Of the stagnation in audiogame development techniques in the second decade of the twenty-first century: Why should we move on to new tools?

Anyone who has developed an audiogame in the last few years will surely have heard of The Blastbay Game Toolkit (BGT). In Blastbay Games’s own words, “BGT is a toolkit that allows you to create your own audio games from the ground up using a simple scripting language coupled together with a powerful game engine”.

BGT has been used in the creation of a huge number of games since it’s release. Many people have learned it as their first programming language and, in the last couple of years, it has seen a few quite interesting external libraries.

In the last couple of years, though, we have also seen a lot of unjustified bashing of BGT. Many people have started to simply talk about how “bad” BGT is with no reason or rime. I myself do think that developers should move on from BGT and, in an attempt to appease those who rightfully ignore the people who cannot justify their complaints, I will try to point out a few of the aspects that, in my opinion, make BGT worthy of disappearing off of the current audiogame market.

Audio System

Possibly the most important issue of BGT, and the most ironic, is it’s extremely rudimentary audio system. For years now we have had technologies that allow us to implement environmental effects and 3D audio into programs on any platform. Of course, different platforms have different ways to handle this. In the case of BGT, though, this fact is negligible and poses the big question: WHY, oh, why does an engine made specifically for the purpose of making sound-based games and only sound-based games, the main focus of which should most logically be offering decent sound support, have the feature set of… I was about to say a sound card of the early 2000s, but in fact, HRTF technology was unveiled in the 90s!

I think it is quite ironic that this fact still remains true and nothing has been done about it even in the latest free update. This, in my opinion, is the biggest reason why BGT is not a suitable game development platform in 2018.

Built-in Feature Set

BGT is being marketed as a simple way to create games and learn programming. A lot of the built-in modules, though, do not have much to do with the creation of games, and the amount of built-in helper modules is quite disappointing. The so called “sound-pool”, which wraps simple stereo positioning of audio elements based on a coordinate system, is extremely basic. While having helper modules is most definitely not required, it is something you would expect from a product which has such a specific purpose.

The community

BGT was created, as they say, “by the blind and for the blind”. It has one very specific purpose: the creation of games with audio and only audio elements. This instantly reduces the possibility of an expansion of the BGT community.

A very important part of a programming language is the community it builds around it. Programmers should aim to help fellow programmers and should be able to use as many resources as they can find. I can almost safely say that any current programmer does not hesitate to check Stack Overflow whenever a seemingly unsurpassable challenge or a simple doubt arises in their coding sessions.

While BGT’s community has shown to be helpful at times and certain programmers provide packs of libraries and utility functions for the masses, it is also incredibly small and limited. The use of a mainstream language eliminates a lot of these issues.

Official Support

Closely related to my previous point is the fact that BGT was pretty much discontinued and abandoned by Blastbay. The previously quite expensive program was released for free a bit more than a year ago and there seem to be no plans for improvement. And yet, it is still being used extensively for many new audiogame releases. I don’t think this requires further explanation.



Ever since the first version, BGT has had warnings in its documentation about the lacking support for dynamic link libraries. For example, to my knowledge, there is still no support for C structures. This limits BGT developers quite a lot and, given the limited built-in feature set I mentioned earlier, this is a real problem and causes frustration while promoting dirty ways to achieve goals. There are huge amounts of readily-available libraries on the Internet to achieve many useful purposes, and BGT simply does not allow the average programmer to dive right in and use them, which is definitely what something aimed at simple game creation should try to do.

Platform Support

There has been a lot of talking about this specific topic on forums every single time a BGT-powered game gets released. Many people use devices other than Windows computers, and BGT is only able to compile for that specific platform. While some games can be adapted for other platforms, such as through the use of Wine, this is not an ideal approach, especially now that mobile platforms are rising in popularity.

And more!

  • No actual built-in dictionary/hash table/map datatype (no, BGT’s dictionary is not how things work)
  • Unnecessarily confusing compilation errors, especially for new programmers
  • Insufficient facilities for game debugging
  • Executable size (the smallest possible executable seems to go over 800kb and include part of the original source inside)

Sure, alright, complain all you want. So what can we use?

There are definitely many options to switch to, but I definitely know which one I will support.

Many of you will have heard of both Dark Defender and Cyclepath. Both of those games are written in JavaScript, the standard language for web scripting, and run under modern web browsers such as Google Chrome and Microsoft Edge. JavaScript is surprisingly easy to learn, well-maintained, and has a ridiculous amount of extra material available for users. With the release of Node.JS came the [Node Package Manager (NPM)]http://npmjs.com/) which is one of the largest repositories of code libraries out there. While I am not saying this system is the panacea for the audiogame development ecosystem, Using a JavaScript-based environment addresses a lot of the issues I outlined:

  • Audio System: Any modern web browser has support for WebAudio, which instantly gives developers the possibility to use modern technologies such as HRTF and environmental effects quite easily, especially with the help of wrapper libraries.
  • Built-in Feature Set: While JavaScript in itself is just the scripting language, coupled with the browser, Node, or any desktop application framework, such as Electron, JavaScript’s built-in feature set is… Big. And even without that built-in feature set…
  • The Community: The number of people working on JavaScript-based projects is simply huge. NPM is full of interesting packages, and it is not hard to add new ones to it, which is why, if we expand our horizons and start using it more, audiogame-related packages could easily be created and uploaded to the repository!
  • Official Support: JavaScript is in active development together with the browsers and Node.JS which it relies on. It has been the standard for web development for a number of years and it looks like it will remain that way for a while.
  • Extendability: A huge amount of external libraries are available on NPM. Node.JS and Electron can easily integrate external libraries into any application.
  • Platform Support: Any modern browser on any modern platform, including mobile devices and even consoles, supports JavaScript. There are Node and Electron binaries available for the major desktop OS’s.
  • And… More!


With this post, I am not trying to say javaScript is the only and/or best solution, and neither am I saying BGT is the worst. As always, this post is meant to reflect my opinion and nothing else. Some people will disagree with me, and some will agree. I tried to support this post with objective facts in hopes that it will serve as a starting point for what, in my understanding, is a long overdue change in the general audiogame development strategy.

As always, thank you so much for reading!


2 thoughts on “Of the stagnation in audiogame development techniques in the second decade of the twenty-first century: Why should we move on to new tools?”

  1. Afaik, builtin js (without any module gotten from npm) is so minimal that people need to get into an absurdly large chain of dependencies, dependencies of dependencies, dependencies of dependencies of dependencies, etc. Maybe this doesn’t apply to our particular niche, though.


    1. in fact, browsers and V8 do provide many API’s that give JavaScript a decent standard library, though as you did say, it does make itmuch easier to add packages from NPM.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s