DEV Community: Allen Antoine

MSc Final Project Devlog #4: Gameplay AI

Allen Antoine — Mon, 03 Aug 2026 13:56:19 +0000

This post covers the design and development of an AI Non-Player Character that responds to sound signals generated by the player. The post covers gameplay AI, not LLM AI models like Chat GPT or others, so you can stop reading if that was what you were looking for in this post.

Tools of the Trade: AI State Tree

At the time of this writing there are two ways to develop gameplay AI in Unreal Engine: Behavior Trees and State Trees. Behavior Trees have been part of the Unreal Engine for a long time now, while State Trees are a relatively new addition to Unreal Engine, having been added in the last 3 - 4 years. The main difference between these two models is how they operate. As its name implies, a Behavior Tree uses a tree structure with a root, branches, and leaves which the AI traverses in order to determine what behavior to carry out. In contrast, a State Tree uses a state machine based on the State programming pattern, and the AI evaluates only the state it is in and conditions for transitions to other states while the game is running.

When determining which of these models to use when developing gameplay AI, the primary consideration was which of these two models would most likely be in use in the foreseeable future. Given that Behavior Trees have been a part of Unreal Engine for around ten years while State Trees could still be considered a new development, it seemed likely that learning and using the State Tree model would be the most advantageous to an aspiring professional game developer. Thus it was decided that the gameplay AI would be developed using the AI State Tree model.

Designing AI Character Behaviors

One part of the design for this game from the beginning was to include AI characters that respond to sounds generated by the player as part of the puzzle solving process. The three primary behaviors planned for these NPCs were following the player, moving to a specified position, and attacking a given target. Initially, the plan was to develop each command as a toggleable behavior, with the player able to stop an NPC's current behavior and return it to an idle state by re-entering the previous command. This was eventually changed to instead having a cancel command that could stop the NPC's current behavior. The reasons for this change were two-fold: First, it did not feel like good design to require a player to re-enter the last full command given in order to return an NPC to its idle state. Second, it was much more difficult to program the toggling of behavior in the AI's State Tree using the same command. The result of this decision was that the player would have four commands they could issue to NPCs: Follow, Move To, Attack, and Cancel. As NPCs do not react to the Activate command presently, that command will be excluded from this section.

The Wild West of the AI State Tree System

Before explaining how the AI State Tree was built, a major limitation needs to be addressed. Epic Games is notorious for having little to no documentation for much of Unreal Engine's systems and capabilities, and AI State Trees are no different. In addition, finding authoritative sources for how to work with the AI State Tree system was difficult given that the system has only been part of the engine for a few years. This meant that there were no standard, recommended, or best practices from which to start the development of the gameplay AI State Tree in this project. It was only through the kindness of strangers in the Unreal Source Discord server and the Unreal Engine website forums that this State Tree came to be, and it is still unknown at this time how 'correct' the configuration of states, tasks, evaluators, and blueprint logic in the State Tree are in comparison to the work a professional developer with more experience might produce.

Anatomy of an AI Non-Player Character

AN AI Non-Player Character (NPC) in Unreal Engine is made up of several different parts, each contributing to the the NPC's function.

The Character

The character is the representation of the AI NPC in the game. It is made up of the character mesh, colliders, and any other visual components that the player sees when interacting with NPC.

The AI Controller

The AI Controller is a component of the character. It controls the character's movements and actions and provides the character senses such as sight and hearing.

The AI State Tree

The AI State Tree is the state machine housing the logic that the AI Controller uses when making decisions about how to control the character. The State Tree is made up of multiple States, each of which may contain one or more Tasks.

States

States are the building blocks of the State Tree. Each state holds a collection of tasks making up a specific behavior. Examples include Idle, Attack, Pursue, Patrol, etc.

Tasks

Tasks are the actions carried out in a specific state. Each task has a blueprint associated with it that makes up the logic for that task. Examples of this could be moving to a location or attacking a target.

Evaluators

