Are there good resources ( manuals, tutorials, etc ) to start studying the code of the Quake 3 engine beyond the code itself?

I'm very interested in know how it's structured for educational purposes and maybe to do some modifications.


3 Answers 3


So, you should start by looking at Wikipedia's article on id Tech 3. That can be augmented by Brian Hook's GDC talk summary and some old stuff on the Element 61 blog. In addition to that, you'll have to trawl through a bunch of whatever old mod tutorials you can find to try and reconstruct what's going on.

I'd suggest starting from the original source release from id, instead of ioquake3 or what-have-you, in order to really see the context of what's going on (how input is handled and directed inside the engine, what sort of underlying event structure is used, etc.).

Some key points that helped me when I was working with it:

  • There is always a server; there may also be client logic sitting on top of handling a frame.
  • Input is directed first to a console, if interested, then to the GUI, then to the game proper.
  • The engine itself is separated (hard!) from the game logic, using trap functions. Look in (if memory serves) the cgame and render projects to find the actual engine code.
  • Game logic can be entirely written to run in the Quake 3 virtual machine. When modding and using native dlls, you will have to run the game as quake3.exe +set sv_pure 0 +set vm_game 0 +set vm_cgame 0 +set vm_ui 0 in order to allow the engine to run native code instead of VM code.
  • The UI for the menu system is a strange, evil, twisted stack of structures and callbacks. It is usable once you puzzle it out, but that can take some trial and error. Remember, it's a stack.
  • If you are writing code in native .dlls, feel free to allocate memory, write in C++, or whatever else floats your boat. You can use the STL too--there is no reason to rigidly follow the C idioms except where you directly interface with the engine.

Some neat things I've made for it with a coworker:

  • Simple command-line interface to call shell commands from the console and dump the stdout/stderr streams back to the console (the Quake console).
  • Interface with an SQL database to pull and display records.
  • Flexible windowing and widget toolkit for making flexible displays on the client hud (using bar charts, text boxes, picture boxes, context menus, resizeable windows, etc.).
  • Slow rockets. :)

Personally, I found that the engine was a great combination of really smart things done in really dumb ways, really dumb things done in really smart ways, and really smart things done in really smart ways. It's a great example of how to have modularity and good structured design in a medium-scale C project.

Lastly, don't feel bad if it takes a while to grok. It took me maybe a month to really be able to know where to find what I was looking for in the engine; if all else fails, start at the application init and just tunnel down into the functions, leaving comments for yourself as signposts. My monitor ended up covered in pink post-it notes with function names, line numbers, and short descriptions of what they did.


The book Focus On Mod Programming in Quake III Arena will help you understand the way the client and server logic are decoupled, client prediction, client side graphics effects etc.



http://en.wikipedia.org/wiki/Quake_engine is a good overview of what is out there, but you can get into the details of its architecture quite quickly through its citations.

May i also suggest a couple books on game engine architecture which may be more in line with what you are looking for. While not Quake specific, they go into the details of engine design and run parallel to many aspects of of the Quake engines:

  • 3D Game Engine Architecture - 978-0122290640
  • 3D Game Engine Programming - 978-1592003518

Not the answer you're looking for? Browse other questions tagged .