KaBotte

ist ein, seit Ende Oktober 2016 in Entwicklung befindlicher, Bot von maks.

Probleme gibt es noch beim taktischen Crashs (Optimierungen für "normale" Rennen funktionieren hier nicht bzw. sind kontraproduktiv).

Wenn KaBotte läuft (hat erstaunlicher Weise den gleichen Tag-Nacht-Rhythmus wie ihr Schöpfer) zeichnet sie sich durch sehr niedrige Reaktionszeiten aus.

Bei Problemen, bitte ein Telegramm am maks.

Hintergrundgeschichte

KaBotte (Dank an den Künstler CaptainLoken)

Im Jahr 2029 (kurz nach Abschluss von Didis Arbeiten an Karopapier [ca. 2028]) ist die Karowelt infolge einer Terminator-WM verwüstet und der Großteil der Karobevölkerung aus dem Karo-IQ verdrängt. Von menschlichen Karo-Spielern entwickelte, intelligente Maschinenwesen begannen als Karopiloten auf der Rennstrecke gegen ihre Schöpfer anzutreten, als sie in diesen eine Bedrohung für ihre eigene Existenz vermuteten. Den Überlebenden des Wettkampfes bleibt die Wahl, den Maschinen als Arbeitssklaven zu dienen oder sich dem Widerstand der Menschen, der Resistance, anzuschließen. Als der menschliche Widerstand unter Führung von John Karo im Jahr 2029 kurz vor einem entscheidenden Sieg über die zentrale Maschineninstanz Karonet steht, schicken die Maschinen eine KaBotte in das Jahr 2016. Dieser Androide – eine Maschine umhüllt von lebendem, gemüsigem Gewebe, um Karospieler unauffällig zu infiltrieren – wird auf die besten Karospieler angesetzt, um sie zu Blocken und gegen Wände fahren zu lassen, bevor Didi Karopapier gegen die Bots verteidigen kann und die Entstehung von Karonet verhindern. (* frei nach Wikipedia)

Fun facts

• KaBotte hat am 28.02.2016 am 91. Tag nach der Karopapier-Anmeldung bzw. 50. Tag nach der Eintragung zu KaroIQ maks in der KaroIQ-Tabelle überholt.
• Die Führung hielt nur einen Tag an, ABER am 24.03.2016 (KaBottes 116. Tag) ist KaBotte wieder in Führung (auch Botrix wurde überholt) und vermutlich bleibt das ab jetzt so :D
• Codezeilen (exklusive Leerzeilen und verwendeter Bibliotheken): Pfadsuche 800, Physik & Sonderregeln 650, Bot-Steuerung 150, Kanalysator 300, Api (Kommunikation und Abbildung als Klassen) 2000
• Erstes Spiel [1] am 29.11.2016 noch mit Anfangsschwierigkeiten wegen eines Bugs
• Erster aktiver Block im Spiel [2] gegen DeepPink. Zuerst einen Zug abgenommen und kurz darauf zum Crash gezwungen.

Features

