My thoughts on audiogame development today

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.


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? Let me know. Do you agree or disagree? Post your thoughts below.

Published by


Add a comment


@Bryan Smart: I believe that the audiogame market is extremely small, especially because most people are just not willing to support developers. Piracy is one part of it, but even without piracy, as you mentioned, high-costing developers and resources can be problematic.
Written on Tue, 14 Jul 2015 13:15:00 by erion
@Carlos Macintosh: Javascript can be obfuscated quite easily. You can also split your code to multiple files, as needed. @Trenton Matthews: I think sooner or later we will see a number of games based on JS and html 5. It is quite amazing what people can achieve in Javascript these days. @CAE Jones: I certainly see your dilemma. Javascript has changed a lot. New, better and ridiculously fast engines running even other languages such as Lua are very impressive. It will be a bit different, but returning to JS might just make your life easier. @Drew: I will take a look at it, it might be just the next step forward. There is a small movement for Screen Reader access right now, see my Steam petition at Slightly related, my interview of blind mainstream gaming
Written on Tue, 14 Jul 2015 13:12:00 by erion
The situation could improve a bit with online games, since pirating of the client isn't a concern. This could provide greater income than the older games enjoyed, but the drawback is that the investment in time to produce compelling multiplayer online games is much higher than what goes in to even the best audio games of 10 years ago. I'm not sure that even a blind gamer market that was free of piracy could support the work on such a game. Even several hundred blind gamers, paying $4 or so per month, wouldn't be compelling for a professional developer that could be easily making between 5-8 times as much at a day job. The reality, though, is a game of this type would require a full time dev, and perhaps 1-2 others assisting with media and content creation. Can the community love a game enough to collectively pay even the basement price of $7000 a month for it? I wish we could, but I'm doubtful that we will.
Written on Tue, 14 Jul 2015 11:02:00 by Bryan Smart
Low-level support on Windows is improving. Austin Hicks's new Libaudioverse library returns the old DirectSound capabilities, in a completely software-based version. It supports HRTF-based 3D audio, basic environmental reverb, obstruction/occlusion, DSP effects, etc. Many libraries are available for physics, networking, AI, etc that could help in the construction of incredible audio games. However, most all of the current audio game coders are teenage newbies that lack coding experience/math to accomplish anything significant. The experienced coders don't have time or desire to participate. Money is the usual insentive, but blind gamers have prooven to be an extremely small and unloyal market (high piracy of games). Professional coders have mortgages, families, etc, and need incomes that blind gamers aren't able to provide. All that leaves the community are inexperienced children with free time, but who are just learning how any of this works. The results are simplistic games.
Written on Tue, 14 Jul 2015 10:53:00 by Bryan Smart
Have you explored WWise from audiokinetic as possible middleware for audio games? It's as powerful as FMOD and is more accessible, by which I mean it has menus and some stuff reads with a review cursor. Mainstream audio engines like these have made the EAX clusterf$%k irrelevant by implementing their own software renderers; those who do not access these tools appear to be left in the dust. So I don't really think audio games are a niche worth saving, sadly. At some point, though, someone from our community needs to have a serious conversation with the people behind Unreal and Unity about designing accessibility into games. I'm not so optimistic as to say that all games can be made playable by everyone, but I do think there are some steps that can be taken. The deaf, for instance, have been very successful in making subtitles an industry standard; why not push for screenreader hooks as another? That's a relatively small step, but an achievable goal that could lead to much more.
Written on Tue, 14 Jul 2015 10:38:00 by Drew
I appear to have picked the worst possible time to stop spending so much effort on Javascript; my last Javascript game was released in 2008, and uses the embed tag for sound and Active X for SAPI. Now, I suddenly find that Javascript is all grown up and outperforming all the systems I moved to when I left. Huh. The world just will not hold still for me and my slow self. Still, new Javascript looks like a completely different creature, sometimes; I'm not really sure that getting into it would be like moving from Windows ME to XP, so much as from Windows ME to Linux. Hm.
Written on Tue, 14 Jul 2015 07:40:00 by CAE Jones
I would truly be thrilled if "any" HTML5 audio games were made. Especially since I am a daily user of the Chrome Operating System. Choose yur own audio adventures, side scrollers in a jungle or cave. They certainly could all be done using HTML5. Sadly, I am no programmer, though I'd truly be overjoyed if "any!" developer would check out that fine platform.
Written on Mon, 13 Jul 2015 23:26:00 by Trenton Matthews
It is interesting thinking about the prospect of developing a game from within a web site. I'm thinking mostly about the source code. If I code it in javascript then anyone can view the source code right? What about splitting the code into multiple files? Maybe these questions are ones with obvious answers, but whenever I've seen javascript code on web sites it's been really simple stuff, like a hangman game.
Written on Mon, 13 Jul 2015 23:05:00 by Carlos Macintosh