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.