DEV Community: Allen Antoine

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.