# Design frameworks and bringing it all together.

This topic is 4945 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Personally, I believe the hardest bit of game design is the overall framework or the engine design if you will. We have buckets of code for physics, quake 3 level layout, lua scripting, OpenAL etc etc. Pretty much all the code is there to make whatever game you like but bringing it all together in one engine... now thats the tricky bit i think. I know there are a few books about designing your own 3D engine but i wondered if anyone here had any preference or can point me in the direction of some unifying frameworks or similiar? Any articles or personal experience on the overall design would be much appreciated. Now i usually use either c++ or java. Personally, i think java is quite good for bringing stuff together cross platform and the like. I already have a lot of experience in jogl and a few other such API's. I'd like to use C++ but i think the design process is a bit more complicated. Either is good though. I imagine good class design is the key with java, whereas getting various API's to work nicely together in seperate DLL's is more of a C++ issue. Cheers

##### Share on other sites
Actually this is more a question for the programming forums, as Game Design here is not really about programming issues. I'll move this thread.

I'll also add that personally, I don't think that the integration is that much of a problem. When it comes down to it, the hard work is in the details. At the top level it's just an input-process-output loop and everything else just either provides the inputs, the processing, or the output.

##### Share on other sites
Kylotan is right. I've seen many people lately with the idea that the "tricky" part of the engine is designing a framework or abstracting the engine design or make it with OO or I don't know what. No, the "tricky" part is the same as always: to make the damn thing run at acceptable FPS with as much graphic detail as possible.

The fact that we have code for model loading,levels,whatever doesn't mean a thing. The idea that you just gather that code, tie it together in a nice framework and boom! you have yourself an engine is just wrong. Try "putting it all together" not in the sense of a nice OO framework, but in the practical sense or resource management(GPU,CPU,RAM), that's the tricky part.

##### Share on other sites
Not as far as I'm concerned. Granted, performance is always a significant factor, but this isn't so much a design issue as a programming one. However, Oni_UK's post seems to address modularity as a programming issue. Kylotan's assessment is spot-on, and I agree with the IPO policy. My CIS instructor emphasized this precept in every single class he taught.

mikeman: My biggest problem is programmatic implementation, which is as much a design issue as it is a technical one. But then, I use Visual Basic 6. I've chosen to endure its limitations in exchange for its versatility.

##### Share on other sites
I see. Personally, what with all the Java-like patterns and "good ways" of coding, i feel that perhaps it is more of "good programming skill" rather than "game design". Modularity is a good thing and yes, i feel that you cant simply string everything together, BUT i feel there is perhaps a good way or method of designing a 3D engine since they all have a similiar theme as was mentioned; input / output, a bit of physics, object interaction and maybe some sort of scripting, texture loading, 2D Hud stuff and a 3D backend. Perhaps i should simplify a bit. I've seen books on designing 3D engines and the like. Would you guys recommend any or any online resources for laying out an engine? I've personally been down the road of hacking away at code and then messing it up. I've pledged to always write down on paper first! :) Guess you're right, its more of a programming thing. Cheers :)

##### Share on other sites
Really, I find that an almost identical structure works for almost any game I develop, from 3D stuff to multiplayer text games. It inevitably ends up like this:
Application initialisationGame initialisationGame loop    Collect input from non-players (AI)    Collect inputs from players (keyboard, mouse, network)    Move or modify players    Send output to players (video, audio, network()Game shutdownApplication shutdown

In essence, most of your low level stuff is gonna slot into one of the above categories. Your Quake 3 level loader and texture loading will run in the game initialisation, your Lua script might only execute in the AI, your OpenAL only operates during the audio bit of the output phase, and so on.

There are times when you might not stick to this rigid formula - for example, you might find it easy enough to play sounds as soon as the relevant input or processing is done, rather than store them away to be played in the output phase. Or you might move the AI characters as soon as the AI is processed, before the player input is collected. And at the other end of the scale, you may find that you're doing game initialisation and shutdown more often than once per game, for example to load new levels and so on. But the general structure is preserved throughout, from the program as a whole right down to each function (where presumably, you take some variables as input, process them, then return an output).

I think perhaps the most important thing is not to think that you can write it all down in advance for any non-trivial project. I always find it better to write down a brief specification and a list of things to achieve, but learn from the code itself. You won't truly know what problems you face until you try to implement them. You could browse GameDev.net for months, trying to learn of every possible problem that might come up, but then if you try and allow for them all then you'll have a horribly overengineered system. (See also: YouArentGonnaNeedIt.)

1. 1
Rutin
23
2. 2
3. 3
JoeJ
20
4. 4
5. 5

• 30
• 41
• 23
• 13
• 13
• ### Forum Statistics

• Total Topics
631741
• Total Posts
3001981
×