Programming for the Oculus Rift

Virtual Reality has always been a dream of mine since I started playing video games. Imagine not just playing a game but living it. I couldn't hope for anything better. In today's world, that dream is starting to become a reality. The Oculus Rift might not be true virtual reality, but it certainly is a step in the right direction. It is a virtual reality headset, immersing the player in their game world and giving them control over the rotation of their frame of view by turning their head. It's the first piece of the VR puzzle, and this past month I was given a chance to develop a small game demo for one.

Now first time setup for an Oculus Rift is not an easy process, like any other new peripheral. This was made more difficult due to the age of the graphics card I use in my desktop, but once that hurdle was passed the rest fell into place easily. Once the Oculus was connected and working with the desktop I tested it in a few compatible games and demos. This confirmed that the device was in fact working and gave me a better idea of what sort of game would work best with the Oculus.

The first proto-type was going to be a simple First Person Role Playing Game (RPG). The player was easy and setup fairly quickly, but when I tried to add vehicles everything started to go wrong. The Unity plugin for the Oculus Rift does not deal with multiple camera sources very well. Trying to rename the cameras so they were easy to find just ended up with those cameras being ignored and new ones being created under the default name. Linking the camera's directly to a public variable instead of trying to find them dynamically didn't work much better. Now at this point I could have just scrapped the vehicles and gone forward with the RPG, but they were and important part of my game's design. I had also been recently inspired by Elite: Dangerous to try a Space Simulator, so I decided to save all the usable code and changed up the prototype.

My second and final prototype is a simple Space Sim Demo. 6 Stars and one planet make up this small star system. The player can fly around all of them looking for 7 spaceships. these ships can be destroyed with your laser. It takes 5 shots to kill a ship and currently they just circle around their spawn point. I considered making both an aggressive and passive AI, but I didn't have time to tune the them so they were left out for now. The aggressive AI was too good at killing the player and the passive AI wasn't compelling to chase down.

In the end, I ended up with a nice little prototype that can easily be expanded to include more planets, more star types, and better AI. I also learned how to setup a game for use with the Oculus Rift, which was my main goal going into this. If I ever need to make a game for the Oculus again in the future I will be prepared to do so.

Revisiting Multi-threading

Last year I took on a project to add multi-threading to a pathfinding AI simulation. While moderately successful, the simulation ran into problems with the number of threads created when I increased the counter in the function controlling their creation. With the goal of improving this functionality in mind, I took it upon myself to fix it and have a much more robust multi-threaded system.

The reason for the crashes was because the program had run out of memory, but I had thought I had accounted for that case within the program. Turns out my implementation was wrong and stemmed for one simple misunderstanding of how the threads were working. When I created the threads I would detach them until the counter hit max, and then wait for that one to join before detaching more. This is where everything went wrong.

I was assuming each of the detached threads would finish before the one I was trying to join. This was not the case. Detaching anymore than one thread before joining the next caused them to pile up faster than the system was ending their processes, burning through the available memory. Such a simple solution that had avoided me at the time due to my poor understanding of exactly how joining and detaching threads worked.

With my new found understanding of detaching and joining threads I relocated the thread creation and set them up in a better management function. This one allowed all the necessary threads to be created without running out of memory. Now my program could create as many threads as necessary without crashing.