CoL

Child of Lothian

In ‘Child of Lothian’, you play as an orphan robbed of her childhood as her family is put on trial by zealous witch hunters. You are left on the streets to escape their persecution inside the bustling world of 18th century Edinburgh.

‘Child of Lothian’ is a single-player, narrative driven, stealth game. Set in 18th century Edinburgh, the player falls victim to witch hunts. After being orphaned the player must learn to survive in the harsh streets as a hunted outcast. It features a dynamic city with rich NPCs that go about their own lives. Through stealth and dialogue the player must create their own opportunities in order to complete objectives. As defined by the given creative brief the final product will serve as a prologue/intro to a hypothetical game.

After the divergent concept phase my responsibilities have been tied to the AI, from their design, to technical implementation (blueprints and AI systems such as Behaviour Trees), to the creation of tools to be used by level design, to setting up the animations (state machine) using the work by the artists!

‘Child of Lothian’ is now available on Steam!

My Work

Concepting, prototyping, implementing and playtesting AI & NPC design. Primary responsibility for the Witch Hunter’s design, the main enemy of the game and any NPC with gameplay implications.

The Project

‘Child of Lothian’ was developed over the course of a 8 months by a team of 23-28 developers and is intended as a prologue.

The Witch Hunter NPC/AI Design

The Witch Hunter functions as the main enemy of the game. It’s design intentions are to create that prison escape-ish manhunt feeling, or in our case, a Witch Hunt. With this a unique and interesting we put a unique and interesting spin on our non-combat stealth as well. As the player wasn’t just sneaking past ‘guards’, they also had a pursuer so the evidence they left behind matters. It flips the ‘leave-your-mark’ trope as you leave your mark on the world but that’s not necessarily a good thing.The design solutions I put forward here allowed us the achieve the aesthetic of this all, not just in the cut-scenes, but also tell this narrative through gameplay!

The main way this is experienced by the player is through the ‘clues’ system. With this the Witch Hunter can track the player down with evidence left behind. This could for example be a sack of flour the player destroyed as an environmental interaction ‘smoke-bomb’.  The player weighs short-term advantages with longer-term consequences, putting a different emphasis on the planning aspect of stealth gameplay.

Enhanced Spatial Awareness System

This system was designed to increase spatial awareness and achieve more natural behaviour for NPCs. Besides standard static environment data, AI can also read dynamic info. An area can be marked as suspicious when a loud noise is heard from the player destroying something. This value can then be lowered again if the AI is looking a the location.

Instead of every AI using complex logic and randomness to come to conclusion a lot more can be read from the environment.

AI need less communication between each other as they are all part of the same system which allows them to work together as dynamic in there without it needing bespoke logic.

Data stored here can also be accessed by NPCs without AI as they don’t need to use logic, but only to read and get info.

Additional Solutions

Particle Crowd Input

The data stored could also be used as an input to a particle system. This is relevant as the plan was to simulate crowds with this. By using this the particles could respond to world events without using perception or AI logic.

Teamwork

The systems also improved possibilities towards believable ‘team’ work. Instead of each AI making similar decisions they split up the area to investigate without needing to communicate directly with each other. The AI themselves have no actual awareness of each other, only the grid’s shared data!

AI Perception of a Sandbox

As our concept contained a sandbox and an AI to interpret the player’s actions in it, we had to find a way for the NPCs to be able to understand an expandable variety  of possibilities and events.

As a solution I designed a system that allow the AI to interpret the worlds based on tags. Anything that was detectable would then communicate its info using the universal tags. Each source has an array of three tags, each with their own purpose. Based on these the perceiving actor could then make a decision on how to respond.

Perception Tags Array

0. Actor Type

Index 0 dictates the type, is the source a player, a NPC or an object. This value should be set on construct and not be changed at runtime.

Target
This tag identifies the player or their unique actions. Most NPCs will deal with this the same as the NPC type, only the Witch Hunter will use it differently as they ‘recognize’ the player and their actions.

NPC
Tag used for NPCs that are also a stimuli source. For example a NPC that is knocked out.

Object
The object type is reserved for actors in the world without their own behaviour but are still ‘perceivable’. For example a flour sack that can be destroyed.

1. State

Index 1 dictates the state, this value will update based on the source’s state. A player is ‘neutral’ but then set to ‘danger’ when pickpocketing.

Neutral
The neutral tag is reserved for actors with a stimuli component but don’t contain specific info at this time. A flour sack is ‘neutral’ until is becomes ‘suspicious’ when hit by the player’s sling.

Suspicious
This tag can be reserved for things that are odd but not immediately dangerous. This can be unidentified sounds or sling-broken-objects. This is generally what an NPC would investigate.

Danger
This tag is slightly different than before as it not only means something is out of place, but also that there’s a threat. This can be used for something civilians run from but the Witch Hunter runs towards. Think a knocked-out guard or witnessing the player pickpocket.

2. Clue

Index 2 dictates whether or not something is a clue that can be found by the Witch Hunter. The tag is ‘Clue’ when valid and empty when not.

Clue
Things marked as ‘clue’ can be investigated by the Witch Hunter and work with the clue system. These will not affect the NPC’s alert state. (This index is left empty in the case of the source not being a clue).

With the use of macro’s the registering of tags is quite easily done. All logic is dealt with in there based on the Enum input options.

One of these Macros sets the source’s type and description. This can change during runtime. For example, something that’s destroyed can change from neutral to suspicious.


The other Macro sets the third tag for the clue. As clues are only available for a limited amount of time, it provides inputs for this in floats. The first determines for how long the clue can be found by an NPC, and the second for how long it is valid to be used if already found.

To use the tags we, added a custom event to the AIPerception component. In addition to getting the actor, we would now also get the tag array. With a function, the tags are assigned Int values which then select an option from a struct. In this struct the designer can set how the AI should respond to each of the possibilities.

NPC Level Design Tool

The custom NPC Level Editor was made by me for the level designers setting up ‘ patrol’ paths for the NPCs. It aims to make working with the NPCs more accessible and speed up the workflow. While the properties could be edited in the details panel, the fact that it’s just numbers and has no in level representation makes it a pain to work with. The custom viewport (which controls like Unreal’s one) gives the level designers have all these properties in one screen. They can see what they are doing in the world through debug shapes and don’t have to type numbers as they can click in the world with a 3D cursor to set a point to that location.

Early Prototyping

During early prototyping and concepting I was also involved in various other features. The example above shows quick and dirty explorative prototypes into different interpetation of a climbing mechanic that was being discussed by the team.