Jonas Hack

World State

I wanted the world state to be managed as simply as possible. So I designed the system bottom-up and separated functionality as much as possible. To this end, I used the blackboard pattern - I stored all information in a central class by associating an enum with integer values. This way it is trivial to add new tracked state variables by editing a single file, whilst still having all the variables statically accessible at compile time, preventing key errors from the typical hashmap based approach.

This also makes formalizing preconditions and effects trivially easy to create and debug. Both are just a list of structs that check or set values from the blackboard. These are then stored in nodes in the decision tree. Each functionality is entirely compartmentalized, only depending on itself and the rather straightforwardly implemented blackboard. This way the call stack is shallow with only a few dependencies: When presenting a decision to the player, the current story node simply evaluates all the preconditions of its children and applies the effect of the chosen option.

Tooling

In order to actually create the story the narrative designer needed straight forward to use tools with fundamental quality of life features. Luckily they were familiar with Unity, so I could implement it as an editor extension.

The simplest debug feature is an inspector for the blackboard: The world state data needs to be reassociated with human-readable names, since it is stored in an integer array accessed by enum ID. This is achieved with a procedural inspector loading the variable string from the enum.

The more important feature is the visual authoring of the story-flow in the form of a decision tree, or rather graph. This process is designed to be as similar to the standard Unity workflow as possible. Each node is a game object, visually represented by a box in the scene view, connected to its successors by an arrow and color-coded according to reachability with current world state. Each node is selectable in the scene. Connections can be made by drag-and-drop. Conditions and Effects are simple drop-downs in lists.

As additional quality-of-life features, node children are auto-detected from the hierarchy and acyclic sections are auto-formatted into perfect trees.

The difference to my previous implementations is the goal of supporting upwards of thousands of enemies at once. To that end I made use of the Data Oriented Technology Stack: ECS, JOBS, and BURST.
This allowed me to depict up to thirty thousand enemy space craft, interacting with each other, dodging obstacles, attacking the player as well as turrets. While this approach taught me a lot about data-oriented programming, I don't see myself choosing to work with DOTS again in the near future. More tried and tested methods are much nicer to work with, where scalability is not as much of a concern.

An additional point to consider is the simple fact, that from a game design perspective, making such large masses of enemies fun to play against is quite difficult. Besides just lowering the enemy count, I also mitigated this by:

1. Scriptable Waves
   I created tooling to allow a pre-determined number and type of enemy swarm to spawn at specific times and under specific conditions. This facilitated the creation of a tutorial like introduction to the game with a manually fine-tuned diffuculty curve.
2. Wave Director
   I created a simple overarching director which takes into account the current world state, such as player health and turret count, decides on the type and diffuculty of enemies to spawn, tailored to the current situation. This approach is intended to extend the possible maximum playtime by dynamically scaling difficulty over time.

The system is based on Fly-by-wire. The player points a targeting reticle in the desired direction using standard mouse controls. The spaceship then automatically aligns itself with the chosen flight path. This process fully respects the physical properties of the rigidbody without cheating by directly setting velocities or rotations. The virtual flight computer takes the difference of current and desired headings, then calculates the necessary forces and torque from there, in keeping with limits put on the ships maximum thrust. The process boils down to solving the equations of motion backwards.

In addition to the player's input, some automatic assists are considered in the calculations. If no or very little input is applied, the space ship automatically slows itself down laterally and turns towards its current travel direction. This mimics behaviour of airplanes for a more intuitive interaction.

I made use of a finite state machine - with a straight forward enum-based implementation.

An enemy-AI can therefore be in different states:

• Guard - stand at a point
• Patrol - walk through waypoints
• Wander - walk to random points near waypoint
• Investigate - walk to point and then to random ones close by
• Combat - walk towards the player and shoot
• Flee - walk away from the player

There is a method ChangeState(Behaviour nextBehaviour):
It sets the variables necessary for the next state. (Things such as nav mesh agent destination etc.)

Periodically the exit conditions for the current state are checked. Some examples include timeSinceStartOfBehaviour and LineOfSightToPlayer. Afterwards the state is changed accordingly.

In Update, depending on the currentState, a different method is called, which controls the actual behaviour of the enemy. For example in case of the patrol state, the distance to the next waypoint is checked and the navmesh destination is updated, if applicable.

