unentscheiden müsste anders gewichtet werden, da ein "passiver" Bot schon sehr viele Punkte einnimmt, falls dieser die "Gewinnsumme" 15 beim Gegner erfolgreich verhindert.
Druckbare Version
unentscheiden müsste anders gewichtet werden, da ein "passiver" Bot schon sehr viele Punkte einnimmt, falls dieser die "Gewinnsumme" 15 beim Gegner erfolgreich verhindert.
So kann man das nicht rechnen!
"Für Tic Tac Toe gibt es 255.168 verschiedene Spielverläufe, von denen 131.184 mit einem Sieg des ersten Spielers enden, 77.904 mit einem Sieg des zweiten Spielers und 46.080 mit einem Unentschieden. " (Quelle: [ame="http://de.wikipedia.org/wiki/Tic_Tac_Toe"]Tic Tac Toe – Wikipedia[/ame])
find das ist ne richtig gute idee, allerdings kommt doch eigentlich eh immer unentschieden raus?
ich finde man hätte sich für 4 gewinnt entscheiden sollen das funktioniert ja nach dem gleichen prinzip nur paar felder mehr und der stein muss "runterrutschen" :D
Vorschlag für nächsten Contest? 'Corewars' - Dummerweise aber nur in Assembler.
btw wieso ist als Tag 'phpisgay' ? :D
Ich verstehe schon, was ihr für Bedenken habt. Ich werde das mit BlackBerry nochmals kurz besprechen.
Bin dabei. :P
Hab nur noch ne Frage unzwar muss unser Programm prüfen ob jemand gewonnen hat und dann nen entsprechenden return Wert geben oder einfach immer nur Steine setzen und der Schiedsrichter wertet das dann aus ?!
Bin auch dabei.
Aktuell muss es einfach nur Steine setzen. Ein Programm von mir wird eure Programme dann gegeneinander antreten lassen und prüft den gewinner etc.