Recently, I’ve started work on our new game engine. And allow me to introduce tonight’s topic right away, thats a game engine and not a graphics engine. In fact, our new graphics engine is near-complete, and we’re only missing the game engine to go with it. Anyway, when undertaking the major task that is software design, I tend to read up on the subject at hand and empirically find a good solution (at least when the code is going to production, and needs to have a certain level of quality). In this case, that phase is a real bitch. Separating the game engine from the graphics engine isn’t a particularly well-documented phenomena. Most people seems to think that the two should go hand in hand while feeling each other up in all sorts of perversive ways.

Well, I beg to differ. In fact, I’ll go as far as saying that not separating the two is a very bad idea. What happens when (because it will happen!) the graphics engine gets outdated? You’ll end up having to either re-write both engines, or do some pretty damn heavy revision work! So in essence, you have to either change or re-write a system that works, because of poor design! Don’t bloody fix it, if it ain’t bloody broken!

While a graphics engine tends to go through a lot of changes as the capabilities of GPU’s progresses, a game engine stays mostly the same. A game engine has a much longer life span than a graphics engine. So the two should not be dependent on each other.
One of the biggest requirements from a technical aspect in the engine I’m working on, is that it needs to operate completely independent from the graphics engine. It also needs to be very lightweight. Creating some sort of bloated monster with no clear boundaries between the visual part and the mechanics part is in other words completely and utterly out of the question.

Ok, let’s go back on the real issue here; the lack of empirical literature dealing with game engines. Why is it, that it’s damn near impossible to find good up-to-date information about writing a stand-alone game engine? Every single article and book I’ve come across intermingles the visuals with the game mechanics. They have nothing to do with each other! Ever heard that old expression, “it walks like a duck, it talks like a duck, it must be a duck”? It’s the behavior of an object that defines what it is, not the graphical representation. Entities in the game world shouldn’t need to worry about how they bloody look, they should only worry about how they act. Mmm, getting side-tracked again.. I guess I should stop before my keyboard brakes.

To sum it up, as games become more and more complex, and more and more expensive to develop, re-usable code is a very very good way of keeping both down to a minimum. So, it’s absolutely crucial that all the systems are designed in a way that makes them re-usable later. It should also be re-usable in way that wasn’t intended in the orginal implementation. This is kinda hard to do if there’s no clear distinction between the game engine which defines how objects behave and interact, and the graphics engine which defines how objects look.

- cmv