Evaluators are very similar to tasks in that they are actions carried out while the State Tree is running. The difference between tasks and evaluators is that tasks only run while their associated state is running, whereas evaluators run constantly whenever the State Tree is running, regardless of the current state. The primary purpose of evaluators is to get information that the State Tree can use in its various states and tasks.

Breaking Down the State Tree

The image below shows the State Tree used by AI NPCs in the game:

Figure 1: An image of the State Tree used by AI NPCs in the game

States

As shown in the right side of the image above, the State Tree has a Root state and four child states: Idle, Follow, Move To, and Attack. Underneath each state's name are the tasks associated with that state. For example, the Idle state has two tasks, which are setting the behavior state variable in the character blueprint and displaying a debug text on screen in the game.

Transitions

Just to the right of each state's name, there is a question mark (?) followed by an arrow pointing to other state names. The Move To and Attack states also have an arrow with no question mark pointing to Idle. These arrows indicate how the State Tree transitions from one state to another. Arrows with a question mark (?) indicate transitions that occur in response to a state tree event. State tree events are notifications to the state tree with a specific tag to facilitate transitions between states. The image below shows an example of how an event is sent to the State Tree from the character blueprint.

Figure 2: An example of a State Tree event being sent from the NPC character blueprint

The arrows with no question marks to the right of the state names are transitions that occur when a state has been marked as completed. This can occur a number of different ways, but in general a state is marked as completed once its component tasks have been completed. The image below shows all the transitions the Move To state uses to transition to other states in the State Tree.

Figure 3: An image of the transitions used by the Move To state in the State Tree

Schema, Context, and Evaluators

Going back to Figure 1, on the right side of the image in the Asset Details panel is where the schema, context, and evaluators are listed.

Schema and Context

The Schema and Context are two sides of the same coin in that together they supply the State Tree with the default classes that the State Tree uses and provides references to those classes to be used in tasks and evaluators.

Evaluators

As previously mentioned, evaluators can be thought of as tasks running continuously as long as the State Tree is running. They are listed on the right of Figure 1 along with the Schema and Context. At present, the State Tree only has one evaluator, which is used to supply the State Tree with a reference to the player and the distance between the NPC and the player.

Tasks

Each state has tasks that are carried out over the duration of the state. These tasks are all being carried out simultaneously for as long as the State Tree is in the state associated with those tasks. Since the State Tree is a state machine, there are specific events for entering and exiting a state, completing a state, and tick. Tasks can be set to run on each of these events. Much of the task logic runs on tick, because the intention of the design for the NPC was that it would carry out a given behavior until it completed the command given to it, and many tasks require the NPC to continuously respond to changing circumstances. For example, when an NPC is given a command to follow the player, it must continuously check where the player is in relation to itself and then move until it reaches an acceptable following distance. An interesting revelation discovered during development of the AI State Tree was that the State Tree does not have a built-in method for sharing its current state with other classes or actors. This necessitated the creation of a BehaviorState enumeration and a task to set the value of that enumeration on the character blueprint so that the character has the ability to perform different actions based on the current state of its AI State Tree. That task runs whenever the AI State Tree enters a new state. Other tasks used in the State Tree involve the movement or attack actions the NPC will take. The image below shows the details of the tasks associated with the Attack state as an example.

Figure 4: An image of the tasks associated with the Attack state of the AI State Tree

How Does it Work? The AI Character and State Tree in Action

Now that an explanation has been given for the workings of the State Tree and its component parts, an explanation can be given for how the AI NPC behaves in the game.

NPCs are added to the Puzzle Actors array along with reflective surfaces and other actors that are meant to respond to sounds generated by the player. They are also added to a second array called NPC actors for reasons that will be explained later.

When an NPC is hit by a line trace, it goes through several steps to process the received signal.

