First person shooters have evolved over the years to build fun environments for non-player characters: soldiers that take cover, aliens that give chase and allies that help in the heat of battle. These all fall within the scope of contemporary shooter design: of holding ground, of defensive lines and holding the player back. In this case study I look at what happens when you toss out the rule-book with id Software's 2016 reboot of DOOM.
DOOM is built around a philosophy known as 'push forward combat': influencing narrative, level design, combat, player progression and more. In short, it acts as a critical reflection and reaction to contemporary shooter games. Whilst Call of Duty will have you hunker behind cover and pick off enemies from afar, DOOM breaks from these conventions to deliver a powerful, fast-paced and visceral gameplay experience. But how does it all come together and what part does AI have to play in bringing it to life?
Push Forward Combat
The philosophy of Push Forward Combat is all-encompassing in DOOM: defining the core pillars of play and how player and AI would interact with one another in combat. As Kurt Loudy explained in his 2018 GDC talk, the game largely pulls its mechanics from the original DOOM games, namely the fast movement, hidden pathways and over the top gun-play. But while it aimed to evoke the originals, it sought to capture a whole new audience who had never played old school FPS games, much less DOOM and DOOM II: Hell on Earth. As such, push forward combat is built around four pillars that drive the overall design of the game:
The Speed of movement of both the player and enemy demons.
The Individuality of demons
A Distinctiveness to each weapon
And even in the face of adversity, maintaining the Power of the player.
These four pillars helped establish and refine mechanics during development, given it would become clear whether they enhanced or detracted from the Push Forward Combat principle. Hence weapon reloading was removed, given it broke the flow of combat, while double jumping was added to allow you to close distances to enemies faster. Ultimately, the core gameplay needed to be intuitive and fun, but over time could become increasingly more complex in its combat design in a manner that rewards target and weapon prioritisation. DOOM's combat often takes place in medium to large scale arenas that are asymmetrical in nature, carry a lot of verticality and have a lot more in common with online multiplayer shooters than traditional single-player campaigns. Once you add enemy demons into the mix, it creates what id refers to as combat chess: where your job is to figure out which demon to smash first and how best to get there.
While this would require a suite of new tools to build and refine the experience, the underlying AI systems it utilises are heavily influenced by more traditional first person shooters and were adapted to suit. I'm going to come back to discussing how exactly DOOM's AI reinforces Push Forward Combat through design, but first I want to explore how the AI architectures work and where it comes from. In order to do that, I need take a moment to talk about the DOOM that never was and how it became the game it is today.
Rescuing DOOM
It's well documented that DOOM 2016 had a troubled development cycle; struggling with the franchises identity and what it sought to become for the modern era. The game originally carried a resemblance to more contemporary shooters, but was ultimately scrapped and DOOM as we now know it took shape from there. It is within this transition, that the legacy of the AI toolchain adopted for the game can be found and how it helped realise the Push Forward Combat concept.
DOOM 4 - as it was originally titled - had been in development since 2008. Parent company ZeniMax Media - who had bought id Software in 2009 to sit alongside Fallout developer Bethesda Softworks - were not happy with progress made and wanted to see a change of direction after an internal review in 2011. Sources close to the project that wish to remain anonymous, told me that the team behind Rage - who were pushing to start pre-production on a sequel - were made to cease work and merge with the existing DOOM 4 team. 'Call of Doomy' - as it had been disparagingly referred to within the studio - experienced a significant course correction from 'DOOM 4' to simply 'DOOM'. This led to a lot of frustration as ideas and personalities clashed over this new direction. The project's new design lead Matt Hooper sought to rekindle the energy of classic DOOM and my sources tell me that SgtMarkIV's Brutal DOOM mod acted as something of an affirmation of this ideal. This lead to a new gameplay demo presented in 2012, that emphasised the push forward combat philosophy as well as reworking the glory kill system that was already in place in DOOM 4.
As many of the senior developers from Rage made their way onto DOOM, so too did many of the tools and systems from both the game itself as well as the id Tech 5 engine. So I'm going to explore the core tools of the AI architecture in the id Tech engine as well as what systems built and refined in Rage were subsequently ported to DOOM.
AI Architecture
The AI toolchain used for DOOM started development back in 2005 as part of the id Tech 5 engine not long after the release of DOOM 3 and received their first true test courtesy of their adoption within Rage. The main decision making system for enemy AI in both Rage and DOOM is Hierarchical Finite State Machines: a variant on the classic AI method that allows for greater flexibility and control of sequences of states and their behaviours.
Hierarchical Finite State Machines
Finite State Machines revolve around the principle of a state: during which the AI can execute a specific behaviour as well as other states it can transition to based upon specific conditions being met. Grouping a particular set of states together and enabling transitions between them can allow for some versatile, reactive and fun behaviours, with one my earliest videos on Batman: Arkham Asylum highlighting how it was used for the inmates in both stealth and combat.
However, this can quickly become complicated as the number of states increases and the possibility for even more transitions between them. To address this, Hierarchical FSMs group specific collections of states to execute as one cluster, with specific transitions into and out of that cluster.
The clusters essentially create smaller state machines within the larger state machine that the system can transition in and out of. Allowing for a more regimented and structured behaviour with specific states existing in one or more groups. This allows for specific aspects such as moving into cover, attacking at range, or up close to be carefully maintained and modelled for each demon.
This distinguishes DOOM in many respects from many modern shooters given that finite state machines are a lot less prevalent in these days, with the likes of Behaviour Trees and even HTN planning proving more popular in the current market.
The HFSM system in Rage was built to enable designers some flexibility when customising behaviours for specific situations, but the actual ability to construct these state machines was limited to programmers. As my sources explained, it was best to ensure that the design team had plenty of interesting and fun behaviours to work with in a given battle. This would retain the integrity of the AI systems and in-turn minimise the chances of them being faulty or acting unexpectedly. To ensure the integrity of the overall structure, FSMs in DOOM could only be built using a custom-written editor that interfaced with the actual C++ code used to build the individual states. This expanded upon a previously built macro language for Rage that the editor would adopt to record states and proposed transitions for the new state machine. This would cross reference against the header files of the C++ code, which dictated all possible transitions for a given state. The latter proved incredibly valuable for the programming team, who could quickly verify the integrity and structure of the entire state machine quickly by reading the header files either in person or through use of a graph visualisation tool. The final implementation was fast and didn't require tremendous resources to manage in-game. However, while the tools created led to clear visualisation of state machine structure and behaviour, I was told it also meant that the increased number of abstractions made it more difficult to step into and debug specific problems.
In addition to the HFSMs being used to dictate the decisions made by the demons, DOOM is reliant on two systems that were built for Rage: the cover system and the animation system.
Animation System
The animation system - referred to as AnimWeb, is itself a Finite State Machine. Each state handled the execution of a specific animation for a particular behaviour, while transitions between states handled the blending between animations. The system would often compute paths through the animweb that triggered starting, middle and ending animations for a specific AI state, with transitions synchronised to occur on specific pre-built blend points calculated from analysing the bones in the skeletal mesh. This system proves vital later in this video as I discuss the design of the demons behaviour, given I'll be looking at what AnimWeb does to tweak and modify animation execution at runtime to ensure demons are consistently terrifying throughout the experience.
Cover System
Lastly, a cover system that heavily interacted with the decision AI, animweb and the built-in navigation tools was built and put to the test in Rage. Rage's combat design and in-turn it's cover system took inspiration from the early Halo
