Kos · May 14, 2014 12:29
diff --git a/How do I represent a world and dynamic objects in a C++ console game? b/How do I represent a world and dynamic objects in a C++ console game?
 1) First thing I'd do would be to disconnect all the graphics rendering code from your World and Entity; it's going to be complicated enough without them :-)

 2) I don't like that an Entity remember its index into the world. Let's revisit a typical roguelike data model:

 > a World or a Level has a tilemap (floor, walls, or generally - a tight "grid" of walkable and non walkable scenery) and in addition - a number of entities, where every entity stays on one place in the grid.

 You can have zero or more entities in the same slot - a goblin can stand over a pile of items, for instance.

 3) Now let's think about the processes that happen. There are processes like movement, attack or picking things up.  Let's take movement.

 Movement is tricky, because it touches both world data (is that place free to move into? are there no obstacles?) and entity data (can it move? can it move over this terrain?). Also movement can take an amount of time, which basically means that the entity won't do a thing before.

 Anyway: if you keep the movement logic away from both world and entity's member functions, you don't need to have this circular reference problem. Also while I can understand why you'd make "Entity::move" in the first place ("it lives, so it moves"), I don't think that such complex multiple-object processes are deemed to be tied together to an arbitrary one of them. Note how many steps can be here:

 - update the World with the Entity's new position in it
 - update the Entity's energy, trigger random events that happen once in X steps (shoe wear?)
 - check for any things that should happen when a map spot is occupied (traps?)

 Does all this logic belong into an Entity more than to a World? I don't think so.

 By keeping stuff separate, you keep the Entity lightweight (= about the Entity itself, not Entity-and-everything-entity-related), thus avoiding the [God object](http://en.wikipedia.org/wiki/God_object) problem.
	1) First thing I'd do would be to disconnect all the graphics rendering code from your World and Entity; it's going to be complicated enough without them :-)

	2) I don't like that an Entity remember its index into the world. Let's revisit a typical roguelike data model:

	> a World or a Level has a tilemap (floor, walls, or generally - a tight "grid" of walkable and non walkable scenery) and in addition - a number of entities, where every entity stays on one place in the grid.

	You can have zero or more entities in the same slot - a goblin can stand over a pile of items, for instance.

	3) Now let's think about the processes that happen. There are processes like movement, attack or picking things up. Let's take movement.

	Movement is tricky, because it touches both world data (is that place free to move into? are there no obstacles?) and entity data (can it move? can it move over this terrain?). Also movement can take an amount of time, which basically means that the entity won't do a thing before.

	Anyway: if you keep the movement logic away from both world and entity's member functions, you don't need to have this circular reference problem. Also while I can understand why you'd make "Entity::move" in the first place ("it lives, so it moves"), I don't think that such complex multiple-object processes are deemed to be tied together to an arbitrary one of them. Note how many steps can be here:

	- update the World with the Entity's new position in it
	- update the Entity's energy, trigger random events that happen once in X steps (shoe wear?)
	- check for any things that should happen when a map spot is occupied (traps?)

	Does all this logic belong into an Entity more than to a World? I don't think so.

	By keeping stuff separate, you keep the Entity lightweight (= about the Entity itself, not Entity-and-everything-entity-related), thus avoiding the [God object](http://en.wikipedia.org/wiki/God_object) problem.