I was reminded recently of the amazing art of the “demo scene”, which (to use a rubbish metaphor) uses computer programs to paint fantastic images on our screens using whatever the rendering technique of the day happens to be. Things have moved on a lot since the old days when a copper bar backed scroll text or sprite animation played in time to a soundtracker module amused us on the Amiga or Atari ST. A 3D spinning cube or BSP maze was pretty amazing on the Atari ST (especially if one had an appreciation of its graphical limitations), but in retrospect they actually proved to be a driving force in advancing and sharing a common understanding of what the hardware was capable of. I can think of all kinds of rendering techniques that are now considered standard fare, but have at some point been presented in demo form to whet our appetite for future hardware capabilities – specular lighting, 3D geometry, environments, voxels, fogging, alpha blending, 3D particles etc. etc.

So when I stumbled upon a link to some of the latest demo scene videos I was blown away by some of the 2minute long audio & visual experiences being created from programs only 4096 bytes long. I also realilzed how amazing it must be to have such an unbeliveable amount of processing power and flexibility that’s available on the current generation of pixel shader capable hardware. It’s surely a true artform, and I for one take a great deal of inspiration from it.

The trouble with middleware in the games industry is that there simply isn’t enough of it. Software engineering is generally difficult and costly but making games has the added shifting sand of generational software and hardware cycles, where the ‘old tech’ has to be constantly iterated, re-factored or even re-written just to ensure the studio’s next game can compete on the technology front.

Now I’m not saying that game companies can’t continue to make games and build internal tech but it does feel like as an industry we’re spending a disproportionate amount of time building tech instead of delivering content, and it is costing every single development business a lot of money to sustain, which ultimately means reduced profitability for the industry. We know that even the teams with mature internal tech need to continue spending money on engineering just to keep up with the development cycles, and I’m sure there must be a scale of economy for such a model, ie. one central tech team can help 4-5 game dev teams deliver their games, but I’m still not convinced that there’s big savings here considering the generational pace of technology. Building a AAA engine from scratch these days must be an enormous investment, and not necessarily guaranteed to improve the situation.

My utopian future vision is one where we can build an engine from component parts that suit the game in developement, and it’s how these components are glued together that will be the primary work of the studio. It’s my thought that moving away from ‘one-big-engine-fits-all’ will benefit games too, as they wont be quite so homogenized as they are now just because of the engine they use. The guys with the Qube engine seem to have taken this approach, but they are still a single vendor. I feel that more diversity and availability of tech will drive more innovative games.

I would therefore be very much interested in seeing middleware expansion in the form of discreet components rather than the full engine solution trend, and there are many useful component parts that could be bought in. The trick would be to keep them tight and focused, they needs to have a specific set of functions that they do well, and be easily replaceable (since no solution lasts forever!). I firmly believe that most bits of an engine can be written in a modular way that require little or no interdependency, and not at the expense of performance or consistency (the skill is in how the bits are presented to the game code). A few obvious examples of the top of my head follow, but even this short list could spawn hundreds of viable tech solutions.

• Network drivers
• Audio/Music
• File systems/ memory /debug systems
• Animation, rendering libraries, effect systems
• Export pipelines, texture compilers, offline lighting tools, etc.
• AI, scripting, maths & physics solutions
• Scenegraph libraries
• Tools – asset management, frontend construction
• Streaming/asset packaging
• Build systems

Note that I’m not suggesting an entire game can be constructed from separate middleware entities; certainly there always needs to be a framework in place, but I’m convinced there’s more profit and diversity in the assembly of an engine rather than manufacture of the component parts.

Unfortunatley there’s some major barriers to this happy world. Unlike the open source community, Platform NDA/confidentiality is a significant administrative hurdle before code can be shared, however it’s definately not insurmountable as vendors such as FMOD have proved. Another real problem is the acquisition of middleware vendors such as EA’s buyout of Renderware – if you were one of the developers using Renderware at the time you were faced with no other choice than to start writing a replacement render engine as it was removed from the marketplace.  I personally found EA’s purchase and subsequent abandonment of the Renderware product extremely distasteful – regardless of EA’s unstoppable businessplan – RW 3.7 was a perfectly good example of focused technology for general purpose use, yet it is now confined to a recycle bin somewhere on EA’s servers.

So now nothing is more likely to make a developer see internal development as a less risky option, when the acquisition vultures are circling any particular middleware product. Having said that, if the market for third party components flourished, developers would have more options to shop around if one product left the market. Clearly losing Renderware was a problem if you’d built your games on it, however with a finer granularity of tech buy-in this risk is a bit easier to mitigate.