Refactoring of MapObjects, MapObjectsManager and MapObjectDrawer and their interaction

[andreas-eberle]

Reason

The integration of decoration objects developed in #237 brought to attention that the current MapObject system, including the drawing and management of them, needs to be refactored and unified. At the moment a lot of special case handling is used for their management and rendering.

Background - Ideas of the Current System

The current system was build to achieve decouple the MapObjects from both, game logic and graphics. Reasons for that are:

• Storing only game relevant information is important to keep memory consumption lower and the savegame clean of non-deterministic stuff. E.g. it would be a bad idea to store the current image index of an adult tree that is used for animating it. This is only a UI thing and does not have any effect on the game logic. However, as we cannot store information in the graphics system but only calculate it on demand (like for the tree animation), we have to store some information in the MapObject. For example the type of the tree needs to be stored, although the game logic only cares about "is there an obstacle on the map" and "can this tree be cut".
• Some map objects need to progress over time (like growing trees). Furthermore, some objects also need to interact with the rest of the game (e.g. a fallen tree or a resource sign dissappear after a while). Giving all these objects a reference to the MainGrid (or an interface for there interaction with the MainGrid) would really increase memory usage (to amount killing the game on Android). I know, optimization should be the last part of development, but it also needs to be kept in mind when choosing solutions. That's why the MapObjectsManager was introduced. It manages the objects by executing their logic, especially the logic interacting with the rest of the game.

  Things to be Considered for the Refactoring

• Refactorings like this should not change the behavior. Therefore I would like to have this done in a separate branch without the combined integration of decoration objects. Mixing a major refactoring with a big new feature only makes it more complicated. Of course, the needs of the decoration objects must be kept in mind.
• The graphics and game logic should be as separated as possible.
• Memory consumption and garbage creating is always an issue on the Android platform and must be kept in mind.

After taking a look at you code in the "add_decoration_objects"-branch, I think your DrawableObjectFrame is a way to start. We really should try to find a unified way to render map objects.

Modus Operandi

The work will be coordinated in the branch https://github.com/jsettlers/settlers-remake/tree/refactoring_map_objects.

[tomsoftware]

Just one brainstorming idea: would it be possible to use something like a Union to store all Data for all kinds of objects. So we could separate date and logic:

• Data is stored in a Array of this union-Data-Object
• all kind of map-objects only exists in one instance (or have only static functions)

//- create e.g. 1000 data container (may this have to be a list of arrays of union-Data-Object to increase the size)
AllObjectData[] = new union-Data-Object[1000];

//- call the static functions with the data for this object as argument (of cause as reference but this is just a example)
FarmBuilding.DoWorkTick(AllObjectData[ 5 ] );
FarmBuilding.getDrawStyleState(AllObjectData[ 5 ] );

Farmer.DoSomething(AllObjectData[ 6 ])
Farmer.getDrawStyleState(AllObjectData[ 6 ] );

benefit:

• it would be very simple to save and load the game (just save/load AllObjectData )
• it is very memory efficient (no object overhead is in Memory) => 1000 Objects = 1000 * sizeof(union-Data-Object)

disadvantage:

• only make sense if all objects have more or less the same amount/size of data to store.
• this is not a good-opp-style

[andreas-eberle]

I see exactly the disadvantage that you pointed out. The objects have very varying size and it is total C programming. Moreover, the code would get badly readable, as there is nothing like the union for structs in Java. Furthermore, all objects stored in an array are actually not stored in the array. In Java, every object type is always passed by reference and arrays only contain references to the objects on the heap. Therefore creating a "uninon datastructure" would only increase the memory usage and still require us to have various types of objects which we then would need to cast to be able to work with them.