The AI makes use of an event-based sensing system. These events are invoked, when the player exits/enters the vision cone or makes a sound within audible range. Depending on the current state, the next one is selected and transitioned to - usually investigate or combat.

The sensing works by testing range, angle, raycasts and layers. Additionally, with every state change, an event is invoked, which then informs any other components. This is used for mostly visual side effects, including emotes and audio barks.

A large part of my contributions consisted of work on the game's enemy AI.
Though most of its features remain unused in-game, a slightly improved version can be found on Github.

I made use of steering behaviours - specifically an improvement on BOIDs, which are a great way to create swarming / flocking masses of enemies.

My version supports these features:

• Directional alignment with neighbouring agents
• Positional cohesion of swarm
• Separation to avoid clumping
• Steering towards a goal
• Avoidance of obstacles
• Spatial hashing for improved performance

Each Update (notably, not necessarily in every frame), for every agent, every feature calculates a new desired direction based on all nearby agents. These directions are then averaged according to user-set weights, defining their behaviour.

To speed up performance, for the necessary distance checks, a spatial hashmap is used. Agents are sorted according to their position into grid-cells, with a side-length of the vision distance of the agents. This makes filtering out obviously out-of range agents trivial for distance-checks, as only adjacent cells need to be sampled, greatly improving performance compared to a brute-force approach.
In a later project (Terminal Rim) I revisted the topic of BOIDs and improved performance massively using DOTS.

A large part of my contributions consisted of work on the dynamic narrative systems, which controlled what direction the story takes, by selecting the next available news articles.
Due to organizational difficulties, this system had to be partially cut to fit a reduced scope. Under the hood my original implementation works similarly to the dialog system of Firewatch and valve's AI-driven dynamic dialog system, outlined in these great GDC talks: 1 2

A global DataManager stores information about the player's previous involvement with specific topics and factions in a form of blackboard. These values can later be queried as preconditions for story threads or modified as direct effects of player actions.

Each news article stores mainly four things.

1. The information necessary for display.
2. A set of conditions, which have to be met for this article to be considered, along with a lifetime defining the maximum turns the article can stay in the backlog.
3. A set of effects, which modify the world state, such as faction relations.
4. A UnityEvent used to trigger special effects.

With all this information the StoryManager decides which articles to show next. It is based on a priority queue, containing all relevant articles. This queue is first filtered for only articles, whose preconditions are met and then sorted based on remaining lifetime. This way currently relevant articles are shown while letting older story-threads resurface as narrative callbacks. In case no articles qualify as relevant to the current world state, filler articles are chosen at random from a set of throwaway articles without any preconditions.
After every round the articles effects are applied to the current world state, simulating the news agency's influence on the political climate. This then affects the available news articles in the next turn, possibly unlocking follow-up stories.

Tools

Level Time Editor

Keeping track of objects in multiple time eras within the same level quickly became confusing and tedious for our level designers. To make their job easier, I created an editor window, which could selectively hide specific time lines, as well as move objects between them. This removed visual clutter of WIP levels and sped up the workflow.

Vertex Painter

A major goal of this game was to demonstrate the decay of architecture through time. The main way to achieve this was through textures. The ageing process of wood is however, specific to the surroundings of the houses. So there needed to be a way to paint on objects within the context of the scene and therefore the engine. For that purpose, I created a simple vertex painting tool with features similar to old school paint. The resulting vertex colors could then be fed into custom shaders.

Shaders

Height Blended PBR

In multiple places, it was necessary to smoothly blend between materials within a single mesh. Unity has some support for this, but only for terrains and only utilising alpha blending and only blending simple textures, not PBR materials. This was not sufficient for our needs.
My improved approach relied on three steps:

1. Using a Vertex Colors as splat map inputs
2. Height blending, by comparing the materials' height maps, not just the splat alphas
3. Blending PBR materials by blending each texture individually

Swamp Water

At the time of the game's development, Unity did not ship with any premade water assets. Also the look we were going for was specific to a swampy biome and could not be achieved with free solutions of the time. So I created my own, with the following features:

• Refraction
• Reflection
• Depth fog
• Scrolling normals
• Noise based waves
• Subtle fake mud on the bottom