C++/OOP game design

c++, sfml

Solution

I can suggest you some designs I used while developing games, while they are not anything good for sure but I never had many problems with them. I'll keep it short just to give you the idea.

First of all you need a view manager, this manager should manage the current view of your game, this can be implemented as a stack of views or whatever. So you will have a `ViewManager` class which knows all the views of your game and is able to dispatch things to the current one.

Then you need an abstract class `GameView` which should provide basic interface from the outside like:

- `drawMe()`, that draws the view

- `receivedMouseEvent(Event e)`, that will receive mouse events

- `activate()` and `deactivate()` to do actions that should be done when the view is pushed or popped in the view manager

Now with this abstract class you should implement any specific view or part of view of your game so that you can push and pop them in the view stack.

A good thing is to have subclasses to manage UI elements, eg class `ActiveArea` which responds to clicks, `Button` which inherits from `ActiveArea` and it is also able to provide a two state graphics. These elements should be contained inside a list of clickable elements which is stored in the abstract view so that every concrete view can add its buttons to a common implementation with no worries. In this way you can have something like (metacode)

void AbstractView::receiveEvent(Event e) {
  for (ActiveArea *area in areas)
    if (area.isInside(e)) {
      area->action();
      return;
    }

  innerReceiveEvent(e); //which should be a pure virtual function that will call a method specified in concrete views
}

In this way you will have each view managing their own state, and the view manager that will take care of drawing and managing events, eg

void ViewManager::draw() {
  for (AbstractView *view in views) // from top to bottom of the stack
    view.draw();
}

Problem

I'm practicing my newbie c++ skills by making a small game using SFML and OpenGL. The programming part has been going fine for the most part, but I've questions regarding actual code/class design. I've one class, MainLoop, which contains the game loop and owns one instance of each of the following classes: Events, Graphics, Commands, Game and UI. I initially wanted all of those to be a single class( with functions separated in different .cpp files), but was told that was the wrong approach for OOP/C++. However, while I can see the good side with separating them( encapsulation, modularity, debugging), I seem to be encountering a lot of bad stuff too. Let me take an example with the user pressing a UI button. First, the MainLoop gets the event from SFML's window class. MainLoop sends it over to my own Event class, which interprets the event and sends it over to the UI class to check if it 'hit' any of the buttons. If true, the UI class then sends it over to the Command class which interprets the button command. Then, finally, the command class sends it over to the Game class or wherever else it needs to go. It all seems very heavy-handed to me, and has also, at least the way I've been doing it at the moment, required a lot of forward declarations( and before I learned about those I ended up with tons of circular dependencies). I doubt it does much good for performance either. Anyway, is there some trick here that I'm missing? How should these classes be connected, how should they communicate? How should I be forwarding commands from, say, the Event class to the UI class? Should I really have forward declarations, includes and stuff everywhere, and doesn't that ruin modularity? Should I have it all run through the MainLoop class and forward the returns using the integers/floats/chars which don't require declarations instead? I'm kinda at a loss here.

Original source