Alas, after the change was complete and a considerable effort had been spent to make entities and entity hierarchies work as well as groups did, the first tests and feedback quickly showed that it didn't work out, and that my assessment of the situation (and my enthusiasm for entities, or in fact, the entity component system) did this time not lead to the desired solution. Practically speaking, we found that the "groups", as they were implemented before, were just too good and too convenient to be removed: my attempt to achieve the same with entities was just not on par (think e.g. of the "Hide Other" button). Considering this more closely, it turned out that this was not a problem of the implementation, but of a more principal nature:
Entities and their hierarchies are an excellent way to organize (group) map elements in terms of the game or the virtual world that is being developed: You use entities to model game objects like players, opponents, cars, lifts, or anything else that is relevant for the game.
Groups, however, serve a quite different organizational purpose that, in hindsight, is orthogonal to that of entities: With groups, you express features that are important to the map designer's workflow or are of technical relevance – but not to the logical modeling of a virtual game world.
- Entities group map elements by their logical meaning in the virtual game world, as observed by players, as needed by script authors, as seen by the core engine, etc.
- Layers group map elements to facilitate technical details for the map designer, e.g. to temporarily hide objects, to lock them from being accidentally modified, etc.
reintroduce-groupsbranch is completely implemented and committed.