Company of Heroes is a tactical real-time strategy game set in a WW2 setting, the player takes the role of a commander, giving orders to an army of troops.
No match ends up being the same due to the dynamic cover, terrain and destruction systems.
- Engine: Essence Engine 5
- Role: Gameplay & Technical Designer
- Duration: 2+ years
RESPONSABILITIES
Gameplay Designer & Gameplay Product Owner
Designing, implementing, and balancing player progression systems, using the proprietary engine, Mural, Confleunce and draw.io. Setting a roadmap for the design team post-launch for the game. Improving core systems to the game such as Pathfinding, VFX and Unit behaviors.
- Design of player progression system
- Improved Unit behavior
- Improved Pathfinding
- Coordinated with VFX, Audio and UI teams for better game flow and experience
- Design of various abilities & units
- Triaged bugs for the whole gameplay team
- Set post-launch roadmap
- Livestream appearances to explain patch changes
Technical Designer
Improving workflow for other Designers, as well serving as the bridge between design and engineering.
- Templatization of various systems such as Airstrike System and Artillery System
- Bridging Gameplay Design & Engineering
- Implementation of various mechanics, abilities and content.
- Mentoring designers in the usage of the internal scripting tool
CHALLENGES
As with any project, Company of Heroes 3 wasn’t created without its challenges, below I’ll explain what those were, the solutions we arrived at, and the thinking behind them.
Pathfinding
Pathfinding in a game such as company of heroes is complex, partly due to having to adhere to some realism, but a big portion of it as well because the game is more fast paced than the usual war simulation games out there, meaning that the responsiveness of the actions matters a lot more.
The overall high level problem at launch was that pathfinding was too unpredictable.
In order to solve the issues I had to document them, and come up with solutions which I solved in tandem with an engineer. Lets first have a look at the issues that were found (be ready for a long list):
- Vehicles would move too tightly around objects often losing speed, for a player this felt like the game wasn’t responsive.
- Vehicles would take a “stair” like path even in open terrain which usually made the main gun point away from the enemy.
- Vehicles would prefer to take roads, while in theory this was nice it meant you never knew what the vehicle was going to do.
- Vehicles would reverse into battle, in a game like company of heroes that has the concept of rear and front armor on a tank this is extremely bad.
- Infantry entities would go back and forth if they had another soldier running in front of them.
- Infantry squads could get caught in “retreating loops”, never arriving to base.
- The list of issues was massive, I’ll refrain from listing all of them but more information can be found on this post as well, written by me.
Solutions
The second part is that not only does pathfinding need to be predictable but also avoid frustrating situations for the player, for example the game has a “Retreat units to base” mechanic, when a player engages with that mechanic they expect the unit to always reach their base.
Issue: “Stair” like be behavior
Solution: On open terrain we draw a line to the end location, if the high level path calculation (different from low level A*), gives us a clear path then we forego the usual pathfinding behavior and instead smooth the path out to a straight line
Issue: Vehicle preferance for roads
Solution: While in theory this sounded like a nice idea, in practice its a case of the system being too smart for its own good, since now as a player you are never sure what the vehicle is going to do. It also has a downstream effect on map makers that now need to adjust for this. We removed the preference altogether.
Issue: Vehicles would reverse into battle
Solution: Addition of a weight for A* paths in front of the vehicle, this meant that the vehicle more often than not would go with the front armor to the target location.
Issue: Infantry back and forth & Retreating loops
Solution: Design and implement a set of rules that vehicles and infantry must follow, this meant adjusting how different elements of the game perceive each other inside the pathfinding. Infantry entities will still consider each other although at a reduced pathfinding cost, vehicles will ignore infantry alltogether.
Videos of the behaviors:
Player reception – Overall Positive
Design & Creation – DLC
I was tasked with the creation of post-launch content, this post-launch content came in the form of “Battlegroups”, battlegroups are a player progression system on the RTS layer of the game.
Battlefield Espionage Battlegroup
Theme
Process:
Step 1: Gameplay Goals:
Step 2: Gather Historical Images & Videos:
Step 3: Paper Design & Flow:
Step 4: Iteration
Step 5: Art requests
Final Product:
Advanced Infantry Battlegroup
Theme
The vision began by wanting to include artillery in the American faction roster, the American army made use of the 105mm Howitzer. Not only that but I wanted to surround it with an unified theme, the artillery should be supporting some sort of infantry advance. As such some historical investigation was done on the elite troops called “Rangers”.
Process:
Step 1: Gameplay Goals:
I wanted to enforce an infantry backed army with artillery support, the infantry contained in this battlegroup should be elite to seperate themselves from the core infantry of the American faction. The Rangers regiment should feel elite and unique from other infantry units, this was the core foundation for the battlegroup.
Step 2: Gather Historical Images & Videos:
Step 3: Paper Design & Flow:
By using Draw.io, bringing other designers into the process and iterating on the paper design, we were able to land on an initial tree (note that the below is the final product).
Step 4: Iteration
Making use of the proprietary engine visual scripting language (State tree), I created the abilities and squads. Below is an example of what a state tree might look like for one of the abilities for the ranger squad. I first start by scribbling the logic into a notebook and try to understand what the different state should be and eventually pass that onto state tree.
Step 5: Art requests
After design was happy with the state and direction of the battlegroup I could move on to including art into the process, the investigation done in step 1 was passed onto artists as well as documentation, done in excel , on what the vision was for each of the abilities and what the icons should communicate/portray. Final product below.
Final Product:
Airstrike System
Overview: The issue
We suffered from a problem of having a pipeline that was too inefficient, in order for designers to interact with the airstrike system they would usually end up using days of their time to create one ability, not only was that very time consuming but it was also bug prone.
Another issue with the previous approach was that the airstrike abilities were disjointed, so if there was a bug in one ability a designer would need to go through 20+ other state trees to fix the same issue.
Finally, our airstrike system wasn’t hitting the mark on realism, airplanes were taunted by players as “looking like toys”.
Solution
I templatized the abilities under one monolithic state tree that could implement all the different behaviors that the previous abilities had but now only needing to be tuned with data, meaning the process became fully data driven.
This state tree took data variables in to output very dynamic behaviors that designers could tweak on the fly, not only did this end up saving massive time on the project but also helped us clear the system of any bugs.
Additionaly this allowed other disciplines like audio to not have to interact with complicated state tree logic to hook their audio in.
For the realism issue I carefully tuned the dive plans of airplanes to more realistically match reality.
State Tree Development:
I started by analyzing all the behaviors of the other airstrike abilities and documenting what sort of behaviors I would need to support. Given the complex nature of the game the list was not small.
- Allow for airplane formations & waves
- Allow for dynamic placement of airplane payloads
- Allow for customization of airplane targeting (Will it only target tanks? Or perhaps it should only target infantry?)
- Allow for customization of the payload, this includes: weapon to use; when to drop it; how many times to fire the weapon; etc.
- Allow for unique airplane “loitering” behaviors instead of “one and done” airstrike passes.
- And much more..
Some of the state tree logic would need engineering support to complete, as such I coordinated with the engineering team to give me access to the tools needed to fully templatize our airstrike system.
Visual Result:
Artillery System
Overview: The issue
Similarly to the airstrike system, the artillery system was lacking templatization. This meant there was no uniform way to create an artillery barrage and that designers would always need to create their own state trees. As with the airstrike system this meant that if bugs were found they would need to be fixed in many places.
Additionaly, two of the core pillars of the game were immersion and authenticity, which the previous artillery type abilities were failing at achieving. This system needed to feel believable.
Solution
Creation of a global state tree that handles all the artillery calls, designers would only need to create an ability that points to the correct new state tree and pass it a custom set of values to operate on.
Those set of behaviors need to accomodate levers that would allow for authentic behavior.
State Tree Development
I started by analyzing all the behaviors of the other artillery abilities and documenting what sort of behaviors I would need to support. The artillery system and airstrike system function wildly different, however the same concepts could be applied.
[miguel_marinheiro] 