As you might know, we have been using DarkPlaces engine for Steel Storm. DarkPlaces began as Quake improvement project a while ago and within a course of years it grew into what it is now – an awesome advanced game engine.
While surfing the Net yesterday, I came upon a thread on the Indise3d forum, where DarkPlaces engine author, LordHavoc, explains why QuakeC is better than C++ for game logic support. I found it very informative and interesting. This is a full text from the thread:
“I recently received yet another email asking for C++ gamecode support, and decided to take the time to fully explain the biggest reasons that QuakeC is better than C++ for standalone Quake1-based game development, I hope this list is helpful.
(Note: I’ve had a lot of recent experience with a C-based gamecode system in my game DarkWar, and the experience has been less than pleasant)
So here’s my list of the biggest features of QuakeC over C++:
- binary portability (the same progs.dat file will run on any computer the engine runs on, no need to compile for multiple targets).
- graceful handling of crashes – the error message is printed to the console and the level can be restarted quickly for further testing (rather than having to restart the entire engine).
- all entity fields are exposed to map loading (this means that if you add a new field, you can immediately go in a map editor and set that field on an entity and it will work), so you don’t need a pile of glue code to expose the class fields like you would in C++.
- all entity fields and global variables are exposed to the savegame system (again this saves on a lot of gluecode).
- no dll API to maintain
- runtime inspection in the game console using prvm_* commands which can query or manipulate the running progs/menu/csprogs systems, for example inspecting the fields of entities, or setting the fields of entities, as well as profiling and automatic graceful cleanup after a crash. (Note: prvm_* commands are a DarkPlaces feature, Quake had other names for these commands and less advanced inspection/manipulation features) (Note2: a debugger can inspect variables in C++ gamecode but not without interrupting execution)
- easy to recompile the progs.dat at any time and simply restart the level or save the game and then load that savegame to see the changes take effect, this is also nice for development of code on active dedicated servers (for mini-MMORPG style games for instance, simply forcing the character files to save and then restarting the level to reload the gamecode). (Note: DarkPlaces supports FRIK_FILE for character saving and such things, Quake does not have file access builtins)
- native vector math (this can be done with operator overloading in C++ of course).
- animation state syntax allows you to easily declare a function for each animation frame of a model, which indicates the model frame to show and the next frame function to execute (and automatically prototypes that function), and sets self.nextthink to time + 0.1, and you can put in any extra behavior you want, such as self.nextthink = time + 0.05 if you want 20fps animation rather than 10, and ai calls are also very commonly used in frame functions. (Note: this can be done with the C preprocessor)
- easier to find and train additional programmers for a project, QuakeC is a very easy language to learn (unlike C++), even level designers can often help with the gamecode because it is so easy (and any project manager knows the value of extra coding help when trying to get a game finished).
- the single kind of struct (entity) enforces a design philosophy that keeps networking, savegames, and map loading simple. (Many of the proponents of C/C++ want complicated class inheritance hierarchies and nested structs, which can be difficult to serialize into savegames or load from maps, requiring more complex editing tools and more code to deal with the pointers and nesting features)
A few issues to keep in mind of course:
For existing C/C++ coders the language does require some different thinking to use effectively, for instance the use of structs and classes is generally discouraged (array, struct and class, are features of fteqcc and frikqcc compilers), instead the language mostly focuses on simple entity manipulation (where additional entities are spawned instead of using structs), so some different solutions to problems are sometimes necessary.
QuakeC is an interpreted language and as such it runs much slower (around 10-20 slower) than a native language, but a game often spends more time in collision functions, rendering, sound mixing, and other tasks than the actual game logic, so this is not a big issue (even most bots are not extraordinarily taxing).”
The original text and the discussion can be found at the forum on Inside3D website.
