Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm looking for a book, website, or other resource that gives modern 3D game engines the same treatment as Operating Systems: Design and Implementation gave operating systems.

I have read Jason Gregory's Game Engine Architecture, which I enjoyed. However, by intent the author treated components of the architecture as atomic units, whereas what I'm interested in is the plumbing between those units that makes a coherent whole out of ideally loosely coupled parts. In books such as these, one usually reads that "that's academic," but that's the point!

I have also read Julian Gold's Object-oriented Game Development, which likewise was good, but I feel is beginning to show its age. Since even mobile platforms these days are multicore and have fast video memory, those kinds of things (concurrency, display item buffering) would ideally be covered.

There are other resources, such as the Doom 3 source code, which is highly instructive for its being a shipped product. The problem with those is as follows:

float Q_rsqrt( float number )
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;                       // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );               // what the f***?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );   // 1st iteration
    //      y  = y * ( threehalfs - ( x2 * y * y ) );   // 2nd iteration, this can be removed

    return y;

To wit, while brilliant, this kind of source requires more enlightenment than I can usually muster upon first read.

In summary, here's my white whale:

  • For an adult reader with experience in programming. I wish I could save all the trees killed by every. Single. Game Programming book ever devoting the first two chapters to "Now just what is a variable anyway?"
  • In C or C++, very preferably C++. Languages that are more concise are fantastic for teaching, except for when what you want to learn is how to cope with a verbose language. There is also the benefit of the guardrails that C++ doesn't provide, such as garbage collection.
  • Platform agnostic. I'm sincerely afraid that this book is out there and it's Visual C++/DirectX oriented. I'm a Linux guy, and I'd do what it takes, but I would very much like to be able to use OpenGL.

Thanks for everything!

Before anyone gets on my case about it, Fast inverse square root was from Quake III Arena, not Doom 3!


migration rejected from Mar 13 '14 at 22:25

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by zehelvion, Byte56 Mar 13 '14 at 22:25

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions about "how to get started," "what to learn next," or "which technology to use" are discussion-oriented questions which involve answers that are either based on opinion, or which are all equally valid. Those kinds of questions are outside the scope of this site. Visit our help center for more information." – zehelvion, Byte56
If this question can be reworded to fit the rules in the help center, please edit the question.

I wish I could help you here, but I'm looking for something like this myself :D – jli Mar 20 '12 at 0:26
You can't even get programmers to agree on where to put their curly braces and you expect a canonical volume describing The One True Game Engine Architecture TOTGEA =) There are a dozens of fully realized engines out there to study from, their combined documentation would make up your library and I'd suggest studying released projects instead of a book at this point. – Patrick Hughes Mar 20 '12 at 2:26
@PatrickHughes On the contrary, I don't think anyone who could actually write such a book could delude themselves into thinking that they'd convert anyone who'd worked on their own engine. Sometimes, though, that too can be probative. From just such a disagreement over MINIX, we get Linux, which is pretty great. This is just one of those big things that everyone seems to pick up on in bits and pieces here and there, and it'd be nice to see a well-manicured point of entry from which specific tangents could be explored. – user14497 Mar 20 '12 at 2:30
The "What the F***" constant is described in… - more precisely how it is used, rather then how it was derived. I don't understand it - but you might. – lochok Mar 20 '12 at 7:09
What would be really needed is a book that doesn't give specific solutions, but an overview over them. The problem with most books (and tutorials) out there is that they're basically the author going "This is how I did it" instead of "Now that we've refreshed our knowledge of the basic principles of software engineering, let us take a look at how to manage entities. Theres method A, with advantages and disadvantages, theres method B, with advantages and disadvantages, but also method C...". Also, abstraction: the better you can apply abstraction, the less language specifics matter. – sarahm Mar 20 '12 at 21:19

Even though they don't come with "educational engines", you might want to have a look at these two excellent blogs. They are written by industry professionals who more or less build engines for a living and they tend to focus on the plumbing in between systems a lot.

I hope you can make something of it - Some of it is not just about writing lean and mean engines but about programming philosophy which you might like or not. It's clear though that the philosophical advice they give doesn't come from nowhere - these people know what they are talking about.

