“Scenario Testing” a game engine by misusing an unit test framework.
I don’t post regularly on this blog, but I really should post more… ^^”
If you have ever read me here before, you probably know that one of my pet project is a game engine called Annwvyn.
Where did I get from
Annwvyn was just “a few classes to act as glue code around a few free software library”. I really thought that in 2 months I had some piece of software worthy of bearing the name game engine. Obviously, I was just a foolish little nerd playing around with an Oculus DK1 in his room, but still, I did actually manage to have something render in real time on the rift with some physics and sound inside! That was cool!
Getting the name of an audio device from it’s GUID : Using the Oculus Rift selected audio device with OpenAL
So, while working on my game engine, I was curious about looking at the technical requirement for submitting an application to the Oculus Store.
One of the things required is that you need to target the audio output (and input) devices selected by the user in the Oculus app
[
][2]
So, how does the Oculus SDK tells you what is the selected device?
The Annwvyn Game Engine, and how I started doing VR
If you know me, you also probably know that I’m developing a small C++ game engine, aimed at simplifying the creation of VR games and experiences for “consumer grade” VR systems (mainly the Oculus Rift, more recently the Vive too), called Annwvyn.
The funny question is : With the existence of tools like Unreal Engine 4 or Unity 5, that are free (or almost free) to use, why bother?
There are multiple reasons, but to understand why, I should add some context. This story started in 2013, at a time where you had to actually pay to use Unity with the first Oculus Rift Development Kit (aka DK1), and where UDK (the version of the Unreal Engine 3 you were able to use) was such a mess I wouldn’t want to touch it…