Idea

I wanted to have both a puzzle and a game design piece in my portfolio.
With Mutualism 3D I aimed to tackle both at once.

I decided to reuse an old game idea of mine: Mutualism . With this as the foundation I could make something new and personal, and also work with recreating game mechanics in a different engine.

Priorities

• Main priorities:
  • Merge mechanic
  • Synergising mechanics for puzzle making
• Lower priorities:
  • Characters
  • Animation
  • Combat + AI

Game description

You play as 2 blobs, wielding swords.

You can play separately or together by merging your characters into 1 stronger, slower, and heavier blob – allowing for different challenges to be overcome.

You must communicate and strategise about when to be merged and when to be separate.

Merging

The mechanics decide what puzzles and challenges are possible, so this was the first step.

The gameplay is centered around the idea of playing merged and separate for different abilities and capabilities. So the merge mechanic is core to the experience and was the first thing developed.

When both players hold their merge button, the characters will be forcefully moved towards each other, and combine upon touching.

Character controller

Second was the character controller. I use Unreal’s third person template as a base, but have modified jump, gravity, move speed, to fit and feel good for the character.

I also added a sword attack allowing for combat and puzzles such as hitting levers, boxes and other obstacles.

Enemies

AI and enemies were taken from the original game.

I added a small enemy that is easily defeated alone, and a large enemy that is necessary to be defeated while merged.

I added one combat area where there are several of each type.

Levers, doors, & moving platforms

At this point, I had achieved my minimum requirements for the game. It was time to get creative with what mechanics would play well with the others.

I first added doors and and moving platforms to work with the levers.

Heavy levers

I added a heavy lever, so it would require players to be together to toggle it.

This allows for puzzles such as putting the players on different paths and finding their way together before they can use the lever.

Color gates

However, as the players have the same abilities, I needed a way to separate them.

I then came up with the color gates. Each player can only go through the gate matching their own color.

Additionally, a teal colored gate can only be entered when merged.

Advanced uses of mechanics

Puzzles can be built with very few and simple mechanics, so I decided to stop developing additional mechanics here and think about what opportunities were now available to me.

It resulted in 2 particular cases:

1. Merging mid-air to reach platforms.
   This puzzle arose from realising I could use the attraction that gets applied when players attempt to merge.
2. Teal gates as blockers.
   This came to mind when I wanted to explore the opportunities of combining moving platforms and color gates.

1. Designing puzzles

I enjoyed trying to discover all the quirks and opportunities the mechanics provided.
However, it also proved difficult to make some truly meaningful puzzles in such short amount of time. Each puzzle has to make sense for the mechanics, can’t be redundant, and should not be able to be completed alone.

Running playtests revealed that many puzzles didn’t meet my requirements – didn’t give value to the meaning of the mechanic, or were too combat focused. This led me to create my puzzle design framework.

I had a playtester say “I really want to create levels for this game“, which made me feel I was on the right path.

2. Unreal logic issues

Making the merge logic work in Unreal proved to be a lot more difficult than it was in Unity. Switching from multiplayer to “single-player” (2 controllers for 1 character) was a mess. This is mainly due to how Unreal decides multiplayer “should” work for most games. I had to make a few hacky solutions, such as input-forwarding, to make the controllers work as intended.

Another issue was how players are spawned in by default, and how their controllers are assigned. Modularity was important to me, which made it harder but smarter – This is in case I want a character select in the future, or maybe 3-4 players co-op, or to assign visuals and outfits.
My solution in the end was to assign players with a trigger box that they land on when they spawn – Simply because the standard way of spawning players in Unreal doesn’t allow for much tracking of possession, especially if you need to control different characters at different times.

3. Controller tutorialisation

I also experienced some issues with players not realising what they control whenever they are merged. It currently works so one player controls the left side of their controller (movement) and the other controls the right (jump, attack, camera). This was an issue I had completely overlooked as it was not present in the original, where the only controls were movement and attacking.

Additionally, that game was designed for a hybrid controller, where players had to hold hands, naturally leaving only one hand left on the controller. It was surprisingly not much of a concern for most players during testing. However, I still find it highly problematic that some don’t understand their controls. I will need a fix for this, but as of writing, it is a lower priority.

4. Combat & AI

Enemy AI became another new challenge for me. I could have made do with a simpler script, not using behaviour trees, which probably would have caused less bugs, but I wanted to challenge myself with a deeper and more modern approach to AI development. I still have issues with the enemies getting stuck on the edges of nav-meshes, along with them being so small that they sometimes crawl under the players, causing all sort of bugs.

This will have to be a potential future fix, as combat is a lower priority.