So, I already sort of expected this problem when I asked another question (how can I link to other threads?), now it has actually come up. It seems my implementation of squads doesn't allow for good coordination of orders (actions). Right now my implementation of squads is that all units are automatically created with their own squad. So Initially each unit has its own one-unit-squad which can then be merged with other squads. Single units can also be removed from squads which puts them in a new squad of their own again. Units/Objects are held in lists that the "game loop acts on", but there is no list of all squads, those are only accessible through units. The behavior of the units is given by action objects that are passed to the action_manager of the class.

entity->getActionManager()->addAction(new move_action(coordinates(x,y)));

The actions step functions are then called by the units step function... At the moment im working on a "flock" of small spacecraft. They have a "idle_move" action that makes them just move around slowly at their momentary position. Now I wanted to implement a flock_move action but am unable to simultaneously "terminate" the orders of the whole squad when the action is completed. The problem is, I am not issuing one movement command to the whole squad, I just give the identical order to every member of the squad. But those actions are basically independent of each other, which makes them hard to coordinate. Now im not sure how to solve that problem? I could just stick with my version and try to find a condition that can be evaluated by every squad member and gives the same result. Or I could add some sort of communication system between the actions. Another possibility would be to move the action management up to the squad object and have a step function of the squad iterate through it's members. The problem there is, that there is no obvious way to iterate through the squads. So maybe the actions should exist only on the level of the squad object, but be called from the individual unit? like in:

void Entity::step()
{
   squad->execute_actions(this);
}

Did I miss some clever way to do this or is my squad/action system just a bad idea in general? should I implement squads different?

Quote:Original post by ddn3

So something like this Squad->(owns N agents)->emitCommand(moveTo)

Squad internally has a moveTo point which it checks periodically when all agents are within bounds, then it considers the squad moved to that spot.

Well, that is sort of the problem. At the moment there is no list<Squad> that allows me to somehow regularily update data of the squad or have it check the status of its members. The squads can only be accessed via the entities.
By using a loop that iterates through the entities and calls a function for each squad it finds, i am going to call that function multiple times... once for each of its members.

So i guess i should have that list<Squad>, but i am sort of allergic to having multiple independet datastructures contain pointers to the same elements.

So how would you implement squads in the first place?

Quote:Original post by japro
So i guess i should have that list<Squad>, but i am sort of allergic to having multiple independet datastructures contain pointers to the same elements.

But in this case, multiple pointers are the elegant solution. If both of those independent data structures need to know about the same elements, then letting them both have pointers to them is the most natural thing in the world.

Quote:Original post by theOcelot
But in this case, multiple pointers are the elegant solution. If both of those independent data structures need to know about the same elements, then letting them both have pointers to them is the most natural thing in the world.

Hmm, ok. But that means i have to actually store "observers" and not pointers, right? Otherwise I run into all sorts of problems when an object gets deleted... Or should I make the second structure sort of "self organizing", so that squads add and delete themselves from the "squadlist"?

You could do that, or just make sure that everything that contains pointers to entities are deleted before the entities themselves, or use smart pointers, which take care of only deleting things when nothing else points to them.

Or, you could do some system where objects remain for a while in a dead-but-not-deleted state, so stuff can check their entities' status and get rid of dead references. It would probably only have to be one cycle, just long enough for all interested parties to get the message.

There are lots of ways to do this. Which one you pick is probably dependent on what your architecture already looks like.