Consider serializing terrain data for random maps and serialization test mode

[historic_bruno]

Currently we don't serialize any terrain data. But this makes the following cases much slower than they need to be:

• Loading saved games of random maps
• Rejoining multiplayer games with random maps
• Serialization test mode (doesn't even support random maps yet, it would be infeasible to generate them every turn)

So for only those cases, but not e.g. OOS checking or saving/rejoining scenarios, we could serialize the terrain data and avoid needing to reload the map. We can also look at compressing the state if the terrain data is too large.

[FeXoR]

If there's anything to be done on the RMS export part I'm glad if I can help.

[elexis]

This might be a won't fix:

• wraitii has a patch for supporting random maps on serializationtestmode at #3615
• saving a copy of the map terrain to every savegame sounds like a waste of disk space
• It's not clear whether serializing the terrain on the hosting computer, then transfering it across the network is faster than computing it from the matchsettings. Bandwidth and the performance load on the host should be minimized, so that observer-join-lag is minimized.

[elexis]

As of alpha 23, Terrain data is held by graphics/Terrain.cpp despite simulation components using that.

There is the desire to have the terrain modifiable by the simulation as well (trigger scripts) and also attach new information to the terrain tiles, such as a walkspeed modifier. So chances are that we have to serialize it whether we want it or not.

[elexis]

data

Specifically:

CCmpPathfinder.cpp
331: CTerrain& terrain = GetSimContext().GetTerrain(); 
540: CTerrain& terrain = GetSimContext().GetTerrain(); 

CCmpTerrain.cpp
50: m_Terrain = &GetSimContext().GetTerrain(); 

[elexis]

Since entities are replaced for rejoiners anyway, we don't need to construct them in ParseEntities with the current code already: #5202.

If the idea is to skip mapfile loading or mapgeneration entirely, then we need to serialize more than the terrain data, but also the starting camera position and environment settings.

This means we could also modify the environment from the simulation :-)

(But the rejoin/savegame filesizes will grow really significantly.)

[Stan]

Doesn't that depend on how it's serialized ? If it's like commands.txt, only the modifications to the map/environnement should be sent :)

[elexis]

The speculative performance benefit of serializing the terrain originally mentioned is that loading the files or calling the mapgen script can be avoided.

The speculative performance benefit of not serializing states that didn't change since the start of the game requires keeping the state of the start a game around. (It would also still require the maploading stage of the client, but as mentioned it's not clear which way the tradeoff goes.) I suppose only gaia resources didn't change since the gamestart, which may be half the entities on the map. So now we got us three-way tradeoff choice.