Class Design

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.

What kind of design patterns work well in games?

Same ones that work well in non-games. That's why they're design patterns. Games aren't special.

Should I be separating animation and graphics from game logic, or should I keep putting them together in a single "GameEntity" class?
[/quote]

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 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.