First, the NPC checks to see if the signal it received was meant for it. This is done by checking the subject portion of the received signal's transmission string against its own ID number. If there is no match, the NPC ignores the signal.
Assuming the signal is addressed to the NPC, the next step the it takes is to check the GUID of the received signal against an array of previously processed signals. This is based on the same logic the reflective surfaces use to limit extra line traces when generating reflected signals and is explained in detail in Devlog #3.
If the incoming signal's GUID does not match any previously received signal, the NPC next looks at the command portion of the transmission string to determine how it should respond. Follow and Cancel commands do not require any additional logic, but Move To and Attack commands require must validate the target substring of the transmission string at this point to confirm that the target is valid. This is also where the previously mentioned NPC Actors array comes into play. Since an NPC could be moving to or attacking another NPC or a destination, it is currently necessary to iterate through arrays for both of those actor types to confirm which actor should be used for the command and whether or not it is valid.
The final step for the character blueprint is to send an event to its State Tree with the appropriate tag for the command it received. There are four tags: Idle, Follow, MoveTo, and Attack. Each corresponds to its respective state.

Once the State Tree has received the state tree event, it transitions to the appropriate state and begins carrying out the tasks associated with that state. It will continue to carry out those tasks until another event is sent to trigger a transition to a new state or the state is marked as complete by the State Tree.

What Does the AI Character Actually Do?

This is where the specific behavior in each state will finally be explained.

Idle

Idle is the default state. In the Idle state, there is only one meaningful task to complete, which is setting the value of the BehaviorState enumeration in the character blueprint, which the State Tree does when it enters this state. While in the Idle state in game, the character takes no visible actions. It is only waiting for a new command.

Follow

In the Follow state, the AI character will attempt to follow the player, stopping when it reaches a distance equalling the acceptance radius of the Move to Target task. That acceptance radius is currently set to 500 units, meaning that the NPC will stop once it gets reasonably close to the player. It will continuously check the distance between it and the player and resume moving if the player moves such that the distance between the player and NPC exceeds the acceptance radius. It will continue to do this until given another command.

Move To

When given a Move To command, will move to the location of the target associated with the command. This could be another NPC or it could be a specific location in the level. When moving to a location, the destination options are limited to locations associated with an ID number. A destination actor has been created to facilitate this behavior. Once the NPC has reached its destination it will automatically transition to the Idle state. While moving, it can be given a new command to either cancel its move or undertake a different behavior.

Attack

After receiving an Attack command, the NPC will move to the location of the specified target and begin attacking it, dealing damage to it if the target can take damage, and eventually destroying it. While it is attacking, an NPC can be given another command to cancel the attack or change its behavior. Once the target is destroyed it automatically transitions to the Idle state.

Final Thoughts

Developing the gameplay AI has been the most difficult and frustrating part of this project so far. The lack of readily available support resources made progress slow and the process of constant research and asking around for guidance was exhausting. However, it is good to see the final product working in the game.

MSc Final Project Devlog #3: Improving Reflective Surfaces and Minimizing Redundant Line Traces

Allen Antoine — Sun, 02 Aug 2026 14:21:47 +0000

This post will examine improvements made to sound reflecting surfaces and methods used to minimize the generation of redundant line traces.

Improving Reflection Modelling

Conversations with classmates about methods for improving the reflective surfaces led to the revelation that the reflection logic had no means of differentiating where other actors in the level were positioned relative to the reflective surface. This meant that regardless of where these actors were the reflective surface would fire line traces at them when hit by a line trace. The result is some rather unrealistic behavior where a sound hitting a reflective surface could effectively travel through that surface to hit an actor on the opposite side of where the original signal would hit that reflective surface. The image below depicts this unwanted behavior as well as the correct behavior for this situation.

Figure 1: An image of a reflective surface displaying incorrect and correct behavior with regard to the location of actors in the level relative to the location of the original source of a sound

To fix this unwanted behavior a check needed to be added to determine whether or not each actor in the Puzzle Actors array was on the same side of a reflective surface as the point where that surface was hit by an incoming sound. To make this check, the Dot Product between the vector formed by the difference between each actor and the original sound's point of impact on the reflective surface and the normal vector for the original sound's point of impact on the surface was calculated.

