The cosmos common contains state that is not tied to any particular entity or component, but is still required by the solvers.
The solvers, however, cannot modify it. It can only ever be altered during the content creation stage, e.g. in editor.
There are certain examples of state that is better held common for all game objects.
For example: if there exist 200 entities named “Road”, it makes no sense to store 2 hundred
std::strings containing a value of “Road”.
It would be better if those 200 entities could share a single
std::string that they could refer to by a simple identifier.
So, for each such entity, we store a type identifier inside a type component, which is a simple integer.
Then we store a map from the type identifier into an entity flavour object (that is a part of the cosmos common significant) that contains the corresponding
This has several advantages:
- Less state to be synchronized through the network.
- Changing the name from “Road” to “EvenBetterRoad” for all road entities involves a single reassignment in the map, instead of iterating through all entities.
Similarly to cosmos solvable, the cosmos common consists of two parts:
Represents the part of the cosmos common that is significant. It holds:
- A map of names into corresponding type identificators.
Implementation note: always ensure that the cosmos solvable is reinferred after reinferring the cosmos common. That is because, if the order of operation was reversed…
…well, actually, nothing bad should happen. That is because physics world caches will have a flag of whether a particular
However: it might be the case that a
b2Shape belongs to an entity, and thus should be freed on destruction, or if it belongs to the common, and should not touch it at all.
b2PolygonShape or so might end up at a completely different address then from before reinference. Better safe then sorry.