My most important recent project, and my Masters Dissertation project, was the development of a game based around the classic arcade game Whac-a-Mole. This was a very involved project, and encompassed a wide range of development skills – but the twist was that it was all developed as a Virtual Reality experience. Here’s a video showing the game in action:
The game went through several stages of development due to the complexity and depth of the project. Tools used throughout development included:
Unity 2022.3.29f1 as the main game engine
The XR Development Toolkit package for Unity as the main framework for VR Interactivity
A Valve Index headset and controllers as the main testing device
Jira for project management
Git and GitLab for file uploading/version management
Visual Studio for programming
Material Maker for surface texture creation and basic photo editing
Blender for custom 3D modelling and texturing of those models
REAPER for custom sound effects
Initial stages involved preliminary planning and general game design, using Jira and documents. I also did a lot of research to not only learn how to use the Unity game engine but also to understand VR design guidelines. In particular, time was spent researching means of avoiding motion/VR sickness; ideally the game would work as a good introduction to the medium!
Development was initially focused on getting a Unity project ready, as well as installing packages such as the XR Interaction Toolkit (which acted as the backbone for most of the game’s VR functionality). After this I experimented with Unity itself; much of this was a learning exercise in how to use Unity and its VR tools – physics played an important part here.
After experimentation was done some basic prototypes of game systems were then ready to be expanded upon. Systems included:
Movement systems that include teleporting around the area (with or without a fade-to-black “blink” effect, to help mitigate motion sickness), turning side-to-side, and free continuous movement for more advanced users.
A hammer that can be picked up, has hit detection for “moles”, and respawning it at a side table if it’s dropped/lost.
Timed “mole” targets the player has to hit with the hammer, with different variants for added challenge (regular ones that give points, bad ones that deduct points, and faster gold one for bonus points).
A table that contains many systems including:
A menu to start the game and with a list of previous high scores.
A handle that can be used to adjust the table’s height.
A system that starts the game with a countdown, and creates targets in random spots while the game is active with a timer for 60 seconds.
A score tracker that updates scores when targets are hit and updates a score display.
Once the 60 second timer runs out, a system that stops the game, tallies the final score, and updates the list of high scores.
A system to prevent hovering the hammer on the table, as an anti-cheating measure.
An options menu that can be interacted with “laser pointers” from the player’s hands. Options include an audio slider, player height input, and movement mode options.
A tutorial system to run the player through the game’s basic controls.
Various management systems including ones for playing sound effects, saving important data, and failsafe teleport systems that recover anything that falls out of bounds.
Once these systems reached a fairly finalised state, one of the more interesting phases of development begun: the creation of custom assets. These were made to help give the game its own unique style and theme, rather than relying solely on pre-made elements. This included models, textures for those models, textures for the environment, the occasional custom shader for special effects, and a great deal of custom sound work.
Custom models were an important element, creating a unique aesthetic for the game. The style was generally kept cartoony and light to make the game pleasing to see and accessible, while still making sure important elements were given appropriate visual detail/highlighting. This included Whac-a-Mole tables, the targets that pop out of them (each given a distinct silhouette), the hammer the player picks up, the table the hammer appears on, and a tutorial blackboard showing off the basic controls. Modelling was done via basic hard-surface techniques, and materials for these textures were also made procedurally with Blender’s shader editor.
After the models were done, a couple of basic environmental textures were made for the walls/floor of the playable area. Since the level was kept very simple to provide focus on the important Whac-a-Mole tables, these textures were also kept simple, though given a little detail with normal maps and the like to help improve the aesthetic.
Some custom shaders were made with Unity’s shader graph editor, namely a glowing highlight effect for teleport locomotion elements (such as anchors the player can teleport to or the visual highlight showing where they will end up).
Finally, and arguably most importantly, custom sounds were made. The primary mixing was done via REAPER, using its helpful region system to batch export multiple variants of sounds as OGG files. Sounds were created for all important in-game events, such as: menus interaction, hammer interactions, targets appearing/disappearing, targets being hit with variants for each type, the table’s countdown timer and score events, and miscellaneous events such as player teleporting or hammer respawning.
These sounds proved to be an important element of the game, as they not only provided instant feedback for in-game interactions, but helped to improve the sense of tactility the game had (swinging a hammer and hitting something only to be met with silence is terribly underwhelming!). When all the sounds were implemented in-game, playing at a Whac-a-Mole table felt instantly more enjoyable – targets popped up with clunks and clacks, hitting them created a thunk and jingle, running out of time is immediately noticeable once the timer starts beeping, this and so much more.
With custom assets made and some additional tweaks made to the gameplay to accommodate them, the game was reaching its final stages. The main thing left to do was test the game with actual playtesters, who were introduced to the game and asked to play through it with no further input from myself.
Players were generally quick to pick up the game’s controls and enjoyed playing at the Whac-a-Mole tables. They did also provide areas of improvement (such as tweaking the tutorial, adding better indicators for scores gained, and more), which was all noted down and with further changes made wherever possible (although only so much could be done with the project being very close to finishing). After the testing, some final adjustments were made to the game and the actual report for the dissertation was completed.