My thoughts on audiogame development today

July 14, 2015

Programming was always a hobby of mine. There is just something in it that fascinates me as a project slowly grows into the form I always imagined it to be in. Of course, there is also the matter of creation: perhaps not consciously, but all programmers enjoy the power of it.

The post has been updated to include OpenAL shortcomings.

===

##The starting years

It was in late 2003 when I discovered audio gaming. Needless to say that I just had to try my hand at creating some. It also helped that, by chance, I met a fellow artist who wanted to learn programming from scratch.

##The happy years and concerning changes

We learnt the ins and outs of Visual Basic 6, which was powerful enough to bring our ideas to fruition. All was good for a few years, our games were praised for their creativity, while having some unique and innovative features. We were part of a thriving audiogaming community.

Life is a rollercoaster, say many, which was certainly true for us. Changes caused us to focus less and less on audio games, creating and playing included. The end of Highschool, university and other things rapidly entering our life were the causes why we decided to put things on hold in mid 2008. Thinking back now, I am certain that we should have been able to continue, but things would have been a lot harder, with a game quality degradation that we did not want to push for.

The following years saw hardware and software changes for Windows. Some of these were quite concerning for audio games, such as Microsoft dropping support for their hardware acceleration layer, essentially dropping hardware rendering for 3d audio for any application using DirectX. As DirectX was the standard for any serious audio-enabled application, this was a quite significant impact.

I have to stop here for a moment, because I hear you arguing that “Yes, this is true, but 3d audio was rarely used.” This is without a doubt, however I have to point out that any game where objects can be behind a character will sound flat without 3d audio. A gamer should be able to tell where objects are located in space, without having to resort to pitch or volume changes. A game should be as immersive as possible, rather than a very simple sketch.

##Dragonflame

Sometimes we have a spark which we choose to act upon. This is what had happened to me with DFE (Dragonflame Engine). The concept was that the engine should provide a base for anyone who has Lua knowledge to start making audio games, without having to worry about things that are present in audio games, such as audio and input handling, menu creation, forms, network, speech, etc. I was particularly motivated to do this, as game developers were not quite keen on sharing code with fellow developers, thus every fledging developer had to figure a lot of things out on their own. This is not necessarily bad, but imagine what wonders a concept like this would do to science. Charming, right?

##Problems, problems and more problems

I was working extensively on Windows for all these passed years, sometimes looking into technologies that would make DFE a better engine. I, for example, spent countless days looking for a suitable audio engine which would provide 3d audio, as well as spacial reverb. OpenAL soft and unity’s audio engine are currently the only working ones, while there are a lot of stereo variants which do not have reverb.

Unity’s accessibility is currently just a dream, while OpenAL soft provides the very minimum needed to process audio. Anything extra, such as streaming ogg Vorbis files from disk or from an encrypted file are up to the developer.

Update: On top of that, OpenAL has its own problems, see here

I had to accept that for now, there is no easy way of implementing reverb or 3d audio. Easy, as in having extensive audio engineering knowledge or spending a significant amount of my time implementing anything passable. This is quite sad, especially for an audio game engine.

Let’s continue with input. Keyboard is the easiest part, however implementing mouse and joystick are not quite so. Random bugs which were not fixed for at least a decade are still present, such as DirectX failing to acquire the mouse when the game window takes focus, or failing to unacquire when the window boundary is reached. I am not even talking about handling buttons and how a more than 3-button mouse is handled, this is simple mouse movement.

Joysticks and other input devices are even more tricky. Remember the software changes I mentioned earlier? Microsoft decided to support xbox and x360 controllers on the pc, while dropping support for DirectInput-based joysticks and devices. Even so, Input devices are still visible via the DirectInput API, where they may or may not work properly.

Analog triggers, for example, will certainly not report their proper state, as they will act as a button having an on and off position, rather than a scale, according to the pressure a gamer might apply to them. As a result, these Input devices must be filtered out, without DirectX providing any helper tool, as there is absolutely no way of reliably identifying an XInput device using DirectInput. Furthermore, XInput does not see DirectInput devices.

Workarounds and more workarounds just made me realise that perhaps Windows is not the right platform.

As a result and since it is quite unlikely that I would seriously contribute more to Dragonflame, the complete source is now available. Use it, learn from it and most importantly, contribute to it! The latest version, roughly a somewhat changed variant of the latest beta can be obtained from this Git repository

To contribute, please contact me for an account.

##Audiogaming today

No matter how biased we are, audiogaming nowadays is quite bleak. Here are possible reasons why:

A considerable number of developers have stopped developing audio games. Some due to a lack of free time, some because of family issues, or because of various other reasons.

Most of the people making audio games nowadays are very young. Due to a lack of code sharing and/or proper education, the same audiogame quality would be too much to expect, not to mention that they do not have roots to go back to.

As a result, most new games we have now are largely reusing concepts of older games, based purely on gameplay experience. Even legacy games are getting degraded due to operating system changes. Shades of Doom, for example, had to implement new audio cues and make up for the loss of 3d audio.

I have to mention though that there are some exceptions, Japanese audio games being an example, with an incredible amount of content that will entertain for hours.

##My Attempt

Because we are playing the same side scrollers, space invaders, grid-based or even simpler games over and over again, I believe that gameplay needs a change. My first, hopefully not last, attempt was AngelGift. Focusing a lot more on a cinematic atmosphere and on a story which can be motivation enough to go back to a game, this might be a way of shaking up all the developers to think out of the box, to invent something unique and creative. It certainly a great feeling when you can say after finishing a game that “this was never attempted before,” however it does not mean that we’re at the end of all things. I have quite a lot of things to show and believe me that I will try my best to make every game just as good, if not better, as the previous.

##What next?

While audiogame development is mostly halted at best, at least for Windows , there are a number of ways how we developers could make it a thriving endeavour again. An increased use of mobile platforms, for example, cries out for cross platform, possibly mobile audio games. This seems to support my belief that Windows is no longer a platform worth developing for, not as a solo platform anyway. But let’s view what other platforms we could develop for:

Since my recent acquisition of a Mac, I am mainly an OS X user and I have to admit that CoreAudio could be the future. It has 3d sound, smooth reverb, is relatively painless to use, it has everything I’ve always wanted. The only flaw in this joyous plan is that there are significantly more Windows users, some, for some extremely odd reason, go as far as using only Windows on a Mac.

Linux is possibly a solution, but geeks would certainly have to act as the Cybermen, to convert all non-linux users. While I would certainly appreciate, even help their efforts, this would be too much of a sacrifice just for the sake of audiogames.

Android’s audio is just not there, while IOS would certainly work, however we would see a lot more commercial games to make up for the yearly developer fees.

What is the solution then? I believe it is the web. It is a universal platform which works equally well on all operating systems, as long as we are aware of the strengths and weaknesses of the various available browsers. It works everywhere, be it desktop or mobile. Are you willing to learn Javascript to have powerful features at your fingertips, such as joystick and force feedback support, the ability to use your microphone, universal speech that works everywhere and much more? Do you agree or disagree? Let me know!

Tags: audiogames development programming