Hey guys! I've been working with games development (on a *very* small scale) for a couple of years now through college, using Java and the SLICK API at first, followed by C++ and OpenGL. However, so far all my games have been quite poorly designed - each object has contained it's own "render" function that it overrides, and the code for drawing the entity to the screen is hard-coded.

What kind of design patterns work well in games? Should I be separating animation and graphics from game logic, or should I keep putting them together in a single "GameEntity" class?

(As a side note, is there an easy way to export models made in Blender and import them into my game? Would I be able to set openGL properties like material properties from within Blender? This would mean I could maintain a reference to a model file in my Entity class and just pass that to a singleton Renderer object when i needed to render the entity.)

I'd like to step up from making one-shot games without much re-usable code to making a platform that I can keep using and improving as I go - at the moment, each game is created from the ground up.

I'm using C++, with OpenGL and SDL.

I have a question: how much have you tried to reuse your code in later projects? I have found that noting the problems that arise due to attempting to reuse my code has helped me to better design my future code for reuse.

[quote name='alaroldai' timestamp='1322900414' post='4890076']
What kind of design patterns work well in games?
Should I be separating animation and graphics from game logic, or should I keep putting them together in a single "GameEntity" class?

Separation is better, since it allows you to run your game without rendering if you're doing testing, hooking an AI up to it, or making a standalone server.
That said, getting the game done is more important than making the game well, and you might not need any of those things for say... Tetris.
[/quote]

When it comes to structuring code, you always want to remember two concepts - Separation of Concerns and Single Responsibility. In general, a class should have a single purpose and the methods that class has should conform to supporting that purpose. If you go beyond this and start combining code into a single object, you've just created the famous "God" object which is generally very bad design and while it may not show any harm at the current point in development, you will typically suffer from this design approach later on.

But when it comes to patterns, you'll likely find a multitude of patterns being used. I do agree however with Telastyn that making the game is far more rewarding in most cases. I've tried to write engines before without considering the end-game and it became far more hassle and less rewarding personally, so I tend to design a game and extract an engine from it. After several games and engine refactors, you start to see the the common patterns in what you factor out as the engine and then can really dive deep into making a solid engine imo, but naturally yours and others opinions may vary.

If you plan to create a multiplayer game, you will need to separate logic from resources, since resources are too large to send through a network connection in an efficient enough manner to keep the game running in real-time. For example, in a MMORPG you might have an Actor class. Actor objects would most likely be saved on the server side and would contain the necessary data to concatenate a Sprite object on the client's side, and to also know where that sprite should be drawn to the screen when rendering everything.

Basically what Telastyn said. It really comes down to what your goals are for each specific game or engine you develop, and you will most likely find yourself re-factoring and re-writing an engine fairly often, or at least parts of it, to gather your best solutions.