I submitted a GDC Talk Proposal for the work I did on the Fire Propagation System on THE FINALS. I unfortunately wasn’t accepted but still thought it was a pretty good attempt. Here is the proposal below:

Architecting Emergence: Designing the Fire Simulation System in THE FINALS

Session Description

THE FINALS is a fast-paced, competitive, multiplayer FPS composed of several emergent gameplay systems working in harmony to create unique gameplay experiences every session. The Fire Simulation system is one of these dynamic systems that supports the overall goal of meaningful player dynamism.

Gameplay Programmer Sahil Dhanju dives head first into the technical challenges of transforming a high level paper design into a production-ready, iteration-friendly, performance-focused, emergent gameplay system.

Topics include the process of working with designers to harden the specifics of an emergent system, the technical architecture of the fire simulation system, and the technical details of how the system was able to meet the performance requirements of THE FINALS.

Attendee Takeway

Attendees will receive key learnings of how collaboration with designers to understand a system’s experiential goals can directly influence the technical decisions and architecture of the system. Attendees will see first hand how these principals were applied to the creation of the emergent Fire Simulation system in THE FINALS and the development benefits this approach provided.

Intended Audience

This presentation is intended for any programmers or advanced technical designers who have an interest in learning how to architect emergent technical systems in a collaborative and fast moving environment.

Presentation Outline

NOTE: This talk could potentially be 30 minutes or 60 minutes, I would like to work with the Advisory Council on which is best. I have also attached a supplemental document which provides a detailed breakdown of the different sections.

The presentation starts with showcasing our game THE FINALS and its plethora of emergent systems that work together to create a dynamic gameplay experience - fire simulation being one of them. Within game development literature, systemic and emergent systems are talked about at great lengths for the gameplay value they provide. However the technical implementation of these systems can easily rot into complex spiderwebs of logic and data, becoming difficult to extend, tedious to debug, and laborious for designers to work with. We’ve seen this first hand in THE FINALS. This section will go into more of the specifics as to why and how this occurs with emergent systems: e.g. unclear separation of concerns, design edge cases that arise as development continues, etc. How do we do this better?

In the next section I lay out the core thesis of this talk: there is a direct relationship between your fundamental understanding of what your system is trying to achieve and the quality/simplicity of its architecture. For emergent gameplay systems, a deeper grasp is achieved by keenly collaborating with game designers to ruthlessly focus on what the player experience goals are. This isn’t the game design process of creating the feature, but rather the collaboration strategy used to harden the requirements of the system. We’re then able to make educated decisions about our architecture since we can easily discern the benefits and trade-offs of different options. I will then go into how this process was applied to discover the architecture of the Fire Simulation system and showcase examples of these requirements such as:

  • Designers wanted specific objects to be flammable and transfer heat between them - we chose an object-based simulation system rather than a voxel-based one. Acceptable trade-off: heat can’t transfer through empty space.
  • Player-driven fire interactions should always be responsive, while ambient interactions should be less so (fire going up a tree). A potential vector for performance optimization
  • Important to tweak how quickly objects became ignited. after they were ignited not much mattered. This insight led us to implement a simple, non-physically based simulation of heat transfer.

The next section is broken up into sub-sections which explore how these requirements directly translate into the specific data representations and creation of the subsystem used by the Fire Simulation - repeatedly always using the razor of “how does this support the player experience?”

As an example, a requirement from above is objects can only transfer heat when they are close to one another. We created the ObjectGraph subsystem to have a spatial understanding of where objects were relative to each other. Rather than using a spatial data structure or overlap checks in the physics engine, we used an internal system called a Distance Query Manager (DQM) that continuously checks the distance between objects, I will discuss the DQM in more depth here and the performance optimizations we gained. The same kind of process will be presented for our object storage representation, simulation of heat, management of FX, network replication of data, etc. The implementation of each being driven by the requirements which were first made above.

The penultimate section will go into challenges we faced after implementing the initial system and how they were easily addressed by having the system be clearly architected in the first place. For example, areas with very dense foliage was catching on fire in a matter of seconds once the fire started to go. We were able to trivially address this by introducing a way to throttle heat transferring from specific objects.

Finally, the conclusion succulently summarizes and reiterates how constantly collaborating with designers to develop concrete use-cases led to an emergent system which is easily configurable, extensible and tractable.

Supplemental Material

Standing on the Shoulders of Giants

This talk can be seen as an application of 3 other talks:

  • CppCon 2014 Mike Acton - Data Oriented Design and C++
  • GDC 2019 Mike Acton - Everyone watching this is fired
  • Rich Hickey - Simple Made Easy