Getting all of the required values for this calculation required changes to not just the reflective surface blueprint, but also the player's sound generation blueprint and the signal structure used to pass sound signal data between actors. The reason for these changes is that the only place where the point of impact and the normal of the hit can be gathered is in the hit result of the line traces generated by the player in its blueprint. In order to pass this information along to the reflective surfaces, that information needed to be stored in the signal structure along with other signal data. For this reason, two vectors called Impact Point and Normal were added to the signal struct.

The images below show the portion of the player blueprint where the two vectors are passed into the signal structure and the portion of the reflective surface blueprint that handled this calculation.

Figure 2: An image of the nodes in the player blueprint responsible for taking the impact point and normal of each line trace hit and storing those values within the signal structure as variables

Figure 3: An image of the nodes in the reflective surface blueprint responsible for calculating the Dot Product between the vector formed by the difference between each actor and the original sound's point of impact on the reflective surface and the normal vector for the original sound's point of impact

The Dot Product is calculated by adding the products of like elements from two vectors. Thus if vector V = (a, b, c) and and vector U = (d, e, f), then their Dot Product VU = ad + be + cf.

The results of this calculation can be interpreted as follows:

If the value is positive, the actor resides on the same side of the reflective surface as the original sound's point of impact.
If the value is zero, the actor is perpendicular to the the original sound's point of impact
If the value is negative, the actor resides on the opposite side of the reflective surface from the original sound's point of impact.

The end result of this addition to the reflective surface logic is that those actors that are on the same side of the reflective surface as an incoming sound will be targeted for reflected copies of that sound. This has the added benefit of reducing the overall number of reflected signals that each reflective surface will send out, thus making the game run more efficiently.

Maximizing Efficiency with Signal IDs

While working on improving reflection modelling as described above, another opportunity for improving efficiency revealed itself during testing. The situation that revealed it is as follows:

Suppose the player is standing in front of a reflective surface. On the other side of that surface is another actor that is part of the Puzzle Actors array. With the reflective surface standing between the player and the actor, any line trace targeting that actor will hit the reflective surface instead, triggering its reflection logic a second time.

This was undesired behavior, because each time the reflective surface was triggered, it would fire line traces at all of the puzzle actors on the correct side of the surface, and this could cause subsequent reflective surfaces to do the same.

Changing this behavior required the reflective surface actor to have a way of keeping track of which signals it had already responded to in order to ensure it did not respond to the same signal more than once. Allowing reflective surfaces to keep track of which signals it had processed in turn required that signals have a unique identifier and that the reflective surfaces have a way of storing references to signals they had already processed. Fortunately, Unreal Engine already had a mechanism for giving unique identifiers to actors. By adding a Globally Unique Identifier (GUID) structure to the existing signal structure, a unique identifier was applied to each signal generated by the player as well as each signal reflected by a reflective surface. An array of GUIDs was added to the reflective surface blueprint so that each reflective surface could store references to each signal it had processed and cross check the values in that array against each incoming signal GUID before processing it.

The images below show how GUIDs are being added to signals as well as how reflective surfaces are checking these GUIDs to ensure they only react to each signal once.

Figure 4: An image of the nodes in the player blueprint responsible for adding a GUID to each signal struct generated by the player

Figure 5: An image of the nodes in the reflective surface blueprint responsible for adding a GUID to each reflected signal generated by the reflective surface

Figure 6: An image of the nodes in the reflective surface blueprint responsible for cross-checking an incoming signal's GUID against the list of previously processed signal GUIDs

Between the improved modelling of reflections and the addition of GUIDs to prevent duplicate activations of reflective surfaces, the number of unnecessary line traces has been reduced and the game is more efficient as a result. This video explains and demonstrates all of the additions to the project discussed in this devlog:

MSc Final Project DevLog #2: Initial Mechanics

Allen Antoine — Wed, 24 Jun 2026 15:40:07 +0000

This post will examine basic mechanics of the game, from initial inspirations and ending with next steps based off work completed so far.

Inspirations

