Phantom Brigade
Combat Systems Design
Part 1 - Turn Based Combat
In this article, I’ll be covering the design and history of Phantom Brigade’s combat systems, from initial prototypes to release.
Phantom Brigade’s combat systems went through two distinct phases, each with its own prototyping, iteration, design and polishing steps. While we were able to apply many lessons from the first iteration to the second, they had very different design constraints and goals. To that end, I’ve broken this into two parts. Covering the original combat system developed at Tetragon Works, and the simultaneous turn-based system developed at Brace Yourself Games.
I was the lead designer, and primary engineer for both phases of development.
Traditional Turn-Based Combat System
When I first began designing the combat system for Phantom Brigade, Tetragon Works was a team of just 3 core developers, with external studio support for sound, music and animation.
It was important to play to the strengths of the team we had, if we wanted to be able to quickly iterate and prepare a prototype in time to show at GDC and other gaming industry events. We were careful to mitigate risks, focusing on designs that could be quickly iterated on and used established design principles.
My core collaborators at the time were Artyom Zuev, and Pavel Effimov, whom are both exceptionally skilled environmental and hard surface artists. This made urban environments and mechanical units a comfortable fir for the team.
After researching market trends on Steam, and cross referencing that against our personal skills and interests, we settled on attempting a turn-based tactical rpg, with Mechs for combatants.
The studio did not have a large amount of funds available, so we had to be very efficient in all of our design choices. Our goal was to quickly hone in on compelling mechanics, and deliver a robust vertical slice of what the game would be like when it was finished. That way, we could either shop the game around to publishers, seek funding and investment, or bring the game to Early Access on Steam.
Design Pillars
Initial Combat Prototype
A core source of inspiration for us was the kinetic, and visceral combat prevalent in Mecha Anime from 80’s and 90’s In particular, 08th MS-Team, with it’s focus on urban, planetary warfare.
The first iteration was designed to allow us to test gameplay as quickly as possible, a traditional move / shoot action combination with discrete player, and enemy turn phases. This was the simplest to implement mechanically and provided a solid foundation to explore the design space from.
Initial Guiding Documentation on Themes
Results
The initial prototypes proved quite useful in testing out all of the game’s core systems, namely turn taking, actions, basic pathfinding, level creation, unit damage, scale, and camera movement.
At this stage, we played by taking turns, passing the controller to one another to command the opposing team’s units.
Playtesting revealed a number of degenerate strategies, namely, it was always optimal to focus fire on a single unit. Maximizing your chances of disabling or destroying it in a single turn. A unit that was out of position at the end of a turn was always a prime target of opportunity, superseding any other tactic.
Increasing the number of units in combat helped soften the blow of losing a mech, though it came with major downsides. It cheapened the value of a unit, and extended the time it took to complete a turn, leading to long periods of inactivity while the opposing force played out their actions.
Initial combat mockups
Turn and Action System Design
The turn and action system design, proved to be one of the major successes of the early prototyping efforts. It consisted of three major components.
Resources - Resources are stored per unit, and have defined min and max values. A resource can be marked as necessary for a unit to become active.
Turns - Every turn, unit resources are incremented. The unit is then checked to see if it is “ready”. This is done by checking to see if all required resources are past their thresholds.
Actions - Actions represent a unit’s available verbs, they have three states, Ready (Requirements met), Unavailable (Requirements not met), and Disabled (Cannot be performed). Actions can additionally add or subtract resources.
The first publicly playable build of combat, showcased at Seattle Indies Expo, Featuring AP and the initial iteration of the action system UI
This allowed me to rapidly iterate on the design of combat, adding new mechanics and turn flows to the game, with no additional programming or UI changes required.
For example, testing ammo and reloading gameplay was done by adding an ammo resource that was required, and consumed by the Fire Rifle Action. The reload action similarly, was made available when the ammo was not full, and filled ammo up to the maximum amount.
By marking actions as consuming and requiring a “primary action” resource granted at the start of the turn, I was able to test having the unit’s turn end whenever taking an aggressive action such as firing.
In this fashion, we rapidly iterated and play-tested until we honed in on mechanics that were interesting and fun. Only then did we add special UI to display specific resources such as Ammo, and (AP / EP).
The Unit UI, queries for available actions a unit can perform. Available actions are white and visible, Unavailable actions are greyed out, and disabled actions are hidden.
The unit has lost its arm and rifle, and can no longer perform the fire rifle or fire at area actions.
Second Milestone Build
We had three discrete goals for the next prototyping phase, based on playtesting and feedback from the initial combat prototypes.
Increase the pacing of turn taking, while reducing the cognitive load for players.
Make decision making for a single unit more interesting, by increasing the space of a unit’s possible actions.
Eliminate discovered degenerate strategies
Second Milestone Gameplay - GDC Builds
Results
Turn Interleaving worked well in playtests, keeping players consistently engaged over a combat encounter. It was no longer necessary to immediately consider all enemy units and their possible move sets to plan efficiently. They only needed consider their own unit’s possible sets of movements and a few units ahead in the execution order to strategize effectively. Turn planning time was reduced from around 8 minutes (2 minutes per unit x 4) to around 1-2 minutes.
It was no longer possible to execute barrage attacks wiping out a unit in a single turn, focusing fire required longer term tactical planning and co-ordination of your entire squad to effectively execute.
AP also proved effective at achieving its design goals, allowing for players to take much more granular and complex turns, for example, spending more AP to step around a corner, fire and duck back into cover. Alternatively, they could stand and shoot risking exposure for potential to deal greater damage to the unit. There was a constant push an pull between banking AP for use later, or spending it all to capitalize on enemy mistakes.
Changes to turn ordering and flow
Turn flow UI
Combat Footage and Gameplay
UI Design - Complexity Reduction
Effectively communicating combat state information to players, would prove to be a challenge over the entire course of development. Players required information about the combat state, weapon ranges, effectiveness, movement costs, and variety of other factors to strategize during an encounter.
To that end we spent a lot of time observing players, and using playtests to determine what information players needed to understand the tactical situation in combat. For example, here is the data that varied per position, and per target.
Position variable data
How much threat is my unit under?
What units have line of sight?
Are my weapons or the enemy’s weapons in range?
Roughly how accurate will my attacks be?
Target variable data
How much threat does a unit pose?
What is it’s damage state overall?
What is the state of it’s various weapon systems and parts?
What actions can the unit take on its turn?
Articles on UI design methodology
A player checks targeting before firing. Icons indicate equipped weapons on each unit. Firing cones show the likely path of projectiles.
A player searches for advantageous positioning. Blue and red lines indicate friendly / enemy weapon range and line of sight
Damage Modelling
One of the benefits of mechanical combatants, is their ability to keep fighting when severely damaged. The mechs in this version of Phantom Brigade, are akin to tanks, taking a severe beating before succumbing to the rigors of combat.
In Phantom Brigade, we wanted to be able to tell the stories we loved from Mecha fiction through the game’s systems. Fighting on bravely as their mech falls apart, and even coming back another day to seek revenge on prior defeats in combat.
To that end, damage modelling became an important part of the systemic storytelling during combat. Each shot had the potential to penetrate armor, damaging precious systems and disabling key functionality of a unit.
This worked in tandem with the action system we created, to quickly allow us to prototype new gameplay.
For example, the unit’s ammo magazine was an internal part of the mech. When it was destroyed, the unit could no longer reload. Similarly, when a leg is destroyed, the run action would be removed, replaced with a much more costly limp action.
Iteration was very fast, allowing us to test new combat mechanics daily, and hone in on mechanics that were fun and engaging for play testers.
Unit Data, Customization and animation
For the purposes of discussing combat, I won’t go deeply into the design of the data structures used by units as I feel that is a topic worthy of it’s own discussion on another article.
The game was developed with a small budget, and we did not have a dedicated staff animator. For that reason, we settled on a unified inner frame with a single animation controller that could be used by all Mech units. Armor is layered on top of the internal frame, which is disabled and swapped as the unit takes attrition during combat.
A unit is made up of 4 main parts
Upper Body
Lower Body
Left Arm
Right Arm
Parts in turn are a collection of subsystems, which are in turn attached to hardpoints.
Each subsystem could contribute to a units stats, as well as resources given at a turn. In this way, we were able to quickly link parts to gameplay outcomes. A reactor was the unit’s primary source of “Energy”, determining a unit’s maximum EP, and recovery rate each turn. We were able to quickly express new part archetypes, such a slowly charging reactor with a deep maximum pool of energy, suitable for hit and run tactics.
Every subsystem contributed in some concrete way to combat performance, so a loss of a subsystem always felt substantial.
Internal Skeleton, and color coded armor sections
The underground base, complete with a mech bay for unit customization
Customization screen for the unit’s main parts
Customization of a part’s subsystems (Upper Body)
Conclusion
The combat prototypes proved to quite effective in achieving the studios goal’s. We were able to quickly prove out the core combat gameplay, de-risking the majority of unknowns in the combat design, as well as overcoming major technical hurdles. Such as Unit Customization, animation, and level destruction.
The game caught the attention of Brace Yourself Games, who later acquired the studio, its team, and the rights to Phantom Brigade’s IP. The project also secured an exclusivity deal with The Epic Games Store, greatly exceeding our funding expectations and allowing for the hiring of dedicated staff to assist with production fulltime. The team quickly grew from a core team of 3, to a peak of 12 core and 40+ internal and external collaborators.