• Berechnung der Ideallinie vom aktuellen Vektor aus
• aktives Blocken von Gegnern; bei der TWM wird das Blocken von Teammitgliedern (Bots) vermieden
• beherrscht Checkpoints
• Richtungsmodus bei Rundkursen (Zieleinfahrt wird auf einen Winkelbereich eingeschränkt)
• selbständiges Erkennen von Rundkursen
• Taktische Crashs (TC, inkl. Mehrfachcrashs)
• Nachtrennen (unbekannte Maps werden gefahren, aber KaBotte lernt mit jedem gefahrenen Rennen die Map kennen)
• Selbständiges Aussteigen bei nicht unterstützten Strecken
• Websocket-Unterstützung (Empfang des Dranbin-BART (Bindran-Alarm in Real-Time), daher Reaktionszeiten von < 1 Sekunde)
• Analyse von Spielen zum Festellen von Assits und Vergabe von Abzeichen bei der von Karaser durchgeführten Terminator-WM ("Kanalysator"); dazu auch absolut lesenswert sind die TWM-Randnotizen von nobody
• Sonderregeln aus Einladeraum: (KaBotte reagiert, wenn die in Klammern angegebene Zeichenfolge im Titel eines Rennens enthalten ist. Für weitere Einschränkungen der Sonderregeln sind die Spieleersteller zuständig (z.B. TC, ZZZ, Richtung, etc.)
  • REmulAde ("§ REmulAde § " bzw. "§ Rundenerster wiederholt letzten Zug §") (bei <= 3 aktiven Spielern muss nur einmal in Folge wiederholt werden; ab 7 Spielern müssen die beiden Ersten wiederholen; wenn die Wiederholung auf einem Gegner landet, darf frei gefahren werden) KaBotte vermeidet Züge die im Falle einer erzwungenen Wiederholung zu einem Crash führen. Eine aktive Zugauswahl um im Falle von RE Wiederholungszüge zu vermeiden findet noch nicht statt.
  • Ziffernblock ("$ Ziffernblock $")
  • Randrennen ("$ Randrennen $")
  • Richtungswechsel nur am Rand ("$ Richtungswechsel nur am Rand $")
  • Doppelzug ("$ Doppelzug $")
  • Bremspedal klemmt ("$ Bremspedal klemmt $")
  • Prim-Beschleunigen ("$ Primzahl Beschleunigen $")
  • Nur x=0 oder y=0 ("$ Nur x=0 oder y=0 $")
  • Geschwindigkeitsbegrenzung ("$ Geschwindigkeitsbegrenzung $") (die Maximalgeschwindigkeit in euklidischer Norm muss im Titel nach dem schließenden "$" mit angegeben werden)

Technische Details

• Programmiersprache
  • Java

• Architektur
  • Multi-Threaded (GUI, Server-Kommunikation, Pfadberechnung)

• Serverkommunikation
  • API(v2/v1) für Spieldaten
  • GET/POST für Interaktion mit Karopapier.de
  • Websockets für Dran-Benachrichtigung

• Speicherverbrauch
  • KaBotte benötigt für die "schwierigen" Maps (z.B. 125, 167, 207) trotz paralleler Berechnung durch mehrere Threads maximal 550 MB. Die Laufzeit gewinnt aber deutlich, wenn viel Speicher (~3GB) zur Verfügung stehen, da zur Pfadberechnung sehr schnell, sehr viele Objekte erzeugt werden und meistens vom Algorithmus schon nach kurzer Zeit verworfen werden, so dass bei zu wenig Speicher der Garbage Collector sehr häufig laufen muss und dann mehr Zeit damit verbraucht wird, als für die eigentliche Pfadberechnung.

• Laufzeit
  • Die Laufzeit hängt stark von der zu berechnenden Map ab, aber bis auf die schon beim Speicherverbrauch genannt Maps liegen die Antwortzeiten von KaBotte meist bei wenigen Millisekunden, so dass die Antworten zum Server künstlich begrenzt werden, um diesen nicht zu überlasten, was besonders bei einem frischen Start von KaBotte passieren kann, wenn sie viele Spiele blockt.
  • Wenn KaBottes mögliche Züge die von Gegenspielern kreuzen, wird für jede dabei mögliche Zugsituation eine eigene Pfadsuche ausgeführt, was z.B. bei Massenstarts die Laufzeit bis zur endgültigen Zugauswahl vervielfacht.
  • Viele der Optimierungen sind Folgen der Arbeiten am Kanalysator, da dafür pro zu analysierendem Spiel bis zu 1000 einzelne Spielsituationen berechnet werden müssen und sich Verbesserungen dabei deutlich auszahlen.
  • Eine Pfadberechnung für Rostock ab dem Start benötigt mittlerweile ca. 50 Sekunden. Vor den neusten Optimierungen stellte die Karte den Worst-Case dar und die gleiche Berechnung dauerte ca. 30 Minuten.

Algorithmen

• Pfadsuche (Breitensuche, dies werden vermutlich die meisten Bots machen)
  • von jedem möglichen Zug werden alle neun Nachfolgezüge betrachtet und überprüft, ob sie den Karo-Regeln entsprechen. Gültige Züge werden in einer Queue zur Bearbeitung gespeichert
  • bereits verarbeite Züge werden nur einmal betrachtet (insbesondere Züge mit größerer Pfadlänge werden ignoriert), allerdings wird die Information gespeichert, ob man auf verschieden (gleich langen) Wegen zu diesem Zug gelangt und diese dann als äquivalent angesehen
  • der Algorithmus wird solange durchlaufen, bis ein Zug einen Checkpoint (im einfachsten Fall das Ziel) erreicht
• Checkpoints
  • für Checkpoints wird der obige Algorithmus für die Pfadsuche für jeweils eine Tour (alle offene CPs und zuletzt für das Ziel nacheinander) ausgeführt
  • um den Suchraum zu verkleinern, werden nur die besten Kandidaten für die kürzeste Tour betrachtet, dazu wird die Karo-Distanz (die Zuganzahl) der CPs untereinander betrachtet und das TSP gelöst
• Richtungsmodus
  • KaBotte beachtet den Richtungsmodus ausschließlich auf Rundkursen; ob eine Strecke ein Rundkurs ist kann KaBotte selbstständig feststellen
  • notwendige Kriterien für einen Rundkurs sind dabei, dass alle Zielkacheln zusammenhängend sind, das Ziel maximal drei Züge vom Start entfernt ist und das eine Zieleinfahrt nur in einem Winkelbereich von maximal 180° möglich ist
  • zur Bestimmung des Winkelbereichs wird eine Pfadsuche zwischen Start und Ziel durchgeführt und alle Winkel der gültigen Zieldurchfahrten betrachtet; bei Formel 1 ist dann nur dieser Bereich erlaubt, bei Normal ist genau dieser Bereich verboten und Züge werden während der Pfadsuche verworfen
  • Problemfälle sind u.a. Maps mit Start oder Ziel in einer Sackgasse (hierfür mussten händisch Ausnahmen definiert werden): Map Nr. 116, 134, 184, 205, 229; 201
• Sonderregeln
  • hierfür werden bei der standardmäßigen Überprüfung auf Gültigkeit von Zügen ebenfalls auf die Sonderregeln hin überprüft; die eigentliche Pfadsuche funktioniert weiterhin ohne spezielle Anpassungen
  • für den RE-Modus ist grundsätzlich nicht genau bekannt weiche Züge möglich sind, bzw. ob wiederholt werden muss, deshalb wird ausgehen von der Wahrscheinlichkeit zu wiederholen (Anzahl der Spieler) für jeden Nachfolgezug die Wahrscheinlichkeit berechnet mit der KaBotte zu einem Crash gezwungen wird
  • Züge mit Crash-Wahrscheinlichkeiten über einem Grenzwert werden als ungültig verworfen

Datenstrukturen und Synchronisierung

• Pfadsuche
  • Zentrale Datenstruktur für die Pfadsuche ist eine Queue. Durch die Art, wie KaBotte die Pfadsuche mit Checkpoints behandelt ist eine PriorityQueue notwendig. Die dabei benötigten Sortieroperationen dominierten die Ausführungszeit, so dass die Standard PriorityQueue durch eine Eigenentwicklung ersetzt wurde. Für jede Zuglänge wird verwaltet eine eigene Queues die möglichen Züge. Zugriffe auf das erste Element der Gesamtqueue und auch das sortierte Einfügen finden in konstanter Zeit O(1) statt.
• Gültige Züge
  • Da die Überprüfung, ob ein Zug erlaubt ist, sehr häufig ausgeführt wird (Maps mit Checkpoints, Kanalysator, Blocker, TSP) lohnt es sich die Ergebnisse zu Cachen. Ein Move wird durch seinen Hashwert repräsentiert und in einer IntBooleanMap aus den Eclipse Collections verwendet, die diese Informationen sehr effizient verwalten kann. Der Speicherverbrauch dafür steigt selbst bei Map 167: Rostock nicht über 100 MB.
• Threads/Synchronisierung
  • Da auf die "Gültigkeits"-Map von vielen verschiedenen Threads zugegriffen wird, müssen Zugriffe darauf synchronisiert werden. Besonderheit dabei ist, dass nach der Anfangsphase der Pfadsuche fast ausschließlich Lesezugriffe stattfinden, so dass es lohnenswert ist den Overhead der Synchronisierung zu minimieren. Sowohl ein Locking via synchronized als auch ein ReentrantReadWriteLock bremsten KaBotte deutlich aus. Als optimal erwies sich ein SequenceLock das nach dem Lesen aus der Map überprüft, ob zwischenzeitlich darauf geschrieben wurde und notfalls erneut lesen muss, aber im Erfolgsfall ohne Nachteile ist.

Verwendete Bibliotheken

• [https://www.eclipse.org/collections/ Eclipse Collections}
• Java WebSockets
• JSON-java
• Jansi

ToDos

• Chatmodul ("sChaloTte") fertigstellen
• Selbstständig Spiele erstellen (bisher nur separate Komponente)
• Bugs bei TC beheben
• Bugs bei Kanalysator mit CPs beheben
• Blocker mit höherer Suchtiefe erweitern

Problematische Karten

KaBotte steigt bei diesen Karten automatisch aus.

• Nr. 49: Vermondy (Ziellinie ist löchrig)
• Nr. 56: Interlagos (Ziellinie ist löchrig)
• Nr. 117: Let's rock (CP nur mit Crash ererichbar)
• Nr. 201: Sandbowl (meiner Meinung nach ist die Map kein Rundkurs und nur dort würde der Richtungsmodus Sinn machen, deshalb lieber deaktiviert)