The initial inspiration for the main mechanic of the game comes from the spellcasting system of the game In Verbis Virtus. This video demonstrates the system in action:

To break down what is shown in this video further, the action of casting a spell in this game can be broken down into three parts:

Enter spellcasting mode
Recite the incantation
Game recognizes the spoken incantation and casts the corresponding spell

Figure 1: A screenshot from In Verbis Virtus showing the controls for casting a spell

Enter Spellcasting Mode

To begin the process of casting a spell, the player must first press and hold the left mouse button or the game pad right trigger. To show that the player is in spellcasting mode, the game shows one of the player character's hands out in front of them in a 'spellcasting pose'.

Figure 2: A screenshot from In Verbis Virtus showing the player in spellcasting mode with the player character's hand out in front of them as a visual cue

Recite the Incantation

Each spell or spell effect has a specific incantation that the player must speak into their microphone in order to cast that spell. There are a total of twelve incantations that can be collected throughout the game. This link provides a full list:

en.namu.wiki

Each incantation is unique and all incantations were created using a fictional language called Maha'ki. This ensures that it is impossible to cast a spell inadvertently.

The Spell is Cast

Once the player recites the correct incantation and releases the left mouse button or right trigger on gamepad, the game recognizes the incantation and generates the spell effect. Some spells, like the light spell, provide a continuous effect until cancelled, while other spells end after their effect has been generated.

Analysis and Takeaways

In addition to being a novel means of control, the voice-based spellcasting system of In Verbis Virtus provides a powerful affordance to the player in terms of the game's usability. Where other games might require the player to move their hands away from the primary controls for movement and aiming (e.g. WASD and mouse), in In Verbis Virtus the player never has to take their hands away from from the mouse and keyboard. This is particularly helpful in combat encounters, because it means the player can always keep their gaze on their opponents and react appropriately to their opponent's actions. This idea of maximizing useability and minimizing hand movement is a core tenet of the design philosophy when designing controls for this project.

Core Mechanics

The core mechanic of this game project is that the player can generate sounds that objects and characters in the environment will "hear" and then respond to if possible. The use of quotes around the word "hear" are there because objects and characters in the game do not have ears like a person in the real world. Rather, their ability to "hear" these sounds and respond is done through an approximation that will be discussed in greater depth below.

The Squawk Box (Working Title): The Source of All Sounds

The source of all sounds the player makes will be a wrist-mounted device found early in the game, which will be called the Squawk Box. This is currently a working title and it may be changed later. The general size and shape of the Squawk Box will be similar to a Pip Boy from the Fallout series of games.

Figure 3: A screenshot of a Pip Boy in Fallout 4

The buttons on the Squawk Box will resemble the buttons on a DTMF keypad.

More information on DTMF can be found here:

Dual-tone multi-frequency (DTMF) signaling is a telecommunication signaling system using the voice-frequency band over telephone lines between telephone equipment and other communications devices and switching centers. DTMF was first developed in the Bell System in the United States, and became known under the trademark Touch-Tone for use in push-button telephones, starting in 1963. The DTMF frequencies are standardized in ITU-T Recommendation Q.23. The signaling system is also known as MF4 in the United Kingdom, as MFV in Germany, and Digitone in Canada.

View on Wikipedia>

Figure 4: A DTMF Keypad

Generating Sounds with the Squawk Box

To generate a sound with the Squawk Box, there are three key actions the player has to take. They are:

Enter transmission mode
Input the desired command to be transmitted
Confirm the command to generate the transmission

Enter Transmission Mode

Currently, the game is being developed for mouse and keyboard and assumes that the player has a full-sized keyboard. The reason for this is because the number pad on the right side of the keyboard is currently where all the controls for transmitting reside. To enter transmission mode, the player presses the Enter key on the number pad of their keyboard. Currently, there is no visual indication that the player has entered transmission mode, but in the future it is planned that the player character will raise their forearm to the camera to put the Squawk Box at the bottom of the screen, similar to how In Verbis Virtus indicates that the player is in spellcasting mode.