I somehow missed this answer, but I'm glad I found it! This is a wealth of great info, thanks for sharing it! – user14497 Mar 27 '12 at 0:21
You're welcome! Help spread the word! ;) – Koarl Mar 27 '12 at 9:12

First that if you want to read engine code, usually engines fall in one of the two categories: fast and unreadable or well structured and slow. I'll suggest you start from the readable and slow :D

If you want to dig a bit in code... - Open Source 3D Graphics Engine. While it's just part of the puzzle I think it is very well structured and easy to read. - 2D Physics Engine. Yes it's 2D but the that is what makes it simpler to read. Adding the third dimension is not trivial starting with 2D is the way to go. I'll suggest checking from the Downloads page. It's few years old but that's the first release of box2D and is much simpler. - Although I haven't messed with the code of this engine enough and I haven't seen in what direction it went, at the time I played with it it was highly readable and well structure (you know what was sacrificed for that).

Thanks for the links! I spent some time a few years back working with Ogre, and you're right, it's a good exemplar of how a complex system fits together in practice. I haven't looked at Irrlicht beyond when I was asking the question that I think everyone asks about "Irrlicht vs. Ogre vs. CrystalSpace", but I might have to look again with fresh eyes. The wealth of open-source projects out there is really astounding, and the argument can be made that anything you don't like can be changed, but the cynic in me says that it's less work to start over from scractch! – user14497 Mar 20 '12 at 21:17
I agree with you. I've been working on engine for 3 years. Even have some products shipped with it. But recently I decided that a bigger change is necessary and 3 clicks later I had a blank Solution... Having worked with a lot of the industry flagships, I think they should more often click new Solution! – Aleks Mar 20 '12 at 22:29

I realise I'm a bit late with my answer, but it might prove usefull for future stumblers... For the "gluing it all together" part of game engine programming is indeed a topic I've failed to master a couple of times myself, and it is indeed hard to find a book that helps.

I found the blog Game Programming Patterns by Robert Nystrom (a true industry veteran) to be helpfull!


Chess engines solve a well-defined problem, and have been completely abstracted from the interface, and communicate their decision logic through the highly defined UCI (or older XBoard) protocol.

The three basic parts of a chess engine are as follows:

  1. Move generation (create a list of all possible alternatives from a given state)
  2. Position evaluation (a static estimate of desirability of any given state)
  3. Recursive search using negamax() – the magic that finds the best score.

Any decision logic can be broken down to variations of these three steps.

Once you have mastered this simple idea, you can start applying computer science to many fuzzy-logic picking situations: from chess, to checkers, to picking best-match bitmaps for optical character recognition (OCR), or for picking best-linked-to website for a google web-crawling robot.

Start by limiting you inputs/outputs to absolutely the essential decision making logic, and leave everything else out. Then, when you've clearly and narrowly defined your problem, pick between the alternatives using the threefold method described above, and write your engine - abstract it from boiler-plate code that interfaces and drives your UI. You can make it into chess, or connect4, or into stock-market analysis, or into the AI for a character in a game...

The simple recursive method method works to crack many tough problems.

Although dedicated to chess, the principles are the same - check out the chess wiki - it details many common methods used in chess engines in its Open Source Engines article.

Hi John. Please don't sign your posts - they're unnecessary. Also please read our FAQ on self-promotion. Whilst it's fine to do it, only do it if it's actually relevant. A link to your chess engine doesn't add anything to this answer, so I removed it. Feel free to link to it in your profile though. – doppelgreener Sep 28 '12 at 15:53

Have you read the Game Coding Complete series? The 4th edition came out a few months back, and their focus is to cover the very issues you seem to be questioning. I've been working on it for months, and it's still a wealth of information that I feel I've hardly tapped.

They publish the source code for their sample game, Teapot Wars, at if you want to look there - it's a basic but complete game that uses Actor classes for all its entities, an Event Manager to run everything, Lua for scripting, and breaks the source code into a .lib file for the basic engine that is then inherited by the TeapotWars class to make the game. Everything is pretty simple, or at least as simple as a modern game engine can be, and it's designed to be easily readable, with the book giving ideas on how to improve every aspect of the engine.

Here's the book link at Amazon:

And here's the forum that the authors maintain:

I gush over this because I find this to be my 'mentor' code that I'm continually looking over for ideas on how to design my own programs - it's really great!