First off, let me preface this with the following announcement: we have two middleware solutions targeting independent game developers coming down the pipeline. One of them is a user interface toolkit, similar to wxWidgets or Qt, but fully hardware accelerated and oriented towards video game UI and level editors. The other piece of middleware is a complete “game engine” on the level of, say, Unity or C4. It features all the stuff that you would want, including interactive level editing, terrain creation, and a full dynamic lighting and shadowing solution using deferred rendering. It also includes some stuff that you didn’t know you wanted, such as an easy-to-use level sketching tool, an asset store built into the level editor, and our new and improved version of so-called “Megatexturing” which lets you paint on every surface on the world, dynamically, and without compilation times or messy texture packing.

Neither one of these two pieces of technology is used by Dungeons of Dredmor; when Gaslamp Games was founded, we originally started working on a 3D isometric strategy game, but we soon decided that it was unrealistic to try to ship a fully 3D title for our first effort – especially without a dedicated 3D content creator on staff! – and so we decided to finish Dredmor instead as a way of bootstrapping the company. That said, we have been working on our next game’s technology base in parallel with Dredmor’s development, it is *very* indie-friendly, and it will be available to interested parties at a very reasonable rate in the near future. If you want to be notified about when we get set to release, send an e-mail to technology-announcements-subscribe@list.gaslampgames.com and we will shower you with love.

That said:

I woke up this morning to see that GarageGames (renamed recently to “InstantAction” as part of a buyout) has gone under. InstantAction is dead, and the Torque Game Engine is looking for a buyer. Deep in the heart of the Gaslamp command center, we’re still trying to figure out exactly what triggered the collapse of the company. I’ve worked for companies that have collapsed before – Loki Software, anyone? – and the root causes of the company’s destruction are not always visible to outsiders. What caused the collapse, and what does this mean for independent developers?

As a company, GarageGames had two projects. InstantAction, a “free-to-play” web portal that never figured out how to monetize itself, and the Torque Game Engine. I’ve worked with TGE before – the core technology behind Torque 3D was originally developed by Dynamix for the video game Tribes 2, which passed through Loki’s porting grinder back in 2000. It had a very good landscape renderer for the time, which was miles ahead of what anyone else was doing. It had vehicle physics. It had a very good, scriptable UI system and a built in scripting language. It also had no interior renderer to speak of. Last but not least, the basic underlying code that made up the Torque codebase was written in 1999 and released in 2000, and GarageGames shipped that technology, with bits added onto it, for many years. Some of the things that they added were very good. GarageGames hired good people, and folks like Ben Garney, Pat Wilson and Melv May all made significant technical contributions. Torque was always hampered by the same fundamental failings of its basic engine: poor support for interior rendering and lighting, a reliance on an increasingly creaky BSP renderer, and an inability to perform the massive, massive refactoring that was needed to run with the times. Folks like Unity, C4, and Epic’s free release of the Unreal Development Kit were just too much for them.

In the future, though, who else will die?

This is an interesting question, and it depends on what you want in a game engine. If what you want is the world’s best eye candy, then most of the current crop of 3D engines out there aren’t going to be able to achieve that over the next five years. Performance on modern hardware is dependent upon three things: efficient use of the GPU, efficient use of multiple CPUs, and writing cache-friendly code. Using the GPU efficiently is surprisingly easy; efficiently using multiple CPUs is harder, and writing really, REALLY cache-friendly code means that you have to throw out your entire engine and start again. Any engine that was built around a very object-oriented model will be so plagued by cache misses as to be unable to compete. Efficient multi-threaded programming is also tricky; I wrote an article on it for Game Developer Magazine, but I’m now convinced that a message passing architecture isn’t the right idea either. Why? Again, cache misses.

Of the big three – Unreal, ID Tech 5, and Crytek – the only people who seem to have seriously started worrying about truly taking advantage of next-generation hardware seem to be ID. (This should surprise nobody.) If you search around, you can find some interesting talks by Jon Olick on the subject. (He doesn’t mention cache coherency, but he is at least talking about methods used for parallel programming.) With their purchase by Zenimax, ID has stated that they no longer plan to license their current engine work outside of their parent company. I don’t know what Unity’s plans are in this space either. Anybody with a code base that hasn’t been thinking about this needs to start refactoring now or risk running into a massive, company-killing load of technical debt.

If, on the other hand, you want the ability to ship a game… then you have a different set of problems. Indie developers, in particular, need tools that let them build games rapidly and get them out the door as fast as possible with a minimum of manpower. That’s a different problem, and requires different solutions. Suffice it to say, those solutions probably *aren’t* compatible with multi-threading and cache coherency.

You could, of course, roll your own technology, but the skills required to write a 3D engine are very, very hard to acquire. (I hung upside down on a tree for seven days and seven nights, let a raven peck out my eyeball, and then, when all else failed, I apprenticed myself to Derek Smart.) This is what is holding up any number of indie titles like Fez and Overgrowth: in order to make a 3D title, you must first write a 3D engine and THEN you have to write a game using it! You need to understand OpenGL or Direct3D, you need at least two years of university-level math, and you need to be a C++ wizard. Not everybody who wants to make a game has these qualifications, nor should they have to.

Technology only gets more challenging for independent game developers as the industry progresses. We hope to be able to help you with your problems very, very soon.

In the mean time: back to Dredmor! I’ve got old-skool 2D pixel hacking to finish.