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.

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.

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) : http://www.gameenginebook.com/ . It will give you some ideas.