After finishing Doom3, I've begun looking a bit at the engine.
I was a bit surpised at how similar it was to the Quake Engine, and to be honest I had expected more development here. Of course changing the engine more radical would also mean that all previous licencees of the engine would have to re-learn things. Thus, by keeping the basics the same, the Quake to Doom3 transition will be much easier for licencees to accept. It does however mean that Doom3 becomes less attractive in the long run.
How was Doom3 done?
Basicly stuff is done by scripting, scripting and more scripting. While I can understand this for historic reasons it just doesn't seem like a very productive way of achieving things.
The very nice ingame GUI's are all described by scripts
. All items are described by tediously entering coordinates, RGB colors, calling other scripts on clicks and so on. Honestly I cannot see (even as a programmer) how the iD folks could stand having to script literally hundreds of screens this way.
In similar way most, if not all, interaction and events are scripted in a C++ like language. So for a rotating bridge you need several hundred lines of code just to make an interactive bridge with a GUI-screen to select where it goes.
This leads me to the main point of this rant. How do you create things for maximum productivity for your team. Doom 3 is IMO an example of "overprogramming" - creating more hurdles and long testcycles for your entire team. The testcycle seems far too huge for so simple operations. Having to load the level, open the GUI just to see how your RGB-values align up just seems very counterproductive to me.
Scripts are popular. They give a great amount of flexibility. Everything is visible in scripts, but sometimes tedious and hard to debug. My guess is that scripts are also popular because their initial development time are rather small. Creating new features, where GUIs are needed takes more time to update than adding another script function. So the basic tradeoff are in most cases:
- Time saved by getting new tools to the artist.
- Extra time spent by the artist by having longer feedback time on changes.
Having a drag&drop interface for creating GUIs will make feedback time zero, since it's WYSIWYG. So when you are selecting a new color you get instant feedback on how it looks with the rest you are doing. When John Carmack talked about "ingame editing" this was what I imagined. Not having a console command spawn up the editor outside the game, or haing to reload the level for every minor change you make.
I think iD can only thank themselves for the long development cycle they've had, by not doing the content creation tools they IMO should have done. There are plenty of inspiration out there, and iD beeing so programmer-focused is not really what I expected. It is possible to have scriptlike features without having to script
. And even though the Serious Engine is pretty dated, the instant-feedback editing and "visual scripting" does show that it is possible to do a lot more without having to go into script code.
There are a lot of other related stuff I won't get into. But D3 IS impressive overall - but productionwise it's the same as Quake 3, with an upgraded graphics and sound system.