In the light of DRY, it seems desirable to store a collection of related game objects in one container only. However, one might need sub-collections of these objects in various contexts. It might be sensible store these specific sub-sets in specific more suitable containers. This increases the effort to track objects across containers, for instance when objects are removed from the game world.
What are possibilities to simplify such a design and what are the typical trade-offs?
In a multiplayer role playing game, the server might hold a collection of game characters in a map suitable for lookup by id.
world map<id, Character> allCharacters
A character may also reside in a certain game level. In order to identify all characters being present in a level it may seem suitable to introduce a container for each level which holds the characters currently present on it. This way you can execute common logic for all characters in that level.
world map<id, Character> allCharacters [levels] level1 vector<Character> charactersOnPlayfield level2 vector<Character> charactersOnPlayfield ...
Going even further, when a character interacts with the world messages should only be routed to characters in range. This interest management could be achieved by dividing the each level into a grid of cells each of which in turn store the characters currently standing on it.
world map<id, Character> allCharacters [levels] level1 vector<Character> charactersOnPlayfield [cells] cell1 vector<Character> charactersOnCell cell2 vector<Character> charactersOnCell ... level2 vector<Character> charactersOnPlayfield [cells] cell1 vector<Character> charactersOnCell cell2 vector<Character> charactersOnCell ... ...
The Character objects at different levels of abstraction introduce the need to think carefully about object ownership and life-time.
Note that the Character objects stored in the containers would naturally be references, not copies. Also, I am assuming that no garbage collection is in place.