Jonas Hack

Each NPC's perception system performs line of sight checks with nearby objects and stores the resulting information in the knowledge representation system, roughly based on the blackboard pattern. Each NPC has a local short-term memory, and access to a squad-wide memory. This way it can coordinate by sharing information with its squadmates, as well as accessing the shared knowledge. For desicion making both sources of truth are aggregated, prioritising most recent facts. Facts whose source has stopped updating them gradually fade, until they are deleted.

For desision making, the state machine queries the NPCs knowledge, tests conditions of transitions and then executes the state's behaviour. For maximum reusability, state management is abstracted into a general-case state-machine. It provides event-based transition effects for visualizing the desicion process. It provides pre-written gizmos and access to Unity's gizmos for debug. And it provides type-based state indexing for compile-time garantees when accessing states. Each state is its own class, tightly coupled to only the state machine and nothing else.

The combined systems are likely more sophisticated than was needed for the behaviours that ultimately ended up in the game, and could have supported more complex enemies. It is a fun technical achievement anyway, though not all features are used to their fullest. The NPCs in this game transition between following a leader guarding patrol points, direct combat and investigating last-known player positions. Occasionally they become fearful or switch allegiances or go berserk.

Based on rigorous profiling, I managed to increase the number of NPCs at a stable framerate tenfold. The game can now run up to 200 NPCs even on weaker hardware and without resorting to data-driven design or multithreading.

1. Spatial Hashing for Proximity Checks
2. Bitmask Faction Checks
3. Zero-allocation Knowledge Queries
4. Query Caching
5. Reduced Load on Navigation
6. Staggered & Dynamic Refresh Rate

To achieve a high sense of polish in the style of arcade games, I implemented a game juice effect suite. Several GDC talks served as reference: 1 2 3 4.

The custom camera system is essentially a one-to-one implementation from the talk by Squirrel Eiserloh. It dynamically frames points of focus of the level in the cameras view, by solving by intersecting the area of viable camera positions. It then calculates the weighted average position within those constraints and determines zoom level. Additionally the camera's view is smoothed using asymptotic averaging. Finally both translational and rotational screenshake is applied, using non-linear trauma with linear decay and inverse-square spatial falloff.

Another bespoke effect is a full-transform secondary-motion system. Objects are trivially animated with procedural follow-through using damped oscillation and/or asymptotic smoothing. The system provides functions for each of the numeric types, wrapped as a monad for maximum portability and ease of use. This is used for example in the UI for menus and health bars, which wiggle, buldge, and move using these systems.
Yet another system handles the lifecycle of VFX, such as particles and decals. It is a per-prefab object pool with a least-recently-used cache. This reduces the allocation and garbage collection overhead during instatiation/dustruction and thus the performance impact of often recurring effects. It also makes the VFX semi-permanent, aiding in design considerations such as wayfinding.

1. Flash
2. Anim Tweening
3. Haptic Impulse
4. Area-preserving Squash & Stretch
5. Anim Curve Driven Rotation
6. Screenshake
7. Aim Punch
8. Hitnumbers

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.

In a later project (CAMELS) I revisted state machines and created a much more sophisticated implementation.

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