Input Command

Following the theme of phone phreaking, every command the player can generate follows a syntax using keys on the number pad. The syntax for commands is:

COMMAND PREFIX-SUBJECT-TARGET

These components together form a transmission that can be generated to control objects and characters in the environment.

Command Prefixes
At present, there are four commands the player can generate. Each command has a corresponding command prefix that makes up the first part of a transmission, and each has a corresponding key on the number pad associated with it. The list below shows all commands, their associated prefixes, and associated keys:

Activate | ACT | NUM +
Follow | FOL | NUM -
Move To | MOV | NUM *
Attack | ATK | NUM /

Subject
Some commands will require the player to designate a specific object or character to execute the command. In all cases, the subject of a command will be designated by a four-digit ID number that will be on or near that object or character. For example, to command a character with ID number 1234 to follow the player, the command would be structured as FOL-1234.

Target
Some commands will require the player to designate a target for a command. As with the subject component, the target component will be a four-digit ID number on or near the associated object or character. For example, to command A character with ID number 1234 to attack a second character with ID number 5678, the command would be structured as ATK-1234-5678.

Confirm Command

Once the player has entered the desired command, the last step is to confirm the command by pressing the Enter key on the number pad a second time. Once confirmed, the command is transmitted by the Squawk Box as a sound or series of sounds.

How Are Sounds "Heard"?

As mentioned previously, objects and characters in the game environment do not have a pair of ears with which to hear like people in the real world. In order to approximate the phenomenon of sound moving through space and interacting with objects and characters, the game uses a system of line traces or raycasts to trigger logic on objects and characters that they hit. The official parlance for this technique in Unreal Engine is line trace, but the term raycast is synonymous with it and may be used in this devlog interchangeably.

Puzzle Actors as Targets for Line Traces

Presently, the current level under development has an array of actors called Puzzle Actors. This array holds a list of all actors added to the level which are meant to interact with transmitted sounds. Any time a sound is generated by the player, this array is used to set targets for line traces which are fired from the player's position to the center mass of each of these actors.

Reacting to Line Traces

When an actor is hit by a line trace, it will trigger any logic it has associated with the transmitted command. For example, a door will open or close in response to an ACTIVATE command. If the actor does not have associated logic for a command, it will do nothing.

Acoustic Phenomenon

One early piece of feedback this project received was that physical phenomena of sound like reflection and absorption should be included and leveraged as puzzle mechanics in the game. This feedback was the main impetus for developing the line trace system currently used in the game. Two acoustic phenomena, reflection and absorption, have been implemented, and two more, diffraction and transmission, are currently in development.

Reflection

Sound waves have the ability to bounce off of hard surfaces. The most common example of this phenomena is an echo. A person shouting into a canyon might hear their vocalizations repeated multiple times as the sound is reflected off the canyon walls. To implement this phenomena, a reflective surface actor was created with special logic that is activated when it is hit by a line trace.

First, it is necessary to set a limit on the number of reflections, because sound will not reflect infinitely--a signal will eventually lose cohesion and energy sufficient to maintain it. The initial limit chosen was five reflections. This number was chosen as it is within the real-world limits of 3 - 18 reflections (citation needed). To ensure that the number of reflections are being tracked correctly, each signal transmitted via line trace has two components stored in a struct--the command itself, stored as a a string, and an array called a signal chain, which is an array of actors. The signal chain has a length of six, with the first index always being a reference to the actor that generated the sound. In most cases, this should be the player, but it is foreseeable that other actors could generate commands like the player does.

When a reflective surface is hit by a line trace, it first checks to see if the sixth element of the signal chain array holds a reference to an object. If it does, then it can be concluded that the signal has already completed five reflections and thus should not be reflected further.

Second, it is necessary to prevent extraneous reflections in order to preserve game resources. Reflective surfaces that are in sight of each other could potentially bounce a signal back and forth between them until it has filled its signal chain array, but it is possible to check for this to prevent extra signals from being generated. Thus, the next check a reflective surface makes before bouncing a signal is to see if the signal chain array holds a reference to this reflective surface object. If it does, then it can be concluded that this signal has likely been bounced back and forth between two reflective surfaces and does not need to be passed on further.

