next up previous contents
Nächste Seite: Generieren eines Agenten Aufwärts: Verwendung des Prototypen Vorherige Seite: Verwendung des Prototypen   Inhalt


Deklarieren eines Agenten

Jeder Agent, Spieler oder Coach, ist eine Unterklasse von Prototype und sollte öffentlich abgeleitet werden:

#include ``prototype.h'' 

class MyAgent : public Prototype { 

};

Bei der Deklaration muß man auch einen Konstruktor angeben, der zumindest zwei Parameter enthält: Den Teamnamen und die Nummer des Agenten im Spiel. In diesem Konstruktor muß der Konstruktor des Prototype aufgerufen werden:

MyAgent (const char* team, int no) : 

  Prototype (team, no) {

    <yourStuff>

}

Der Destruktor des Prototypen muß nicht explizit deklariert oder aufgerufen werden.

Die Form des Prototype-Konstruktors entsprechend prototype.h:

Prototype (const char* team_name, 

  int number, 

  bool reconnect = false,

  bool isGoalie = false, 

  const char* host = DEFAULT_HOST, 

  int port = PORT,

  bool isCoach = false,

  double mapWindow = 0,

  bool logging = false,

  int numSnapshots = DEFAULT_SNAPSHOT_DEPTH,

  bool losingPackets = false );

team_name
muß für alle Spieler gleich sein, da der Server sonst von verschiedenen Teams ausgeht.
number
muß der Position in der Reihenfolge entsprechen, in der die Spieler sich beim Server anmelden. Die Nummer des Goalies ist dabei egal (s.u.). Wenn die Spieler über ein Skript gestartet werden, sollte man für entsprechende Pausen nach jedem Anmelden sorgen, damit die Reihenfolge nicht durcheinander geht. Wenn beim Anmelden für die erste Halbzeit die angegebene Nummer nicht stimmt, meldet sich der Agent sofort wieder ab, und isServerAlive() (siehe [*]) liefert dem Agenten false zurück.
reconnect
gibt an, ob der Spieler sich für die zweite Halbzeit anmeldet. Das erneute Anmelden ist nötig, da die Spieler beim Server abgemeldet werden sollten, wenn die erste Halbzeit vorbei ist. Jeder Spieler muß beim Wiederanmelden seine Nummer angeben, insbesondere der Goalie-Client muß die gleiche Nummer wie beim ersten Anmelden verwenden. Die Reihenfolge der Anmeldungen ist beim Wiederanmelden egal.
isGoalie
gibt an, ob der betreffende Spieler sich als Goalie beim Server anmeldet. Es darf sich nur ein Spieler beim Server in der ersten Halbzeit als Goalie anmelden, und der Spieler mit dieser Nummer (in der Anmeldereihenfolge) wird auch in der zweiten Halbzeit der Goalie sein. Nur für diesen einen Spieler wird amIGoalie() (siehe [*]) true liefern.
host und port
geben die Stringadresse oder auch IP des Soccerservers und den Anmeldeport für den Clienten an. Sie sind mit ``localhost'' und 6000 (dem Standardport für Spieleragenten) vorbesetzt. Wenn diese Angaben nicht stimmen, oder kein Soccerserver gestartet wurde, wird isServerAlive() false liefern.
isCoach
gibt an, ob der Client sich als Online-Coach anmelden soll. In diesem Fall muß der Anmeldeport explizit angegeben werden (der default-Wert wird aus der server.conf Datei ausgelesen und steht in COACH_PORT).
mapWindow
schaltet das Worldmap-Modul ein und skaliert die Darstellung. Wird an dieser Stelle ein Wert > 0 übergeben, so generiert der Prototype beim Start ein Worldmap-Fenster in der entsprechenden Vergrößerungsstufe und zeigt es an, und er schließt und löscht es beim Beenden auch wieder. Die Aktualisierung muß allerdings von Hand erfolgen (siehe [*]). Solange hier ein Wert <= 0 übergeben wird, verwendet der Agent keinen weiteren Speicher für das Anzeigefenster. Weitere Beschreibungen findet man in der Dokumentation zur Worldmap.
logging
schaltet das Loggen der UDP-Kommunikation in ein Logfile comm.log ein. Es werden sämtliche vom Server empfangene und zum Server gesendete Informationen aufgezeichnet, allerdings nur in ihrer Reihenfolge, und ohne weitere Informationen zum Agentenzustand. Die log-Datei eines Agenten einer Halbzeit umfaßt in der Regel mehrere Megabyte.
numSnapshots
gibt an, wieviel ``Platz'' den Worldmodel für Snapshots zur Verfügung gestellt wird. Der default-Wert sind 30 Snapshots. Dies bedeutet, daß die letzten 30 (oder 29?) Snapshots im Speicher bleiben und der Agent sie abfragen kann. Der Wert stellt also die Gedächtniskapazität des Weltmodells dar. Da jeder Snapshot recht viel Speicher benötigt (und der bei 22 Agenten auf einem Rechner garantiert knapp wird), sollte man nur bei vollem Bewußtsein über die DEFAULT_SNAPSHOT_DEPTH hinausgehen.
losingPackets
Dieses Flag greift in den Timing-Mechanismus des Comm-Moduls ein und sollte verwendet werden, wenn der Spieler nicht jede Runde eine Information vom Server bekommt. Dies ist zum Beispiel beim V4.x Protokoll des Soccerservers gegeben. Nach dem V5.x Protokoll werden regelmäßig (sense_body) Nachrichten versendet. Sollten diese Nachrichten aber gehäuft verlorengehen, muß man diese Option einschalten. Für Details bitte in die Dokumentation zum Comm-Modul sehen.


next up previous contents
Nächste Seite: Generieren eines Agenten Aufwärts: Verwendung des Prototypen Vorherige Seite: Verwendung des Prototypen   Inhalt
Debian User 2001-05-17