Setting Combat Direction

With limited time to establish a proof of concept, I was tasked with setting the combat and camera direction for the rest of the team. We wanted the game to be fast paced, while keeping the player feeling challenged and vulnerable. When deciding how to achieve this vision, I started by identifying the challenges, constraints, and existing ideas inherent to the game we were already making, that the combat system would need to support or work around.
These were the most inflexible ideas I had to keep in mind when planning the combat systems:

1) Shared characters between player and enemies2) Keep the player feeling vulnerable3) Limited animation budget4) New 3rd-person camera5) Center the possession mechanic

Because the team only had one animator stretched between several different controllable characters, the number of unique attacks and hit reaction states to a minimum. From here, we could define the core conflict of the game.

With these principles defined, we were able to move forward with refining the gameplay from the initial prototype.

Refining the Possession System

Moving into production, we knew that possession was the project’s signature mechanic, and we had to get it feeling great.

In its initial version, possession was activated by a raycast out from the player’s center camera. On a successful capture, the player gained control of the enemy they hit. That enemy would slowly lose health until it died, at which point the player would take a small amount of chip damage, and revert to their previous form.

This specific version of possession was a great proof of concept, but the aim requirement ultimately proved cumbersome for a game that mostly focused on melee combat. This was an ability that players needed immediate access to, and at this time players would often miss one possession, then run away from enemies while they waited for the ability to recharge.

Our first attempt at refining this involved changing the possession to a cone, in order to target a larger range of enemies without accurate aiming. While a definite improvement, this was still too slow and specific for something the player needed immediate access to. It allowed for quicker plays, but the player was still having trouble keeping up with the onslaught of enemies The move’s slow speed and difficulty to aim made what should have been our keystone mechanic cumbersome and risky to use, and we needed a version that the player had quicker access to during gameplay.

At the same time, we were having difficulty solving our game’s dodge mechanics. The player needed a reliable way to respond to enemy attacks, but building unique defensive options for every enemy would either need to replace the secondary abilities that made each enemy unique, or risk overblowing our animation budget. We needed a simpler system that would work across every character, and realized that we could solve two problems at once by folding it into our possession mechanic.

Our next iteration was what we called possession counter. The player could still possess normally, but if they pressed RT in response to an attack, they would do a short teleport backward, and possess the enemy that attacked them, if they had possession available. This both created a viable, character-neutral response to enemy attacks, and helped the player gain an offensive form more consistently.

These changes granted a defensive tool and pushed them to engage with the possession system more, but was not without problems. First of all, it was confusing. Players would often get the dodge or conter-possession to come out without intending to, and the action was too quick for them to understand what was going on. Players were also not switching forms often enough. While we dedicated a face button to leaving possession, the game did not incentivize the players to use it, so they usually stayed inside one enemy until it ran out of health, at which point they would just grab another. Finally, since running out of time in a form had little consequence, the player did not care about taking damage. This was a major violation of the goal of keeping the player vulnerable, and after a few weeks of testing with this version of the mechanic, we needed to re-evaluate the possession loop once more.

To address these issues, we made a few key changes to the possession mechanic:1) Split the possession counter into it’s base components; the possession move itself and a teleport that avoids damage.2) Make the teleport trigger when the player leaves a possession, instead of attempting to gain one.3) When a possessed enemy runs out of health, deal continuous damage to the player’s base hp until they manually leave the form.

These changes were very successful. Players now had to make a calculated tradeoff of whether to when to leave a possession, based off if an attack was coming their way, and how much time/health they had left in the enemy.