First VR game development

Last thursday, I participated in a competitive 12-hour game jam. Before the jam, since we had a chance to use VR devices like Oculus and Myo, we thought “Hey, let’s make a VR game in 12 hours with zero prior experience in VR game design or development!”. Our goal wasn’t really to make a good game or win the competition, we primarily wanted to get a grasp of what it’s like to develop VR games. But suffice it to say, we didn’t manage to make a “complete” game, even within the standards of a game jam.

The concept

What we were supposed to make was a different kind of castle defense game, trying to integrate the VR devices into gameplay. You are in a defensive position of a castle and your goal is to keep firing cannons to keep enemies at bay, and to prevent your dumb assistants from adding too much gunpowder into the cannons. Your goal is to defend the castle as long as possible, and avoid igniting cannons that have too much gunpowder. In either case, you will lose, and your score is based on the amount of enemies destroyed.

The player controls a first-person character with WASD movement, the Myo controller and Oculus. You use Myo to control your hand that holds a torch, and Oculus to look around, of course. You light your torch with a campfire and start igniting the cannons. If a cannon doesn’t have enough gunpowder when fired, it will not reach the target, and you get no points.

So the concept heavily revolves around the devices that we were using. Without them, it would’ve probably ended up as a bad copy of Surgeon Simulator.


The plan of our production was to get a prototype of our core idea done in about 2 hours into the jam. So we spent the next 2 hours doing anything but the prototype, including trying to get the devices work properly.

About 4 hours in, we ditched Myo. It was buggy and quite inaccurate. We changed the controls so that you can control the torch arm with a mouse.

After we got the new controls somewhat working, we ate and then we had about 6 hours left and even the first prototype wasn’t ready. At this point we decided we are going forward with our current idea until the end and see how much we can get done.

One hour until deadline, we started adding the score system and game loss logic so that we can actually call it a game and not a toy, and started building. The end result looked about as good as most kickstarter projects.

Things that could’ve gone better

I’m just going to list these because it’s probably easier to read that way.

  • Planning ahead. We knew the jam’s theme beforehand, so we could’ve thought about the concept more and get straight to prototype development once the jamming started. We also should’ve arrived sooner to get the VR devices working properly.
  • Ditch Myo sooner. Or, in other words, we should’ve failed faster. We should’ve prototyped faster to quickly realize that Myo isn’t going to work for our game.
  • Take time into consideration. The part that the game jam was only 12 hours didn’t really sink in at the beginning. 12 hours is a very short time for a game jam. But we knew that we had 12 hours right when we signed up for the jam. We could’ve allocated our time better.
  • Juiciness. Even though we didn’t have a fully working game, we could’ve made it more juicy so that it would be more interesting as we presented it.
  • Graphics. This is a minor thing, though. We didn’t really have an artist in our team so we can scrub this off with “It’s engineer graphics, don’t question it.”


This blog post may make the jam seem like a negative experience, but it definitely was not. Sure, our game kind of sucked, but we still made our first VR game. We got a nice concept that we may someday properly produce. We got to play around with Oculus, which is always nice. We got free pizza. And despite the occasional stressing (at least on my part), we had fun, which in itself signals a successful game jam.

Maybe we’ll do better in the next competitive jam, whenever that’s going to be. 🙂