Summary
Armored Warfare (AW) is a popular free to play online vehicular combat game, similar in many ways to World of Tanks. AW has various game modes ranging from PvE with up to 5 player co-op to 15v15 death match style gameplay. Each game mode has a set of win conditions that the team must work towards to win over the enemy AI/players. Players can choose from various different tanks/vehicles during a match (with additional vehicles being unlocked as a form of progression) filling roles such as main battle tanks, scouting vehicles, and distant artillery.
Global Operations
‘Global Operations’ was a new game mode and one of the bigger features that I contributed to in my time on the Armored Warfare team. I worked on multiple features for this game mode, such as the ability for vehicles to respawn/select respawn points, support for the ‘phases’ that the match goes through as it progresses, and more. One of the bigger things I worked on for this game mode was the implementation of the ‘Wildcard‘ abilities.
Recon UAVs
Recon UAVs can be deployed to specific locations and follow a specific path- both dictated by a designer when adding them to the map. As they move they check for line of sight to enemy units; Upon getting line of sight to an enemy the enemy is revealed to the team controlling the UAV similar to how an ally gaining vision on an enemy reveals them to your team. The UAV has health using the same system as player/AI vehicles and after taking enough damage they are destroyed.
Pillboxes
Pillboxes are simple structures (implied to contain human combatants) that will fire upon enemy units in range- damaging them. They are activated in groups, usually of about 4 structures- these groups and their placements are setup by designers when building the map. The logic behind these is very simple- they check if enemies within their effective range (controlled by designers) are within line of sight of the structure, if so it will fire upon the enemy using parameters also controlled by design (controlling damage, rate of fire, etc). Similar to UAVs, pillboxes can be damaged and eventually destroyed by the enemy team- neutralizing their threat.
Airstrikes
Airstrikes are the final and most powerful ‘wildcard’ ability. The player selects any map location and direction to deploy the airstrike. This will cause players in the area being struck to receive a warning of the incoming airstrike. A countdown will begin and eventually a bomber will fly through the sky based on the target location and direction- dropping a series of bombs on the targeted area which will damage everyone hit by these explosions without discrimination. Unlike other wildcards there is no damaging/stopping the bomber- your only option is to evacuate the area or find cover.
Daily Challenges
Daily Challenges were Obsidian’s take on a feature many games (especially online / free to play games) have. On login each day players would be given a set of 3 challenges- these challenges would have 2 different conditions to complete them (giving players the option to do one or the other) and players were allowed to ‘re-roll’ one challenge per day for a new challenge. Upon completing these challenges players were rewarded with in-game currency/items/etc.
The work for this feature consisted of work on the client, game server, and backend server (a mostly single process application written in C++ that stored player info in a database). Most of the leg work for this feature is on the backend- with it assigning challenges, tracking their completion, and providing rewards. The game server was responsible for telling the backend when progress was actually made for individual challenges (as pretty much all of these challenges are driven by actions taken during a game, such as destroying a certain type of enemy, completing objectives, etc). The front end work was mostly just receiving the active challenges and their status (how close to complete they are, etc) and displaying them to the player. There was also the ability for the player (via the client) to reroll certain challenges which would cause the backend to replace the challenge with a new one (usable once per day) and update the client with the new set of challenges. The challenges were data driven by design- with them setting the icon, description, and objectives for the challenge via data and support for using certain actions/events as objectives provided by gameplay.
Audio Support
During my time on Armored Warfare I also helped support the audio team. Two of the more prominent examples of this were-
Turbocharger Audio
Many tanks use engines with Turbochargers- if you have never heard a turbocharger on an engine before they have a very district sound. This is something that was missing from some of our vehicles and we added after the fact. Support for this involved adding events specific to the turbo for the engine (alongside the existing audio used for the engine) and param manipulation for that event (the project used FMOD Ex) which audio used to modify the volume and pitch of the turbo event. Control over how the param worked (how it ramped as the engine RPM increased and decreased, where it peaked, how fast it decayed, etc.) was all data driven per vehicle to allow audio tight control over how the sound behaved as the RPM/speed of the vehicle changed. This implementation allowed the audio team to implement and tune turbo audio for multiple vehicles in the game as time went on after the feature was added.
Prioritization
During development of Global Operations we ran into bugs with audio for the player’s controlled vehicle cutting out; Profiling we found we simply where hitting FMOD’s voice limit and it was ‘virtualizing’ certain voices based on priority (the sound would no longer be audible but it would still be progressed by FMOD internally as if it were- so the audio would be in the correct position if/when it came back). Looking at the audio being played there was a lot but nothing that was wrong per say, we could do some optimizations to try to reduce the number of sounds being played but the first thing worth looking at was our event priorities, which influences the order in which FMOD will virtualize sounds (sounds for the player’s vehicle should probably be one of the last things cutting out…).
Sadly (or luckily depending on how you look at it) up to this point the audio team had not prioritized any of our audio events so as FMOD was virtualizing audio events it was making poor choices- dropping really noticeable audio events much earlier than reasonable. In order to fix this I worked directly with the audio team to set priorities on all the audio we had in our game (generally by creating large ‘categories’ of sounds and setting the priority on sounds in those categories the same). This took some time but the results spoke for themselves- Global Operations would still hit the voice limit within FMOD but this was fine, FMOD was now virtualizing low priority sounds, which wasn’t even noticeable, and that alone ended up being all we needed to ship the game mode.