putting everything together (graphics, physics, game logic)

[Shtuka]

Is there literature out there on putting everything together (graphics, physics, game logic, sound, ...), on class hierarchies etc.?

[Mind Calamity]

Hmm, try Game Engine Architecture/Design by David H Eberly, also Game Engine Programming by Stefan Zerbst and Oliver Duvel.

I'm trying to get this my own way, as reading a ~1000 page book on any subject is not really a hobby of mine, but if you're a book person, try those. Or ask on www.gamedev.net too.

[jacmoe]

http://www.ogre3d.org/documentation/books
I recommend Jason Gregory's book.
It actually features Ogre.

However, if you - like me - prefers a more practical approach, there's a lot of open source projects using Ogre.
http://www.ogre3d.org/tikiwiki/tiki-ind ... ing%20OGRE

[nikki]

It worked pretty well for me to just 'use them together' in a game - call directly the graphics functions, sound functions etc. with minimal binding between the two. You have what you need, just make the game.

[Mind Calamity]

It worked pretty well for me to just 'use them together' in a game - call directly the graphics functions, sound functions etc. with minimal binding between the two. You have what you need, just make the game.

This may be true, but most game/software developers tend to focus more on code re-usability, rather than making the game/program they should, which could pay-off later when you're developing more games. Also, that binding thing you're talking about - that's what's tricky for most people, for example - I was stuck at figuring out which classes my engine/framework should consist of, and how they would be related for months.

[nikki]

True - what I meant by minimal binding was have it so that each component "doesn't really care about the other." I made a little object framework for my game which had the usual GameObject base class that gave it frame update events, etc., some level/state management and loading, Blender export and allowed Python scripting and did save/load. It depended only on the Ogre Vector3 and Quaternion and in hindsight I could've used generic vector classes so that this code can now be 'reused' without Ogre or the other libraries - even for games I make that use pure OpenGL or whatever.

Making a framework that is a layer above your graphics, sound, logic engines is what I thought wasn't really necessary unless you're a big team with a plan for many projects (companies like ID games) - you'd have to update it along with underlying engine updates, and you're bound to the engines you decided to use (switching OpenAL with FMOD for exampe). Also as a single developer, you'd have to make the framework first and then the game, this takes time, versus a larger team, and you can't 'predict' what you're going to need in your game and decide the level of abstraction you want on certain things - "Should I have an animation class just for the cutscenes, or a generic 'timeline' class?" etc. May be it makes sense to just make the game, in a neat way. Not sure if 'YAGNI' is the right acronym here, but after some little graphics projects (recently was into trying to write demoscene demos, heh) it seemed to make sense.

Thinking about this - how about starting work on a game, and when you need something and begin coding it, try to predict if it makes sense in a more abstract way and put it in 'engine' code category. Later, call this bunch of 'engine' code your engine.

[jacmoe]

I am with Nikki on this one.
Programmers tend to over-engineer everything..

Read this:
Write Games Not Engines - Scientific Ninja

[Mind Calamity]

I have read that, and I agree that you shouldn't over-engineer, but having a nice reusable framework that wraps everything together and can help you kickstart a new game in a matter of minutes is a good thing to have no ? Even considering you are going to lose some time designing it, I think the pros beat the cons on this one. And if nothing else - the feeling of accomplishment that you get knowing that you have your own engine is itself extremely satisfying. (Although in my case this goes for pretty much anything I get working)

[cybereality]

Game Engine Architecture by Jason Gregory is a really good read. It's not a code cook-book, but it does give you a good bird's eye view of what goes into a game engine. There are, however, code snippets based on actual production code, and a lot of it is more straight-forward than you think. Worth checking out.