Vault Raid

Development Process

Pre-production

I didn't take too much time out of the week for pre-production, but still felt that it was important to help establish Vault Raid's theme and the core mechanics to implement. Most of my time was spent deciding on the main premise, along with collecting reference images from multiple FPS dungeon crawlers and dystopian/brutalist style sci-fi media to use when it came to designing the level and finding textures to use (all credits for assets used can be found on Vault Raid's Itch.io page). 

Additionally, I used this phase to experiment with what engines would be feasible given my limited computing resources (an underpowered Dell laptop with an i7 7th gen & Nvidia 930MX at home, and the lack of ability to install new applications on college computers). I originally wanted to use Unity, given it is lightweight enough to run on my laptop, but found that my college's PCs did not have Unity installed, and with my desire to exploit the much more powerful GPUs & CPUs of the college PCs for baking the game's lightmaps at a much faster speed than on my laptop I decided to go with Godot. With the engine's editor being even more lightweight than Unity and not requiring installation to run, it felt like the best choice given my circumstances. Unreal Engine was never seriously considered due to how resource-intensive it is to run.

Production

A lot of my early time while making Vault Raid focused around designing & implementing the more "mundane" systems. My first two days didn't even focus on the game itself and more on implementing a menu system I had made for an unreleased game project then subsequently improving upon it. I tried my best to design it with modularity in mind, although the scripting behind making settings save permanently between play sessions had to be bodged together due to time constraints. The issue wasn't saving settings (that was done quite easily with Godot's config file system), it was having them set upon loading the game. I ended up placing the settings nodes (with their visibility turned off) behind the main menu screen and having a script fire upon loading the game that reads the settings config file and applies settings accordingly using the hidden buttons.

The next focus was setting up the game's enemy AI. Like all good game engines, Godot provides developers with a navmesh & pathing system for both 2D and 3D projects, so it was a simple as creating a navigation mesh for the game's map (once that was designed) with obstacle objects placed accordingly for static obstacles that actors might run into (like the pillars seen in room two). Scripting enemy path-finding wasn't too difficult either; actors have an "area of sight" that extends in a set radius from the actor. When a player enters this radius, actors will start moving towards the player's location until they leave the actor's sight. Rather than immediately stopping, I had actors move to the last location the player was seen in. This allows for actors to regain sight of players even when they've initially left the actor's area of sight, making enemies more difficult to fight. 

I designed the main level of the game within Godot rather than modelling it in external software like Blender mainly as a time constraint, as working within Godot allowed me to add the map's collision as it was designed, making it the faster option. Given that I was not focusing on the game's looks, I felt it was an acceptable shortcut. The biggest downside of using Godot to design the map was that each mesh object's UVs were separate meaning that textures would not apply correctly and would look disjointed.

Throughout the 4 days I spent on the game's production I would temporarily jump between my main focus at the time and scripting player mechanics as the game developed. Originally, I thought that a slow player with slow enemies was what I was aiming for, but after playtesting the game I felt that a higher speed felt more exciting and fit more with the premise of "raiding" a vault. Player health was also originally much lower (being killed in just two hits from an enemy). My own playtesting (along with feedback from friends who tested the game too) revealed that this felt incredibly punishing, thus players can now sustain 5 hits before dying, and are healed when killing enemies. Implementing the gun that players used was probably the most difficult and annoying mechanic out of everything I had to do. The initial issue was getting Godot's line trace to work. Once that was fixed it was properly centering the player's crosshair before finally finding a way to implement a satisfying muzzle flash (I ended up with a tacky particle effect that I would definitely replace if I was doing this over again).

Postmortem