Welcome the 1st update for Damocles VR, a FPS Tower Defense set during an alien invasion. These updates will run alongside the devlog to talk about the technical issues I’m encountering, what I’m working on currently as well as any ideas I’m currently thinking about as well as help links to resources I find useful. These updates will be as frequent as milestones I hit, but I will strive to do one a week but it might be a little more delayed as the project gets more mature. So let’s dive right in and get under the hood.
Whenever I start a project I always try to put to paper what it is I am working on, so usually the first thing I crack out is the Game Design Document (GDD) as that gives you a really high level view of what the game will be like. I tend to go for a One Page GDD that you can find here (there’s a backup of my version on my Drive you can find here) as that lets you define the really big chunks of the game first. This one page document really is a 10,000 foot view of the game you want to make, the general idea of what it will be (and won’t be) but don’t feel compelled to adhere to it slavishly, as your vision and how the game feels as you make it will lead to changes.
When writing the GDD it is important to document why you’re making the change you’re making and more importantly to not add any features until you either remove a feature or have completed the ones you have. My rule of thumb is that after the first month of development, I won’t add major features to the GDD until I essentially feature-complete what I have which is usually much much later. That is usually sufficient time for the scope of small projects to determine if the feature set is viable, still works with what I want to make, and otherwise fun. This helps avoid feature creep as well as gives you a tight framework to operate in. That’s what works best in my case, find what works for you and then just stick with that, everyone has a different process and you will go through multiple projects before you really find your workflow.
So after completing my GDD and having a general idea of what I want to work on, I typically start by working on the main game space. Since Damocles is broken up into two pillars, the Bunker and the Topside I try to start with the harder of the two which would be the Topside. The Topside is really broken into a few distinct parts and this break up makes it much more digestible to develop and ultimately design. So off the top of my head this is the Player, the Defense System, the Weapons, the Enemies, and the Objective System. Each of these has sub-components but this is the Minimum Viable Product for the prototype. This ultimately may not be the final list but you have to start somewhere and as you complete more and more projects you have a good frame of reference for what you need to do based on your previous work. If you’re truly stuck, it’s often helpful to play games you want to emulate or feel inspired by to see how their systems work, just pull apart their mechanics to see how they’re structured to give you an idea on how to structure your own project.. The more you can think about these systems the better you will be in the execution, avoid potential pitfalls and generally have smoother development experience.
Longest part of setting up this scene was just picking out what I wanted.
Since this is a VR title I am relying heavily on the Virtual Reality Interaction Framework (or VRIF) asset off the Unity Asset store. This is made by Bearded Ninja Games (you can see the asset here) and they are incredible in the level of support and responsiveness to questions/issues. If you can part with the cash, you can hardly find a better deal in VR development tools. VRIF helps immensely with the heavy lifting of interacting with Oculus/SteamVR API which drives the majority of player interactions as well as having a ton of absolutely insane helper scripts to make it so easy to make a VR game.
The other asset I’m using is GameDevHQ’s Filebase which is a one-stop shop asset marketplace (you can find them here) similar to the Unity Asset Store, it integrates directly into the editor and allows you to import models on the fly. The benefit of Filebase being that for a single annual cost you get a whole slew of game-ready assets such as the buildings or props (as well as enemies and weapons! They seriously have butt-loads of stuff) you’ll see in the following updates but if they don’t have it then their art team will create it if the request is reasonable. It’s a real time-saver in terms of prototyping and I could easily see myself creating an entire game with their asset library, there’s also an incredibly helpful community surrounding GameDevHQ that really tries to do their best to assist. They offer courses and do weekly live-streams as well as tutorials, so check them out if you get a chance you probably won’t regret it I know I haven’t.
With VRIF and Filebase set up I decided to work on the first iteration of the Arm HUD UI system. I make a basic scene with a simple landscape using Unity’s terrain tool, a few buildings and trees from Filebase, and a free desert texture from the Unity Asset store. I always find it nice to spruce up a scene before working, you’re gonna be spending a lot of time in the space so may as well make it nice to look at. Now down to brass tacks I start with a basic UI Manager, this will control all of the buttons, activating and deactivating HUDs for both the arms and later on the menu screens. It’s usually easy to keep this all in one place. With the Manager in place I worked on the physical aspect of the Arm HUD. Using VRIF is a breeze, after parenting some basic cubes to both arms I take one of the Button prefabs provided by VRIF, and parent it to the Cube and lock it into place, I also parent a Canvas to the arm HUD and implement some dummy buttons to test the functionality.The Button prefab already comes with a helper script attached (called Button no less) that fires an event on Button Up and Button Down that you can wire up to another GO in the scene, it also includes other help features like a sound effect when you depress and release the button. In this case my UI Manager which will oversee all of the logic driving the canvas UI on the HUDs themselves, but I only need it to activate after the Button comes up which seems to be working. I replicate the same on the other arm, telling the UI Manager to activate the parented Canvas object when the button is clicked and deactivating it when the button is clicked a second time.
Click. Click. I’ll add a rotation and gaze check to hide it when not needed.
That was quite a long post, I’ll try to keep the following ones quite a bit shorter. My current plan is to show off an update every-time I complete a major mechanic of the game. This may be week to week or several weeks between updates. If you made it this far, thank you for reading and see you next time.