Assuming that the signal chain for a signal received by a reflective surface is not full and the signal has not already been bounced off of this reflective surface, the next step is to add a reference to the reflective surface actor into the signal chain array. To do this, the signal chain array is iterated through until an empty index is found. A reference to the reflective surface actor is placed there.

The final step in modelling reflection is to reflect the signal. After adding a reference to itself to the signal chain array, the reflective surface fires line traces at every actor listed in the Puzzle Actors array except itself.

Absorption

In comparison to reflection, absorption is much easier to implement. Absorption occurs when a surface or material absorbs some of the energy of a sound wave. The amount of energy absorbed varies depending on the material. Hard surfaces like stone absorb next to nothing, but a thick theatre curtain will absorb quite a lot (citation needed). The current design of absorptive surfaces in the game is that they will function as surfaces which absorb 100% of the sound they receive, effectively blocking sound from travelling past them. The only action needed to implement an absorptive surface is to ensure that it blocks all line traces.

Diffraction and Transmission

Low frequency sound waves are physically large, with a wavelength measured in feet or meters. Because of this, low frequency sound waves have the ability to bend around obstacles and they can also penetrate and transmit through obstacles better than higher frequency sounds. These phenomena are called diffraction and transmission respectively, and they form another mechanic currently under development. The idea of this mechanic is that at some point in the game, the player will unlock the ability to generate low frequency signals that will penetrate through a number of actors before dissipating. The initial limit for this is envisioned to be five, but it may change as development continues. This ability will have two main uses: unlocking secret areas and interacting with objects and characters that would otherwise be unreachable. While there has presently been little development on the story or setting of this game, it is envisioned that areas used for maintenance or security purposes would not respond to 'normal' signals higher in the frequency range, and that special low frequency signals would need to be used to access areas like maintenance tunnels or security closets that might be shielded from higher frequency signals.

The videos below highlight the first and second iterations of the primary sound generation mechanic:

MSc Final Project DevLog #1: Introduction

Allen Antoine — Sun, 07 Jun 2026 14:35:47 +0000

As a master's student at Manchester Metropolitan University, I have to complete a master's final project, which includes a dissertation and viva as well as the project itself. I thought it would be a good idea to write a series of devlogs as I go to help me remember what I'm doing along the way and to help bolster the written materials I need to submit. As much as possible, I'm going to write these in academic voice so I don't have to work as much if I want to pull material from here into my dissertation. Without any further ado, here we go:

Project Goal

All projects in the game industry have a goal, and this project is no different. In the case of this project, the goal is to showcase the developer's skills as a sound designer, composer, and game developer in order to attract potential employers and secure a place in the game industry.

Considerations in Reaching the Project Goal

While external help is allowed, this project is expected to be the work of a solo game developer working for ~4 months, thus the following considerations were made in pre-production to allow the developer to exercise the Paretto Principle as much as possible [Note: Find academic reference for Paretto Principle]:

Select an Appropriate Game Genre: With only 4 months, it was decided that certain game genres requiring many programming tasks to complete a Minimum Viable Product would be avoided. In addition, it is easier to create an immersive soundscape in some game genres over others, and this was also considered when deciding what genre of game develop.
Develop with an Engine that Aids the Project Goals: There are many game engines available to the modern game developer, but few of the main engines widely in use by the industry have robust built-in audio tools. This strongly influenced the final decision on which engine to use for this project.
Outsource Assets Outside of Core Competencies: With the developer of the project lacking strong visual art skills, assets like models, textures, animations, would need to be outsourced, either from connections or asset sites like the Fab store, Mixamo, and others.

Initial Design and Development Choices

When taking the above considerations into account, the following design and development choices were made:

Design a First-Person Experience

First-person games arguably offer the best opportunities for realism and immersion in sound design, and for this reason it was decided that the project would be a game designed and developed for the first-person perspective. [Note: Find academic references to support this statement]

