Object-oriented Programming - need your help

Question

hey folks,

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

Your 'Game Engine' would probably be considered more of a 'Math Library.' You might want to insert another object in between 'Game' and the other Server Classes that 'Delegates' the requirements of 'Game' to the Server Classes and call that 'Game Engine'.

Also maybe 'High Score' and 'Playground' could be combined into a Class which represents 'Game State' and port that directly to 'Game.' 'Playground' could be a Server Class which encapsulates any code to do the actual presenting of said background where this would usually represent a 'Rendering Class.'

IMHO

Answer 2

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.

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 :)