Slow And Steady Wins The Race: Reflections of Turtle Derby VR
This is the third in a series where I document and reflect on my experience building my knowledge in game development, and writing through the process. Think of it as a bit of a diary — entertainment for the learned, therapy for the learning.
It’s been 24 hours since I finished developing my first virtual reality game, Turtle Derby VR. I think I’m ready to talk about it.
This all started when I found out I’d have a day off of work on Friday. That extra day screamed “game jam” to me, but I was unmoved by the thought of making another 2D game on such an occasion. I’d recently rediscovered my Oculus Quest collecting dust on my shelf, so I decided I’d dive into VR development for the weekend with little expectation for the result as I’d failed building to the Quest long before. Still, I was determined.
I gave myself 48 hours. Whatever I’ve got by then is what I’ve got and that’s that.
On Your Mark, Get Set, Go!
First I needed to figure out what I’d actually be making. I set my timer for one hour, and in that time wrote down any feasible ideas with seemingly simple mechanics.
When the hour was up, I outlined everything I would need to implement at face value for each game idea. This includes assets, scripting, audio, UI, etc. After listing the requirements for each game I was able to weigh their development difficulty level and easily narrow down my options.
I settled on turtle racing, inspired by this episode of SpongeBob SquarePants.
Using this episode as a guide, I started by setting up the turtle movement and animations, then added the racetrack and event logic behind the competition. This part was surprisingly straightforward, as it had nothing to do with player interaction aside from determining if the turtle the player bet on was the winner.
It was finally time to face what I’ve been avoiding — implementing virtual reality support to this game.
At first glance I thought it would be as easy as importing the proper integration package, tweaking a few settings, and we’re off to the races (pun intended). This part was possible due to some great tutorials shown to me by my awesome mentor Alexander Kudishov. I was able to quickly fix any errors using those guides, this probably saved me a good few hours out the gate.
My immense confidence quickly faded into concern as I realized my curriculum did not contain any guidance for UI design. I was not prepared for the headaches that lay ahead. Turtle Derby VR relies heavily on UI for player input, so I needed to make this both functional and intuitive.
I couldn’t quite figure out how to get the betting menu to follow the player’s head movements smoothly, so I instead took the kiosk route. In hindsight, this may have been the optimal option. I didn’t want to obscure the player’s view or give them a heart attack by having a colorful menu pop up in their face with no means of escape.
In the past, I used Trello to manage my small projects. Lorenzo Pilia reached out to introduce me to Codecks, a trading card-like project management tool made specifically for game development. Because this was my first VR project I didn’t know what to expect regarding tasks, so I started with a deck I called “Basics” which covered the fundamentals of virtual reality development, lighting, and UI. From there, I was off to the races! (I won’t make that joke again)
One big difference between traditional video game development and VR development is the increased need to account for player actions. It’s important to give your players freedom to move around the scene in virtual reality, so you have to test every square inch of your game to make sure the player doesn’t interfere with the game logic. For example — in Turtle Derby VR, when a turtle crosses the finish line an event is triggered to display the winner on the results screen (also a kiosk, this time due to laziness). If the player decides to wander onto the track mid-race and stand on the finish line, the game logic will implode because there is a non-turtle winner. This is easily solvable, but the difficulty lies in uncovering these small details to begin with.
Whenever I make a new game, I try to improve on at least one aspect of the previous game I created. This round’s theme is sound design. While I’m not one to compose my own audio (I’m more of a royalty-free kind of gal), one of the issues with Wendell’s Extreme Feeding Contest was the jarring cuts in the sound effects/music. Audio spatialization is extremely important in VR to amplify the immersion of the player’s experience. Because of this, I found it to be the perfect opportunity to try my hand at producing satisfactory results regarding sound design.
The easiest way to get the pacing right with the sound effects was to customize them to my needs outside of Unity. I found an audio sample of a horse derby commentator that I cut up into two parts. In the first part, I included a bugle call and starting gun into the track because it was more seamless than calling the individual sounds via script. I did the same for the second part of the audio, which fires when the race ends. This includes the end of the commentary track (announcing the winner) along with miscellaneous sporting crowd cheers.
While I had little time for polish, I did want to add something unique and identifiable to the game. I achieved this by assigning “stats” to the contestants (charisma, day job, speed, and desires) to give them a bit of personality. When a player places their bet on a turtle, that turtle’s stats will be shown on the big screen, sports style (It has now been revealed that I know nothing of sports).
Everything had been implemented and tested, my life was going well. Now all that’s left to do is build the solution and obtain the sacred apk.
As I initialize the final build, a wave of disappointment and anxiety washes over me.
“This is building too slow”, I say to myself.
I’m ready to unveil my latest work and bathe in the glory of adding a completed project to my portfolio.
15 minutes pass. “I don’t have time for this.”
I cancel the build. I noticed miscellaneous add-on plugins that were being imported from the Oculus integration package, some of these I knew for a fact were not being used in Turtle Derby VR. In the heat of the moment, I began deleting folders in hopes that it would speed up the build process and give me my well deserved reward (a working apk).
Once again, my immense confidence took a sharp nosedive into the pits of build error hell. I cannot explain exactly what went wrong due to my reckless actions (most likely a conflict in the package versions when re-importing the files I deleted), but it took an additional 7 hours to rectify. There was laughter, tears, anger, disgust — I felt the entire spectrum of emotions during this debugging process.
A new mantra I’ve adopted after this fiasco is “always dedicate time to building/debugging”. The game jam was originally meant to be 72 hours, but I wanted the extra day to relax so I cut it down to 48, and thank goodness I did or I’d still be cleaning up build errors instead of writing this postmortem right now.
Another mantra I’ve adopted is “don’t go on a deletion spree out of impatience” (self-explanatory).
Thank you for reading this far, you can find me by visiting kazmuir.com. If you have anything to add to this topic please comment below.
