The ALEX Protocol is a third-person action game that offers an intense and challenging arena combat for Controller for PC. As game designer, I authored the game design documentation and regularly updated a change log. I designed the combat system for both the player character and AI. I also worked directly with our character artist, animator, and animating programmer to create fluid and fast combat moves. I also balanced the game’s AI, player attacks, and overall objective system.
Team Size: 17 Developers
Dev Time: 24 Weeks
Weekly Hours: 20 hours
Engine: Unreal Engine 4.9
-Designed & Balanced Rock/Paper/Scissors Combat System
-Balanced player attacks speed and animation
-Balanced player movement and arena sizing
-Designed & Balanced 3 unique enemy type behaviors and attacks
-Authored the Game Design Documentation
-Consulted and maintained vision of game throughout project
-Designed and Balanced the Destroy Objective with Lead Level Designer and Lead Programmer
-Designed the Control Point of Objective with the Lead Level Designer and Lead Programmer
-Led pre-production and production design meetings
The Alex Protocol was my first time doing a single-player, combat system. We had 8 weeks for Prototype/Proof of Gameplay to Vertical Slice; and a following 8 weeks to take the system and visuals to RTM. Knowing this, I chose to create a combat system that was simple on paper, and easy to communicate to players: rock/paper/scissors/shoot.
Flying enemies were light, and swarmed around the player create areas of denial around the player, forcing the player to dance around the play space. Players cold easily grapple these enemies and throw them, but reaching in close with a melee attack was very tricky. But if lined up correctly, sent these enemies flying.
One of our AI programmers set up a behavior tree with swarm variables that allowed me to test and tweak how large the area of denial the flying enemies would create for players. This behavior tree really helped when the Level Design department and I had to decide the amount of enemies we could feasible have on screen and in encounters.
Through constant playtesting and iteration, we determined the minimum and maximum number of flyers needed to keep each arena encounter frenetic and challenging.
The majority of my time was spent working with the AI programmers. We collaborated on having each enemy have a unique reaction to each one of the player’s 3 attacks. It was not only important to communicate which attack to use, but also make the attacks powerful, frenetic, and feel that way when players used them against the correct enemy type. Attack animation timing and giving enemies reactions to player attacks helped enhance the combat experience.
A large part of my game design contribution was balancing the speed of each player attack (usually in milliseconds) with how long it would take to execute the attack after a button press, the time it would take for the enemy to get hit (if not instantaneously), and then the damage value associated with that attack.
I used blueprint within each player attack to match the animation timing from Unreal Engine’s animation editor to make sure the delay on the player attack were the same value. I did this process for each of the player’s 3 attacks.
The image on the left shows the Throw Attack animation slowed down to a 1/4 of the speed we used in the final game. The right image shows the attack at its final in-game speed.
The grapple animation was also included in the throwing attack animation/attack time. Originally, players would be able to grapple objects in the environment as well as enemies, but was cut to focus on the player character’s interactions with the enemy instead.
This three stage attack required players to hit the button in under a second to successfully string 3 animations (same-value damage attacks) in a row. This attack would hit up to 2 enemies in front of the player, do the same damage to each enemy for the attack; and if hitting a ground enemy, would kill them in 2 strikes, making the final attack a “free” attack against any enemies in the player’s area.
The above images show the Flail attack separate stages for each animation, slowed down.
These animations show the in-game speed for the flail attack.
Although I did a balance sheet initially in Excel, the final balancing happened in-editor through each enemy and the player blueprint. We chose in-editor blueprint (instead of data tables) as it was the lowest risk option for our limited time schedule. Reflecting back on this process and now having experience with them, I would use Dynamic Spreadsheets or Data Tables to keep all of the information in one (rather than several) places.
Trying to communicate the same vision to 17 different personalities and communication styles is tricky, especially in an open office environment. This environment really tested my ability to communicate clearly, when early on prototyping didn’t always match the vision. I learned that unless people can see it on the screen, they really don’t know what you’re talking about. In lieu of an image, I had to constantly speak in the language of playing the game. Detailing why and how the experience felt to players helped communicate my ideas more clearly.
During this project, there were some milestones where I had to communicate when our product didn’t match publisher quality expectations. To avoid this, a lot of my work during core hours (when our team met in-person) went to consulting and play-testing. This meant most of my own balancing and design work fell into personal out of office hours. As the team began to work late hours as well, my design work kept pushing further back. Eventually, I burnt out, took a day, and came back strong. Crunch taught me to pace my passion for excellence.