KaBotte: Unterschied zwischen den Versionen

Aus KaroWiki
Zur Navigation springen Zur Suche springen
K
Zeile 1: Zeile 1:
KaBotte ist ein, seit Ende Oktober 2016 in Entwicklung befindlicher, Bot von maks. Erklärtes Ziel von KaBotte ist es, Re-Rennen fahren zu können (das kann noch ein wenig dauern) und performant genug zu sein, um auf meinem Synology-NAS (DS213j) zu laufen. Momentan (Stand: 8.12.2016) beherrscht er CPs, TCs, ist in der Lage den Richtungsmodus zu interpretieren und fährt nach Möglichkeit nur auf der Ideallinie.  
+
ist ein, seit Ende Oktober 2016 in Entwicklung befindlicher, Bot von maks. Erklärtes Ziel von KaBotte ist es, Re-Rennen fahren zu können (das kann noch ein wenig dauern) und performant genug zu sein, um auf einem Synology-NAS (DS213j) zu laufen.  
  
Zur Zeit ist KaBotte in einer intensiven Testphase (läuft nur tagsüber auf meinem Arbeitslaptop und abends zu Hause) mit meinem Arbeitskollegen, die vollkommen freiwillig als Gegner für KaBotte herhalten müssen.
+
== Problematische Karten ==
  
Karten die KaBotte noch Sorgen bereiten sind 117 (ohne TCs) und 167 (wegen der Größe des Suchbaums).
+
Nr. [http://www.karopapier.de/mappreview.php?MID=117 &pixel=4&karoborder=1 117 ]: ohne TCs
 +
 
 +
Nr. [http://www.karopapier.de/mappreview.php?MID=167 &pixel=4&karoborder=1 167 ] die Größe des Suchbaums (9 Fakultät)
 +
 
 +
== Funktionsweise ==
 +
 
 +
KaBotte bestimmt zu einem gegebenen Move die möglichen (nach Karo-Physik) Folgezüge. Die neuen Züge werden in einer Queue gespeichert, für den jeweils ersten Zug in der Queue wird dieser Vorgang solange wiederholt bis der gesuchte Checkpoint gefunden wurde oder die Queue leer ist. Wenn ein Checkpoint erreicht ist, wurde er in der minimal möglichen Anzahl der Zügen erreicht.
 +
siehe [https://de.wikipedia.org/wiki/Breitensuche Breitensuche].
 +
 
 +
später mehr...
 +
 
 +
== Facts ==
  
Facts:
 
 
Programmiersprache: Java
 
Programmiersprache: Java
 +
 
Architektur: Multi-Threaded (GUI, Kommunikation, Pfadberechnung)
 
Architektur: Multi-Threaded (GUI, Kommunikation, Pfadberechnung)
 +
 
Pfadberechnung: Breitensuche (Wege zwischen CPs), Tiefensuche (Suche des optimalen Pfades durch alle CPs zum Ziel)
 
Pfadberechnung: Breitensuche (Wege zwischen CPs), Tiefensuche (Suche des optimalen Pfades durch alle CPs zum Ziel)
 +
 +
==aktueller Stand
 +
 +
Zur Zeit ist KaBotte in einer intensiven Testphase (läuft nur tagsüber) mit meinem Arbeitskollegen, die vollkommen freiwillig als Gegner für KaBotte herhalten müssen.
 +
 +
Der Bot beherrscht CPs (integraler Bestandteil) und TCs (kann zu sehr langer Laufzeit bei "großem" ZZZ führen).
 +
Aus den möglichen Zügen wird immer einer gewählt, der zu einer minimalen Pfadlänge führt.
 +
 +
2016-12-11: Ein Bug mit dem Richtungsmodus wurde behoben (Information, ob Rundkurs muss manuell erfasst werden)
 +
2016-12-14: Arbeit an einer GUI zur besseren Erfassung von Infos wie Rundkurs
 +
Momentan (Stand: 8.12.2016) beherrscht er CPs, TCs, ist in der Lage den Richtungsmodus zu interpretieren und fährt nach Möglichkeit nur auf der Ideallinie.
 +
 +
== ToDos ==
 +
 +
Ausbau des Multi-Threadings bei bei der Pfadsuche zwischen den CPs
 +
Vorberechnung/Caching der besten CP-Permutation
 +
Caching bereits berechneter Pfade pro Spiel (im Augenblick wird jeder Zug komplett neu berechnet)
 +
Heuristik zur Bestimmung des nächsten Zuges bzgl. Position der Gegner
  
 
[[Kategorie:Bot]]
 
[[Kategorie:Bot]]

Version vom 15. Dezember 2016, 15:02 Uhr

ist ein, seit Ende Oktober 2016 in Entwicklung befindlicher, Bot von maks. Erklärtes Ziel von KaBotte ist es, Re-Rennen fahren zu können (das kann noch ein wenig dauern) und performant genug zu sein, um auf einem Synology-NAS (DS213j) zu laufen.

Problematische Karten

Nr. &pixel=4&karoborder=1 117 : ohne TCs

Nr. &pixel=4&karoborder=1 167 die Größe des Suchbaums (9 Fakultät)

Funktionsweise

KaBotte bestimmt zu einem gegebenen Move die möglichen (nach Karo-Physik) Folgezüge. Die neuen Züge werden in einer Queue gespeichert, für den jeweils ersten Zug in der Queue wird dieser Vorgang solange wiederholt bis der gesuchte Checkpoint gefunden wurde oder die Queue leer ist. Wenn ein Checkpoint erreicht ist, wurde er in der minimal möglichen Anzahl der Zügen erreicht. siehe Breitensuche.

später mehr...

Facts

Programmiersprache: Java

Architektur: Multi-Threaded (GUI, Kommunikation, Pfadberechnung)

Pfadberechnung: Breitensuche (Wege zwischen CPs), Tiefensuche (Suche des optimalen Pfades durch alle CPs zum Ziel)

==aktueller Stand

Zur Zeit ist KaBotte in einer intensiven Testphase (läuft nur tagsüber) mit meinem Arbeitskollegen, die vollkommen freiwillig als Gegner für KaBotte herhalten müssen.

Der Bot beherrscht CPs (integraler Bestandteil) und TCs (kann zu sehr langer Laufzeit bei "großem" ZZZ führen). Aus den möglichen Zügen wird immer einer gewählt, der zu einer minimalen Pfadlänge führt.

2016-12-11: Ein Bug mit dem Richtungsmodus wurde behoben (Information, ob Rundkurs muss manuell erfasst werden) 2016-12-14: Arbeit an einer GUI zur besseren Erfassung von Infos wie Rundkurs Momentan (Stand: 8.12.2016) beherrscht er CPs, TCs, ist in der Lage den Richtungsmodus zu interpretieren und fährt nach Möglichkeit nur auf der Ideallinie.

ToDos

Ausbau des Multi-Threadings bei bei der Pfadsuche zwischen den CPs Vorberechnung/Caching der besten CP-Permutation Caching bereits berechneter Pfade pro Spiel (im Augenblick wird jeder Zug komplett neu berechnet) Heuristik zur Bestimmung des nächsten Zuges bzgl. Position der Gegner