I''m amazed this thread has gone this long without people mentioning two books(at least I think they haven''t been mentioned). They are:

Real-Time Rendering 2nd Edition
by Akenine-Moller & Haines

3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics
by Dave Eberly

Now, one thing to mention is that neither of these books are in written in a tutorial style. That is, they do not actually walk you through creating a game engine. What they cover is basically everything you need to know to create a decent game engine, and are API agnostic in doing so. Between the two, they cover things like:

Transforms: How Matrices, Quaternions, etc work, so you can create your own functions)
Graphics Pipeline: Cameras, Culling, Clipping, LOD, Shading, and Rasterizing.
Geometry Methods: Curves, primitives, triangle formats, sub-divs, patches, Terrain, etc
Scene Graphs: How to create and manage a tree of nodes
Intersection/Collision: Rays, Spheres, BBox''s, Ellipsoids, Capsules, etc
Animation: Keyframes, Inverse Kinematics, Skinning.
Rendering: Lighting, Texturing, BRDFs, Shadows, Global Illumination, DOF, etc

Now, what they don''t show you is how to set up your classes to hook up all those things up together and make them interact. Actually, I think Eberly''s book does come with an engine of some sort but I haven''t checked it out. That being said, I think how you go about hooking all that stuff up will differ depending on what type of game you''re doing. They also don''t show you anything regarding Input, Sound, AI, or Networking. So, you''ll have to glean that stuff from another source.

One thing you should be aware of is how these two books differ. Real-Time Rendering tells you how all these things work in theory, in a fairly easy to understand matter. All of the methods are explained with pictures and bits of pseudo-code, but no source code. Eberly''s book, OTOH, is VERY mathematical in it''s explanation of everything, but also provides nice source code showing how to do it. So, as I''ve been working through, I''ve found it works well to learn how it works with Real-Time rendering and then how to do it with 3D Game Engine Design. They seem to complement each other nicely.

At the end of the day, I think I''m in the same boat you''re in. I wish there was a good book that showed how to connect all the bits together. It seems like all of the books out there either represent very simple, heavily API reliant "engines", or they''re mostly reference books. But at least with these books you''ve got a fighting chance if you can think through how you want your engine to work.

Also, just as an aside, you might want to hold off on picking up "Physics for Game Developers" for the moment, and use your money instead on these two books. I have that book too, and while it''s OK for reference it didn''t blow me away. But more than that, with all of the other engine stuff to contend with, it might be a while until you get to implementing physics for whatever type of game you''re doing

Well, I hope that helped!

-John

Well, from the looks of everything most people seem to equate "game engine" with "graphics subsystem"! There''s a LOT more to a game engine than just shoving geometry around, if all you want to develop is a fancy renderer then you''re in good shape with all the recommendations so far!

The first thing to do is sit down and generate a list of desired features. Divide the features into logically grouped categories, something like "AI", "Networking", "Geometry Database", "Renderer", "Audio", "User Interface" and such. You''ll find a lot of dependencies between subsystems this way as well. After enough passes, you should have a decent idea of the number of subsystems you''ll be implementing and their interactions. Then you can pick a technology for implementation: Language (C/C++/Java/whatever) and component communication (COM, message-passing, etc).

The general concept is: decide WHAT you want to make. Then decide HOW you''re going to make it. And there''s nothing wrong with reverse-engineering someone elses code, learn from others mistakes - it''s more fun to make your own (lol do I know that one)! Strangely enough, I don''t think there''s actually a good book on "game engine design" that covers ALL the bases (graphics/AI/database/audio/physics/networking), everyone tends to focus on the "hot topic" which is mostly visuals - the most obvious part of the engine - and leaves out the "dirty little details" that make up the other 90% of the code.. ugh.

As to the clueless llama saying don''t do it: I''m sure this is from someone that''s still coming to terms with QuickBASIC. The only real way to learn something is to try and do it yourself, and that''s what I think the idea is here - learning how. Ignore this person, obviously Mom forgot to give them their Prozac before they went online.

Have a look at the Ogre engine. Its free and available at sourceforge. You can use it as a reference when you need help.

Another resource you might want to take a look at is my open source game engine hosted at http://neoengine.sourceforge.net

not much to add. I started coding my own engine about a year ago, with almost no C++/DX/GL knowledfe in my bag. Now, after rewriting the engine about 7 times, it got interfaces for Dx and Gl, and more...

All I can recommend is writing an engine you think roxx, then scrap the project and start over. You can check out my first version of the engine, using Dx and VB over at Syron Engine Site. No downloads, just a couple of pix.

It''s nothing impressive, but you need the training you get from redoing the code a couple of times, making it better as you go. (atleast it worked for me, may or may not for you...)

anywayz...

"What is darkness? It doesn''t exist where there''s light, and without light, it''s nothing..."