The way I figured it, since the specific data each marine would need would depend on its state, rather than have a bunch of data swapping back and forth between the game engine, this interface object, and the marine itself to determine what state it was in and what data it need, I thought that it would be less cpu intensive to just pass the entity list to each entity and let the entity do what it needed to do since obviously the entity already knows what state it is in.
You do have a point, though, about entities spawning other entities.
The way my design is laid out now, you have the GameEngine which stores the data structure holding all entities in the game. Currently I have it stored as a Vector (i'm programming in Java) but in the future I could implement it as a quadtree.
Each entity itself has only an act() method, and all other attributes, such as mobility, position, etc are added in as extra objects.
So a Marine object woudl implement Entity, but would also have a Movement object that would be passed the marine's Position object to move it around the map by calling the Movement's move() method.
I implement Marine this way so that I don't get unneeded functionality if I later want to implement a missile or a rock or something. Each game object is assigned the attributes it needs and nothing more.
The downfall is that only a marine knows all the attributes of a marine, so the Entity list has no way to globally interact with all the entities except act() and type casting.
So since each entity will need very different data, I thought it best to let each entity control how they parse the data.
It isn't too bloated because each state in the FSM would implements its own resolveGameState() so when the Entity's resolveGameState() is called, it would in turn call the current state's resolveGameState() method.
This puts the code relevant to moving, such as collision detection, in the MoveState, nearby object scanning would be in ScanState, and so on. Obviously if there are no collisions when the game begins, the only collisions that will be caused are those that occur with moving objects and those objects will be in MoveState. That reduces collision detection somewhat.
When I implement a quadtree, each quadrant in the quadtree will hold a list of all entities inside that quadrant and so each entity would only be passed a list of entities in the same quadrant.
If I were to implement this interface object, it would have to do the extra work of type casting to the appropriate class, then determining which state the object was in and thus which data it would need. That sounds bloated and unnecessary.
This is just how things are implemented in my program at the moment, feel free to comment on how ridiculous it may be. I am always looking for ways to improve it.
Now that you have a general idea of how my program works, do you still think that putting all the code for determining which entities need what data is more efficient that letting the entities determine for themselves?
How did you guys do it in your own work?