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.

DEV Community: Allen Antoine