Question

I try to realize a little game project to dive deeper into OO programming (winforms c++/cli).
I already started coding but now I´d like to make a re-design.
For the beginning the game should consist of four parts like game-engine, user interface, highscore and playground. Heres a little (non-UML-conform) class diagramm to visualize my purposes

Would this be the right way?
In my eyes the game engine is responsible to control the game sequences (state machine?) and exchanges information betweens all other classes.

I appreciate any help!

EDIT:

so it´s a really simple game, no big deal! here´s a link of what I made by now:
http://www.file-upload.net/download-2595287/conways_project.exe.html
(no virus 🙂 but I guess you need .NET framwork to get it work)

Answer 1

Unfortunately, your current design sucks 🙂

I won’t say what I will suggest is actually the best solution available, because in game design there is generally “no best” solution, but still I think it would make you think appropriately.

Larger UML here.

alt text http://yuml.me/1924128b

Let’s say you have your basic class Game. It’s something abstract class, that wraps all your game logics and works as a sort of Swiss knife.

You should create two another classes – UI and State (which, obviously, encapsulate game UI operations and store current game state). Let your Game class hold UI and State instances.

Now, your Game class should have basic methods to control your game. They could be plain render(...) and update(...) methods and this part is actually a bit tricky. If your game is real-time, you would have to update your state every Y milliseconds, so your update(...) should be called in a loop.

If your game isn’t actually real-time, your updates should happen only when user does something or you actually know that you need to change something. You could implement a message queue here and update(...) call would simply flush all those messages.

Now, the render(...) method. Create some class and call it Backend – let this class encapsulate all your drawing possibilities. There is one really cool thing here – you could let your Backend be an abstract superclass and create some concrete backends, which derive from Backend. And that would actually give you an opportunity to switch your Backends with simple code manipulations.

After that, you should pass your Backend instance to your render(...) method, which would do appropriate drawing and it’s logic could be written the following way:

foreach (const Object& object, game_state) {
   object->render(backend); // Or something like that
}

The last thing to mention, your game state. You could have a plain structure to hold all your current objects, score, etc, etc. Let every object access that GameState structure and everything will be fine.

Actually, there are many things to think about, if you wish to, I could write more about this game design approach and share some tricks 🙂