In both of Mike Acton’s talks, he repeatedly hammers the point of understanding your data. An engineer should be able to easily articulate their data, and therefore be able to also understand how this data is transformed (the systems that operate on them). In Rich Hickey’s talk, his thesis is writing “simple” systems is not easy, but rather is done through constant due diligence of focusing on that goal. It can be all too easy to “complect” - meaning intertwine - systems and data that aren’t related to each other. However by using the right tools, you can make achieving simplicity easy. These talks have exceptionally great takeaways but the concepts they preach can be a little too abstract for the audience to see how they concrete apply to their use cases. The value I bring with my talk is that the development and productionizing of the Fire Simulation system is a pragmatic application of the principals in the above talks. Showcasing how applying those tools at every step of the developmental process can take a paper design and turn it into a high quality maintainable system. I plan to mention these talks in the first section, talk about their takeaways and interleave their lessons throughout the rest of the talk. This in turn will hopefully reinforce the concepts talked about in the mentioned talks.

A useful but failed prototype

The first prototype of the fire simulation in THE FINALS was a voxel based system which was unfortunately hard to work with, hard to extend and didn’t meet our performance requirements. I plan to discuss this system and the issues with it when talking about why emergent systems can rot. However another takeaway of this is that prototypes can give you additionally insight to help you make better technical decisions later on

Fire Simulation Architecture

A takeaway I plan to mention at the beginning of the 2nd section (formalizing the technical architecture based on the player experience) is it’s important to keep in mind that the paradigms of the game engine you work in shouldn’t dictate all of your technical decisions. Your system should “fit” into the broader picture, but the internals can be made in a way that suits your problem space the best. In Unreal, it can be all too easy to just simply create another AActor and shove your logic in there without truly thinking about where your behavior should live. For the Fire Simulation system, rather than using an AActor or UActorComponent, we created a more ECS-like system which passes handles back into the traditional Unreal game framework.

The simulation is split up into 5 main subsystems:

  1. ObjectStorage - responsible for storing state for all “fire” objects. A key part of discussing this will be showcasing how player experience requirements turned into the data definitions that live in this system.

    1. We realized there are some objects that should gain heat and then burn (a leafy bush) but some objects that simply always emit heat and are controlled in script as to when they disappear (a flamethrower’s projectiles). This led to there being two kinds of fire objects Burnables and Heat Sources.

    2. We wanted to be able to extinguish burning objects - e.g. a smoke grenade should stop an oil barrel fire. We used “negative heat” to achieve this.

    3. Physical objects in the world are represented in a vastly different way than objects in our destruction system like breakable walls. However designers wanted to essentially treat all of these objects the same when it comes to fire. Therefore our data definition doesn’t include any way to distinguish between these two representations.

    4. Designers wanted objects on fire to take damage. There are many different ways that damage is dealt in THE FINALS and it seemed messy to implement all of this within the fire system. Because of this we pushed the responsibility of dealing damage into the gameplay systems that use the fire system since they have the context of how to deal damage to the objects they are responsible for.

  2. ObjectSimulation - responsible for simulating the heat transfer between objects. The highlight of this system for the audience is just how simple this simulation is while still achieving the desired player experience. I will go into depth about the specifics and how the simulation actually got simpler and simpler as we realized we didn’t any fancy bells or whistles.

  3. ObjectGraph - maintains an up to date spatial representation of what objects are next to other objects. Since we had a clear understanding of the player experience requirements, we were able to easily leverage our in house Distance Query Manager to calculate the spatial representation. I describe the DQM in more detail below. This system was also key in achieving our responsiveness and performance goals.

  4. ReplicationActor - replicates data about fire objects to all connected clients. The amount of data replicated is extremely small so bandwidth is optimal for our performance targets. This replicated data is what drives the spawning of fire related FX (VFX, SFX screen vignettes, etc.) through the Embark FX Director (mentioned below)

  5. Event System - broadcasts gameplay relevant events from the fire system to the rest of the game. There were some tricky implementation details about the issue with synchronously pushing events the moment they happen. I plan to discuss this in the second to last section of the presentation as listed in the outline.

Unique components used by the Simulation

There are 2 inhouse features that are used extensively by the fire simulation system.

Embark Distance Query Manager (DQM)

This system is used by many of our emergent gameplay systems in THE FINALS. It’s a surprisingly elegant and simple piece of code. The DQM allows user code to make queries about one type of object knowing if they are close to another type. For example:

  • Birds can query if players get too close so they can fly away

  • Players can query if they are close to revive markers to show a UI prompt

I plan on going into the technical details of this system is utilized and how it greatly simplified the implementation of the fire simulation system, leading to being able to easily modify the ObjectGraph as requirements changed. Audience members would be able to replicate this system quite easily for their own needs.

Embark FX Director (FXD)

This system is used by almost all code which wants to play any kind of FX - camera shake, vfx, sfx, etc. the FXD is used for all FX for the fire system. Like the DQM I hope to discuss the relevant implementation details for the FXD that helped the fire simulation system meet the player experience requirements but helped keep the complexity of the system low.