New class Director/Scenario concept

[paul424]

What I wanted , was to have qualificators over event types : like "creatures " , "hurt " "damaged" "dissapeard " "entered" etc.
That is each event should have multiply types. This can be done statically : c++ class inheritance and base class for each qunatifier, or dynamicaly where each base type would have to be somehow either deduced from the context, or explicitly set by the programmer at the creation type.

[oln]

It's important to not just think about how the structure should be, but also the process of changing the structure. I think we should do things in small steps. (Trying to change something to radically right away can easily lead to problems, as with the tile map stuff.) We need to start splitting up the large classes, and reduce, or ideally get rid of, the use of singletons.

Try to think about the concept of dividing up problems into smaller problems, until reaching a level where they can be solved.

Since you wanted me to comment on the director/scenario thing. I think the idea can be used in a way, though I think we should structure this using the application modes. For a campaign, there could simply be a "campaignMode", which sits above the load mode, and chains the different scenarios together (which could function a bit like your "director" idea.). Though, again, we should implement this in steps. The first major goal I think should be to get a basic map editor mode, with GUI controls, working. (Most of the functionality is already there really.) I suggest this general outline:


First we should start moving the game-specific parts (gameMap, renderManager, sceneManager etc. ) out of the ODFrameListener class, so that only the stuff that is used in the menu is in there. By doing that we separate the level loading from the game startup, and can control level loading independently.

Then, we split out the menu parts of odFrameListener into a new class. Depending on the size/complexity the mode ends up with, it can later be split up more.

Once that is done we can start making the class that will contain the modes. Optionally the mode stuff could be tested with mock objects first.

Then the game and menu mode could be implemented, and tested.

Then the game mode could be split up into editor and game, with the common parts as a superclass.

etc..

[paul424]

In case someone would document here's another class scheme ( quasi-UML )