Days Gone is an open-world action game set in the high-desert of the Pacific Northwest two years after a mysterious global pandemic has decimated the world, killing most but transforming millions into mindless, feral creatures. Survivors live in a world where resources are scarce, violence and murder are common and Freakers roam the wilderness.

My role in this project was to fill the enormous open world with a variety of encounters as well as populate the play space with items and weapons for the player to find a collect. One of the first challenges to overcome was of course what the player would do in the open world while exploring and traveling between missions. The mission to mission narrative was all but cemented when I joined the studio, and so it fell to myself and the rest of the open world team to fill in the blanks and create a constellation of events and small narratives to flesh out the world. The world needed to be brutal and unforgiving and test the player in ways that the main campaign couldn’t. In order to create a collage of events to test the player, the team needed an easy system to create and implement them, enter the Ambient Events system.

Because the game’s scope was constantly expanding the open world team needed a way to create huge amounts of content as soon as an idea struck and be able to alter that content as soon as changes were made in the game world. To meet these goals we created the Ambient Events system. Although initially built only to handle small scale human encounters, the system quickly expanded into a robust, modular blueprint driven system in which new events could be conceived and deployed in a matter of hours, rather than prototyping and implementing all the logic over a few days.

Ambient Events are built from two major interlocking blueprints. A single base class handles every ambient event and dictates when the event will ‘fire’. This initial step examines the player’s current status like health and ammo, as well as what weapons they’re carrying. It is also able to be far more granular, for example, one event in which a bike scrapper can appear and disassemble the player’s motorcycle.

All of the major interactive elements are hand populated however, allowing the design of the event to best suit the environment. This also allows the events to be highly customization and feel more organic.

To the right we see an example of an Ambush Event populated. In this scenario, the unsuspecting player is ambushed as they approach. When they get too close a Freaker jumps out from around the corner and grabs them, forcing them to the ground. This was one of my favorite events to populate - even though I knew the population like the back of my hand they never failed to make me jump when I was testing my implementation.

Above the event we can see the red exclamation point; this is the ambient event marker. This contains the base logic that the event relies on to run, as well as several customization variables about this particular event. The red figure marks where the enemy will spawn. Because the event relied on the game’s standard spawning system we had to actually hide a physical NPC in the world. This created a couple of interesting side effects: like most games, enemy NPC’s are prevented from spawning directly in front of the player. Events with enemy NPC’s will not activate at all if the player is too close to within eyesight of a spawn location. This means that events are less likely to happen if the player is being vigilant. On top of that, if a player is being especially observant, they may actually see the event before the enemies have a chance to react, letting the player score a rare victory in this hostile world.