Doug Binks - 28 Mar 2001 - edited 30 Oct 2013
[This is an archive post about the first version of Avoyd which we now call Avoyd 1999. The full game is now free to download.]
Things are going well with the Avoyd demo, and to our knowledge we now have over ten thousand downloads from the various sites which have counters on their download pages (combining versions 1.0 and 1.1 but excluding the patch). We think this is pretty good going for a small game from a small company with a small budget, and hope that it bodes well for our commercial release.
A recent email to us concerned whether we'd release the Avoyd game engine to the public. There are many ways we could do this, and I thought I discuss them here, along with the pros, cons and likelihood of them happening.
Open source: By open source we mean releasing all of the source code to the public using a license which allows them to alter and distribute the source as they wish (though potentially with restrictions such as the GNU license gives, which forces you to release your source and changes under the same license). Open source software is a great thing, but I am unsure about it's application to game engines. I believe the best areas for open source are in tools (such as editors), standard services (http servers, operating systems), and standard based libraries (jpeg image libraries, OpenAL). These three types of code have in common that the programmers involved get something directly back for their effort, that they are best developed by common agreement (thus software based around standards is great for open source development), that the market for these products is slow moving, and that the core activity of the person or business is not the development of the open source software. Open source is, I believe, a form of outsourcing in which you maintain an involvement. It is (in economics speak) a planned economy of software development rather than a market based one. The internet allows this planned economy to run with low overheads and near instant response to demand, though for tight feedback it is best that the programmers actually need to use the product in some way. A good game requires passion on behalf of it's developers, novelty, and a unity of vision hard to develop using open source techniques. For us, our core activity is game programming (note: not game content creation, as we develop much of this algorithmically). To give our source away would lead to a dilution of the vision and novelty of the game, as I (as only full time worker here at the moment) would have to find another way to pay for my lunch, and because I would have to give equal attention to the ideas of others as to those of myself and our small design team.
Licensing: We could potentially offer a license to developers interested in using the engine, but to do this properly requires support. Given our present size, we just can't afford to lose the time at the moment. This is, however, an interesting possibility which we may pursue in some way in the future.
Mods: Many games, such as the Quake series, offer the user the ability to extend the core engine, allowing people who have bought the full game to play these extensions. This is the most likely scenario which we will consider. Indeed, a significant amount of the game will be modifyable in a point-and-click manner (after all, the environment or 'map' can already be easily modified from within the game). As the game develops, expect to see greater freedom for expression using the game. Our hope is to be able to allow gamers to extend the game using freely available tools (or ones provided by us with the game). Initially, however, our prime goal is to bring the playability of the game up to the highest possible standard.
Another email asked us if we'd port the game to the BeOS (which we were offered assistance with). At the moment we're not yet ready for porting to other platforms, as there are still some critical changes going on under the hood. However we are interested in making Avoyd as widely available as possible, and the game was designed with portability in mind. We'll be looking at this issue more closely in the future.