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?
To illustrate:
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.