Develop with Unreal Engine

Between the three main game engines in use by the game industry--Unity, Unreal Engine, and Godot--Unreal Engine has demonstrably more built-in audio tools, including but not limited to MetaSounds, and the Quartz Scheduling Subsystem. Furthermore, there are pre-built project templates available in Unreal Engine that give the developer a working first-person character with basic controls and animations, which saves developer time, considering those elements would need to be created manually in other engines. In addition, the Unreal Engine can integrate with FMOD and WWise audio middleware for more complex sound and music integration in the game. For these reasons, the Unreal Engine was selected as the game engine for this project.

Initial Game Concepts

In discussion with the program lead, it was identified early on that while the game would be in first-person perspective, the game should not be a shooter game. With so many first-person shooter games already on the market, this genre has been thoroughly explored, and developing an experience that rises to the level of a master's thesis project would be difficult. Thus it was advised that the developer investigate other first-person perspective experiences like walking simulators to see what inspiration could be found. From that discussion, research was conducted to find games that fit this criteria. One game found in this research was a first-person puzzle game called In Verbis Virtus.

In Verbis Virtus on Steam

Use your real voice to cast spells in In Verbis Virtus, a fantasy adventure unlike any other. Step into the shoes of a wizard in search of an ancient power. Explore a lost temple, making your way through forgotten chambers brimming with unspeakable beauty and terror.

store.steampowered.com

The game allows players to take on the role of a wizard and use their voice to cast spells to achieve different effects and solve a number of puzzles and defeat enemies. Watching a playthrough of the game provided considerable inspiration for this project, but there were still several key questions that needed to be answered, such as:

What basic controls (move, jump, run, crouch, etc) would this project use to allow the player to navigate the game world?
What abilities and/or weapons would the player have at their disposal to allow them to interact with the world and defeat enemies?
How are those interactions carried out with physical controls on a computer keyboard and mouse or gamepad?
How could these controls, abilities/weapons, and physical controls tie into the main project goals related to sound design and music?

During brainstorming on these questions a number of parallels were drawn. First, while creating a game that allows players to use their voice as a control mechanism was certainly outside the scope of a 4 month project, allowing players to use sound as a control mechanic could be viable. Second, In Verbis Virtus has a limited number of spells with each spell used to solve specific problems. One spell in particular, the Word of Command, is used in a general sense as an activation spell to control doors and machinery. From this, a parallel was drawn to a similar mechanic in modern and science-fiction games: hacking. In a sense the spells could be seen as programs being executed on objects in the game environment. This lead to the idea of sound hacking, which culminated in the idea of phreaking.

Phreaking is a slang term coined to describe the activity of a culture of people who study, experiment with, or explore telecommunication systems, such as equipment and systems connected to public telephone networks. The term phreak is a sensational spelling of the word freak with the ph- from phone, and may also refer to the use of various audio frequencies to manipulate a phone system. Phreak, phreaker, or phone phreak are names used for and by individuals who participate in phreaking.

View on Wikipedia>

Between the 1970s - 1990s, hackers found ways to manipulate the analog phone networks of the time with sounds generated at specific frequencies. This was most commonly used to avoid paying for phone calls. To do this, many 'phreakers' as they might be called would use a number of different devices, commonly referred to as 'boxes' to generate the tones needed to override the phone systems. Many had a color designation from which could be inferred its specific hacking purposes. From this historical reference, a primary mechanic started to make shape. The player could have a device that generated control tones that allowed them to perform actions like open doors, control machinery, and command NPCs, and these commands would have a certain syntax to them similar to phone numbers.

This was the idea brought to the first group advisor meeting and from that meeting, fellow master's students and faculty provided feedback that unique sound mechanics utilizing physical sound phenomena like reflection, absorption, amplification, and others would make the idea more interesting and mechanically robust.

In DevLog #2: Initial Mechanics the initial development of these mechanics will be presented in detail.

Thank you for reading.