Phantom Brigade
Combat Systems Design
Part 2 - Simultaneous Turn System
This section covers the development of the simultaneous turn-based combat and timeline systems for Phantom Brigade. From initial ideation and prototyping up until the game’s 1.0 release.
If you’re interested in the design of the original combat system, you can check it out in Part 1.
I was the lead designer, and primary engineer during this phase of development. In addition, I handled all design, asset creation and programming for the combat prototypes. I regularly consulted with the team at BYG, to seek advice and discuss thorny design problems.
In particular, I’d like to thank Alex Vostrov for always being happy to patiently discuss design with me, and help me work through the most difficult points in the design. As well as Tarn and Zach Adams, and Kepa Auwae for talking design shop with me.
I will always be thankful for your help and support.
Design Brief
After Tetragon Works was acquired by Brace Yourself Games, I continued to lead the development team, while taking on the roles of lead designer and programmer.
After securing funding from Epic Games, I was tasked with completely redesigning the combat system from the ground up. The previous combat system was specifically designed to be low risk, and achievable by the 3 person team we had at Tetragon Works. I wanted to limit the amount of unknowns in the design to help mitigate risk associated with trail-blazing an unknown design space.
This time, I was tasked with creating a novel piece of design, one with a strong “Post Play Hook” that players hadn’t seen before. I was given approximately two months to prove out a viable prototype.
Design Constraints
At this stage, we had put approximately 1 year of full-time development into the initial version of Phantom Brigade’s combat. Chronologically it had been about 2 years, though development was slow initially, and consisted of me grey box prototyping systems in Unity on the weekends or at the Indie Support Group in Seattle. It was not until I had landed on a solid idea that I moved to put a team together, first hiring Artyom Zuev and later Pavel Effimov as fulltime contributors.
Timelines were tight : Phantom Brigade was already announced and had an established fan base. We could not delay indefinitely, and the previous version was already far along mechanically.
We had already invested significant resources into creating art assets, set dressing, VFX, customization systems and more. We needed preserve as much of both the art, and code code base from the existing game as possible.
We were very limited on programming. At the time I was the only programmer on the project aside from Artyom, who was also our UI artist and hard surface artist for level assets.
We could no change the “Pre-Play Hooks” significantly, as that is what attracted our core fan-base and press interest. For example, the game must still be turn-based.
Ah, grey box prototyping, my old friend.
We Go and Micro Turns
Decide on a hook to optimize for and narrow the design space to be searched
Create a new Unity Project for greybox prototyping
Pull in pieces of code from the main project as needed to facilitate prototyping
Iterate on mechanics as quickly as possible, while evaluating their potential design risk
Once a design has been confirmed, re-implement the new gameplay in the main project.
Phantom Brigade was inspired by a love for 80’s and 90’s Mecha anime, and the frenetic, often kinetic urban battles that took place in them. Mechs would weave around corners, duck behind buildings, and smash into one another with shocking impacts. All the while wreaking complete carnage on the environment.
The major failing of the first combat system, was that it did a poor job of capturing the essence of a Mecha Anime’s fight scenes. My goal for the prototype became to find a way to solve this, and see if it was possible to capture the cinematic nature of Mecha combat in a turn-based system. To that end, I wanted to start my explorations by experimenting with simultaneous turn execution.
I’m been an avid fan of table-top and wargaming ever since I was a teenager. As such, I am very familiar with “We Go” strategy games. The main variants of these are realtime with pause, where time can be stopped allowing players to issue orders to their units. Planned actions play out in realtime when the simulation has been unpaused.
In the next variant, players their turns at the same time during a planning phase. These orders are revealed and resolved during an activation phase.
A WEGO Realtime With Pause Wargame during planning. WEGO World War II: Stalingrad by Brian Kelley
Next, I mapped the action data to the timeline UI, allowing for a preview and fine placement control. It was not always easy to place actions in the world on the path, especially when units intersected or double back on their tracks. Though, this did introduce edge cases around actions that exceeded the end of the turn.
The timeline was modal, displaying only the actions that the player had currently selected, or was actively planning. This proved to be confusing, and counter intuitive to new players. A new solution was needed to address the problem.
Overview and goals
Prototyping conclusions
The timeline proved to be very successful at solving the core issues I was facing around action selection, specification and planning. Waiting could now be easily understood, and selected on the timeline. Actions could also be selected freely with the mouse and repositioned to finetune their placement, all with real-time previews. Bypassing the need to destructively plan and re-plan actions. I also experimented with the amount of tracks, allowing units to attack separately with both the left and right arm. While it certainly looked cool, it proved to drastically extend the time required to plan a unit’s actions, and served little practical utility. It was always a better option tactically to focus fire on a single target.
The new combat system proved to very popular at BYG, and we play tested it frequently. I was able to port over a lot of the knowledge and systems designs from the original combat system, such as location based damaged, action definition and other data systems I had designed. This helped to drastically reduce the time needed to prototype, and increased the number of action verbs I could explore while iterating. I was able to define and test many types of weapons, playing with ranges, firing rates, and accuracy to define new roles. Physical simulation during turns allowed for much more mechanically deep interactions than were possible in the previous combat system. While the variable rate of simulation time allowed for strong “bullet time” style cinematic moments. Watching shots barely miss a player.
I also discovered and implemented support for a number of emergent player behaviors that I observed in playtesting
Players flanked and executed pincer attacks, exploiting how units turned when firing at their target : Implemented directional hit and damage tables
Using damaged units as mobile cover : Implemented shields in the game, and shielding actions to face units while moving
Players purposely collided with tanks and other units : implemented crashing, which could interrupt a unit’s actions. Bracing with a shield also increased stability allowing for intentional tackling
Players intentionally tackled objects into obstacles : added a basic system of impact damage, allowing units to damage, and be damaged by the environment
Players shot objects out from under units running across buildings and cover : added simple simulation of falling damage
Risks and concerns
Initial Plan and Target
A WEGO Turn Base game, with planning and activation phase. X-Wing Second Edition by Fantasy Flight Games
First playable prototype
I began by setting up a basic turn taking system, pulling in the pathfinding systems, camera and data backend from Phantom Brigade’s main project.
I picked a 10 second activation phase as a starting point for iteration, implemented as 10, 1 second micro turns per simulation or “Execution” phase.
Actions were given a duration in seconds. For example, firing the main weapon would take 3 seconds to complete, and moving a single space would take one second.
Players first planned their movement, after confirming it, they could then place an action by clicking on their movement path and dragging along the pathfinding nodes, that represented each second.
I also built a basic damage system allowing for part destruction, damage popcorn and simple explosion effects.
Friendly and enemy actions planned out on the battlefield - Planning Phase
Early Targeting UI - Showing friendly and enemy firing cones. I added a timeline to keep track of the micro turns as they executed. I also introduced the concept of a player ghost, that could be slid along the movement path to preview the unit’s expected position during a turn. Information that was critical for target decision making.
The Next iteration of targeting, communicated the minimum and maximum effective range of each unit. Allowing for simple weapon counter tactics, such as closing range with a sniper or attacking a shotgun equipped unit with a long range rifle.
Final thoughts
The new system was not without it’s major concerns however, there was still a number of degenerate strategies and open design problems I didn’t have time to solve yet. Here are some of them I discovered while prototyping.
Handling of edge cases around turn edges was complicated and would likely need a lot of UI iteration
It was always better to fill the timeline with actions, and constantly empty the magazine if possible. I implemented a reload system, but this did not solve the problem, it was always optimal to pop out, fire your entire clip and reload after the unit was dead or your moved back behind cover. This action pattern was not engaging to testers, and felt repetitive
Animation was going to be very complicated, the possible space of actions skyrocketed as we added verbs. Units could move and fire in any direction at the same time.
Melee was an open problem, while tackling and shield bracing attacks emerged naturally, I didn’t have time to explore targeting and resolution of melee, a key feature from the previous version of the game, and our thematic inspirations.
AI was going to be complicated and potentially computationally intensive. It was no longer possible to discretely walk and evaluate all potential outcomes for decision making. We would need to rewrite the AI to use fuzzy logic or an iterative action planner.
The previous combat system’s coding paradigm was incompatible as it assumed turns as a core principle. The entire combat system would have to be rewritten. Though, we could still save a large portion of the code base, due to how well it was encapsulated.
Simultaneous turns required the player to plan everything up front. Any increase to planning costs for a single unit was multiplied by 4. The time to plan a turn was vastly longer than the execution time (5 seconds of realtime) Even with time dilation extending it to around 7.5 seconds. The more complex we made the timeline, and verbs, the longer it took to plan a turn. This caused major pacing problems, for the payoff to be worth the time taken to plan. Streamlining the UI was a major priority and would take along time to get right.
The information density was very high both in planning and in execution, players had a hard time parsing the entire battle, as actions could take place off screen outside of view. Players would need a way to review or replay a turn to get an understanding on what they missed during a turn.
Resolving these outlying concerns would take several more months of dedicated prototyping at my estimation, as they were complex and highly coupled design problems. In addition, there was not much existing or modern design to reference, so there would be a high trailblazing cost to find workable solutions in design and UI affordances.
I considered the prototype to be very high risk, as I generally prefer to fully prototype before moving into production so I was hesitant to proceed. Having major unknowns in a design is always a risk, especially when it is hard to predict how long it will take to resolve.
In regards to goals, the prototype largely achieved them. The combat system was novel, and felt new. Players really enjoyed it, even in this early version, and it was a big hit around the office. There was a lot of potential for emergent gameplay, and the cinematic nature of the UI and combat was a much better fit with the project’s thematic inspirations and design pillars. The new combat system was also evaluated to have stronger pre and post play hooks.
Overall the prototype was deemed to be a success, and worth committing to by the stakeholders at BYG. I was directed to proceed with porting the prototype over to the main Phantom Brigade project
I moved away from the concept of micro turns, to a linear simulation time value. This allowed me to design a smoothly scrolling UI for scrubbing time (Unit Timeline), and control the speed of execution. Actions now had a start time and duration that allowed them to be freely placed. The gesture was intuitive, and inspired by the interface of video viewing software, such as VLC.
I discussed the problems I was having designing a UI for planning actions with team. Chatting with Marlon, the Video Producer at BYG, as well as Ryan Clark, the founder of Brace Yourself Games. Ryan shared a screenshot of planning in excel, using colored lines and bars stacked on on top of the other. The analogy worked well. Each action was in essence a task that needed to fit into the schedule of a turn. Marlon also suggested taking a look at the UI Video editing software, as they were trying to solve a similar problem.
This proved to be just the inspiration and I needed, and I quickly implemented a timeline with individual “tracks” for actions. A track for movement and spatial actions, and a track for secondary actions that depended on position, such as firing.
Units execute their actions simultaneously during the Execution Phase
Second Iteration
Timeline UI development
At this stage, we had all the basic pieces in place to begin experimenting with game mechanics.
I conducted playtests with BYG staff, and other designers to collect feedback on their play experience.
Here were the main take aways
Simul-Turns were a big hit, players enjoyed how lively combat started to feel with units moving around at the same time and bullets flying all over.
Testers were much more comfortable executing team based strategies, players emergently began using their own damaged mechs as mobile cover when a weapon was lost, and even executed pincer or flanking maneuvers
Action placement felt clunky, the rounding per second made placing actions a staccato experience. This was a clear trend that persisted throughout the project. Placement and dragging always had to be smooth or it was accepted poorly.
Players wanted a way to preview their actions, to see if timing would play out as they expected.
10 seconds was too long for a single turn. Players didn’t feel they could react quickly enough to the changing conditions of the battlefield.
To Be Continued! The story is not over yet, I’ll keep expanding this design entry as I have time.