Jonas Hack

I made use of a finite state machine - naively implemented with an enum and the switch-method.

An enemy-AI, can therefore be in different states:

• Guard - stand at a point
• Partrol - 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):
Here variables for the next state get set. (Things like navmesh agent destination etc.)

Periodically the exit conditions for each state are getting 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 uses of an event based sensing system. These events are invoked, when the player/exits enters the vision cone or makes a sound withing audible range. Depending on the current state, the next one is selected and transitioned to - usually investigate or combat.

The sensing works by checking 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 consisited of work on the games 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. BOIDs 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
• Seperation to avoid clumping
• Steering towards a goal
• Avoidance of obstacles
• Spacial 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 avereraged 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 the future, I might look into compute shaders and the jobs-system to improve performance even further.

A large part of my contributions consisited 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 smaller scope than intended. 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 preovious involvment 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 cue, containing all relevant articles. This cue 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. Incase 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 archieve 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 sufficent 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 indiviudally

Swamp Water

At the time of the games 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