How about the Enginuity series, here on GameDev.Net?

It doesn''t differ much from how you build other large scale software projects. A lot of research has be done here to identify reoccuring successfull object interaction models, so called design patterns.

Look for "architectural patterns", "design patterns" and "idioms" - since they''re totally independent of the type of software project one is developing with them, you won''t likely find game engine related examples, though.

-Markus-

quote:Original post by Wavewash
3d Game Engine Design by David H. Eberly I thought was a fantastic book. If you get the chance stop by a book store and see if they have it. Page through it and see if it has the information you want. It seems to touch on just about everything.
~Wave

Really? Because I thought it was terrible. The guy's obsessed with lozenges, cylinders and spheres. I looked for any information at all that would help me structure a 3D engine properly, and couldn't find anything other than vague references to scene graphs and the like. In fact, the front cover was more of a help (there's a treeview of a scene graph integrated on it). The Magic 3D Engine that he wrote (which comes on a CD with the book) is about the only reason to buy the book, and that's not brilliant. I suppose if I could be bothered to decipher the Bezier and NURBS sections, for which you'll need at least A Level Math (I did AS Level Math, and that's barely enough), this book might be of some use to me. In fact, the only reason I kept this book rather than sending it straight back to Amazon was that I thought I was missing something. I read the positive reviews on Amazon. "I'll read through it again," I told myself. I did, and it still wasn't an ounce of help. No doubt he knows what he's talking about, but he can't write for toffee.

I'd look at the way other 3D engines work. A 3D engine, however, can be an extremely complex thing, so if it's a C++ engine you want to study and eventually build, you need to know everything about C++. Try looking at the Neo engine, the OGRE engine, the Quake III engine (based in C, and very instructive, get it from ftp.idsoftware.com), the Unreal engine and the Half-Life engine. The modding communities which surround these games have documented the engines very well, and you can usually figure them out with some programming know-how. Don't expect it to be too easy, though . It's a good idea to sketch out how each engine works, how DLLs communicate with EXEs, how the user interface is drawn, how the engine manages it's resources, etc. Then you can draw it all together to create your own...

Insert [CENSORED] here.

[edited by - iNsAn1tY on November 17, 2003 5:12:58 PM]

I would NOT recommend using the Quake 1/2 source code to teach you how to design your engine.

quote:Original post by Salsa
I would NOT recommend using the Quake 1/2 source code to teach you how to design your engine.

I didn't say it would be easy to figure out how Quake II works. All I said was that it would give an idea of what is required in an engine. That's why I listed the Neo and OGRE engines first; they're probably the best place to start.

quote:Original post by Spudder
None of the Unreal/Q3/HL engines are available for "browsing" to learn how to design an engine, the source code for the Q3/HL games is publicly available which might give you some insight into how the respective engines work.

Yes, the actual engine part is not available. But the source code for the game shows how the engine communicates with the game, and how the game uses the engine to run itself.

The problem is, I don't know of a book which takes you through the steps of creating and properly structuring a 3D game engine from the ground up. One which did would probably be a couple of volumes. The best thing I can think of is this: don't design a game engine. Design a basic game. See what this game requires, in terms of input, rendering, game logic, etc. Then, when you have this, you'll know which parts to put in an engine (so they're reusable for another game) and which are truly part of the game. I mean, how can you create a game engine without first making a test game to "feel out" your engine's requirements?

Insert [CENSORED] here.

[edited by - iNsAn1tY on November 17, 2003 7:37:25 PM]