Advertisement Jump to content
Sign in to follow this  

Framework design question

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi Guys,


I am reasonably early on in writing a framework for my game. (I hesitate to use the word 'engine' as I am making a game, not an 'all purpose' engine).


As it gets bigger, the code is getting a bit messy and hard to maintain. So I am wondering if the idea of 'sub classing' would make sense in my case.


At the moment I have separate graphic, input, and audio classes. The input and audio classes are maintainable, but he graphics one is getting big (as I anticipated would happen).


I am thinking of breaking the Graphics class down to sub classes. Something like this;


Graphics - General device creation etc.

Graphics::Objects - Subclass the objects to have creation and destruction handled by the graphics class.

Graphics::RenderTargets - I'll have multiple render targets as I need them for what I am doing.

Graphics::Shaders - Haven't thought too deeply with this one as to whether I need to subclass this or not.


Would this sort of approach be feasible?


I look forward to any thoughts and suggestions. smile.png

Share this post

Link to post
Share on other sites
I wouldn't even call if framework, but just implementation of the game.

Gradually rewriting and expanding code in the area where it is needed is a good technique. You may paint yourself into a somewhat fixed structure though. Each time you expand just a tiny part to something else, which works locally, and bolt some more code onto it.

However if you would take a few steps back and design it at a bigger scale, you could end up with a different / better structure. Keep that in mind, and don't be afraid to refactor code. Better kill code that bothers you as fast as possible.

Share this post

Link to post
Share on other sites
Thanks Alberth. I guess it all comes down to individual preference and workflow in the end, doesn't it smile.png

I'll try the approach I have mentioned in my OP then. I'll soon know if it is going to suit my style.

Share this post

Link to post
Share on other sites
You mean atbthe moment you have just three classes - graphics, input and audio, which implement everything?

Yes, that's not a good idea. That's not an object oriented design. Read up on SOLID and practice OOD. Breaking them into many smaller classes sounds completely expected/normal -- and a lot more than three!

Share this post

Link to post
Share on other sites

Sounds as if you have your logic and game-objects in your Graphics class, and that sounds wrong.

No class for game-objects/entities themselves? More classes can so make your life easier. 

Easier debugging, easier refactor, easier compile, easier to not get a giant lump of spaghetti-code.

Share this post

Link to post
Share on other sites

games are made of components and systems and modules. many of them translate directly to class definitions. and many of those may be made up of instances of sub-classes (such as a list of objects).



basically these are the major "things" you'll need:


a renderer. it takes a list of renderables, determines visible surfaces, and sends them off to a render queue for optimal submission order to the GPU.


an input handler that processes user input.


an update_all routine which typically calls update_each for all objects in the active entities list.


implementation of the list of renderables can be anything from a simple static array to a dynamic oct-tree data structure. the correct choice depends on the scene type.


input handlers may use immediate or deferred processing (IE message systems)


there may be more than one list of renderables and / or more than one list of active game entities. its not uncommon to have a few lists - one for each basic type of thing.


various and sundry asset pools with textures, meshes, wavs, etc. these provide a place to store data used by other systems. asset loading is typically the asset pool's job, whether its all up front, per level, or demand paging.


a high rez timer system for FPS counters, and framerate limiters or fixed timestep systems, as well as timed events in the game which are driven by the game clock, which is driven by the update frequency, which is governed by the high rez timer system.


an audio system that can play or loop sound effects and music loops.


an animation playback system for animated models.


i'm sure there are more, that's all the really high level general ones that come to mind at the moment.


if i were to take every data type and its associated routines and turn into a class in Caveman 3.0,i'd probably have 30, 50 maybe 100 classes total.

Edited by Norman Barrows

Share this post

Link to post
Share on other sites

Here's my 5 cents. I've been working mostly on engines and frameworks, very rare on actual games but I noticed few rules if you build something more reusable and maintainable:


- Make sure you can use it. New framework brings new API. If you - the creator, cannot remember own API, then probably it's going to be hard to use.


- If you are not sure about the abstraction level, try to write pseudo code which uses your non-existing API. It works for me. When I worked in bigger teams on solution that were used by many developers, asking them for advice ("how would you like to use it?") was very helpful input. For example, if the question is "how do you instantiate a shader?" (just example), and somebody (even you) writes simple snippet of the code. It helps also to decide about structure of code (namespaces, classes etc.).


- If you are the only person using your framework/engine, sometimes it's worth to bring "new blood" who will tell you that your ideas make no sense (believe me, you want to hear it as often as possible, it may save lots of hours of coding moving in wrong direction). What I learnt over years, today you can't really make this kind of solution single handed. Well you can, but it's very easy to make design mistakes being just on your own.


- Don't design "final" structure. It will change. A lot. Really lot. Iterate over it. If you work on the actual game, that's great because this is your main use case and it provides you with the requirements. Frameworks, libraries, engines - whatever you call a middleware is like a clay, you keep reshaping it, modifying, it will always get closer to the perfection you want, but you're always see something missing ;)


- (as bonus) Read this book by Jason Gregory (I believe it's the most known book about today's engines, but still worth mentioning) : . It will give you some ideas.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!