In our teamwork structure, players are organized into team formations with each player filling a unique role. However players can switch among roles and the entire team can change formations. Both formations and roles are defined as part of the locker-room agreement, and each player is given a unique ID number. It is a significant challenge for players to remain coordinated, both by all believing that they are using the same formation and by filling all the roles in the formation. Since agents are all completely autonomous, such coordination is not guaranteed.
In PTS domains with limited communication (as opposed to no communication) possible during the dynamic, real-time periods, inter-agent communication can help the team stay coordinated. Communication protocols defined in the locker-room agreement combine with heard messages to trigger internal behaviors that alter the agent's internal state.
This section describes the CMUnited-97 simulator team implementation of the communication paradigm presented in Section 5. All of the agent messages are of the format:
(CMUnited <Uniform-number> <Encoded-stamp> <Formation-number> <Formation-set-time> <Position-number> <target> <Message-type> [<Message-data>])For example, player 8 might want to pass to player 6 but not know precisely where player 6 is at the moment. In this case, it could send the message (CMUnited 8 312 1 0 7 --> 6 Where are you?). ``CMUnited 8'' is the sender's team and number; ``312'' is the <Encoded-stamp>, in this case an agreed-upon linear combination of the current time, the formation number, and the sender's position number; ``1 0'' is the team formation player 8 is using followed by the time at which it started using it; `` 7'' is player 8's current position; ``--> 6'' indicates that the message is for player 6; and ``Where are you?'' is a message type indicating that a particular response is requested: the recipient's coordinate location. In this case, there is no message data.
All teammates that hear such a message update their internal states to indicate that player 8 is playing position 7. However only player 6 sets its response and response-flag internal state variables. In this case, since the target is a single player, the communicate-delay flag remains at 0. Were the message targeted towards the whole team or to a subset of the team, then communicate-delay would equal:
Once player 6 is ready to respond, it might send back the message
(CMUnited 6 342 1 0 5 --> all I'm at 4.1 -24.5). Notice that
player 6 is using the same team formation but playing a different
position from player 8: position 5. Since this message doesn't
require a response (as indicated by the ``I'm at'' message
type), the message is accessible to the whole team (``-->
all''): all teammates who hear the message update their world states
to reflect the message data. In this case, player 6 is at coordinate
position 
.
Were player 8 not to receive a response from player 6 before passing, it could still pass to its best estimate of player 6's location: should the message fail to get through, no disaster would result. Such is the nature of most communication in this domain. Should there be a situation which absolutely requires that a message get through, the sending agent could repeat the message periodically until hearing confirmation from the recipient that the message has arrived. However, such a technique consumes the single communication channel and should be used sparingly.
Notice that in the two example messages above, both players are using the same team-formation. However, such is not always the case. Even if they use common environmental cues to trigger formation changes, one player might miss the cue. In order to combat such a case, players update the team formation if a teammate is using a different formation that was set a later time as detailed in Section 5. For example, if player 6's message had begun ``(CMUnited 6 342 3 50 ...'' indicating that it had been using team formation 3 since time 50, an internal behavior in player 8 would have changed its internal state to indicate the new team strategy.
Other examples of message types used in our implementation of simulated robotic soccer players include: