HERZLICHEN GLÜCKWUNSCH an @kuroineko für den besten Beitrag und den Gewinn der 200 Bounty von @TheBestOne (exzellentes Sportsgeist!).
Schreiben Sie ein Programm, um so viele Bilder wie möglich einzufärben, bevor Oppositionsprogramme dies tun.
Regeln in Kürze
- Ihr Programm erhält ein Bild, Ihre Farbe und die Ganzzahl N.
- In jeder Runde erhalten Sie Pixel-Updates von anderen Programmen und werden nach Ihren N Updates gefragt.
- Sie können alle weißen Pixel aktualisieren, die neben einem Pixel Ihrer Farbe liegen.
- Das Programm, das die meisten Pixel hinzugefügt hat, gewinnt.
Regeln im Detail
Ihr Programm erhält einen PNG-Bilddateinamen, eine Standardfarbe und eine Nummer N. Die Nummer N gibt die maximale Anzahl von Pixeln an, die Ihr Programm in jeder Runde einfärben darf.
Beispiel: MyProg arena.png (255,0,0) 30
Das Eingabebild ist ein Rechteck mit Seiten zwischen 20 und 1000 Pixeln. Es besteht aus schwarzen, weißen und farbigen Pixeln. Ihr Programm wählt möglicherweise eine Folge von weißen Pixeln aus, die Sie selbst einfärben möchten, unter der Bedingung, dass jedes neue Pixel mindestens eines der vier Nachbarpixel Ihrer eigenen Farbe hat. Das Bild enthält zunächst mindestens ein Pixel Ihrer Farbe. Es kann auch Farbpixel enthalten, denen kein Programm zugewiesen ist. Der Alphakanal wird nicht verwendet.
Ihr Ziel ist es, Ihre Gegner zu blockieren und Ihre Farbe in so viele Pixel wie möglich zu schreiben.
In jeder Runde akzeptiert Ihr Programm 1 oder mehr Nachrichtenzeilen auf STDIN und schreibt eine Zeile mit Pixelkoordinaten auf STDOUT. Denken Sie daran, STDOUT als ungepuffert zuzuweisen, oder leeren Sie den STDOUT-Puffer in jeder Runde.
Die Reihenfolge der Spieler, die in jeder Runde aufgerufen werden, wird nach dem Zufallsprinzip festgelegt. Dies bedeutet, dass ein Gegner (oder Ihr Programm) 2 Runden hintereinander haben kann.
Ihrem Programm werden colour (N,N,N) chose X,Y X,Y ... X,Y
Informationsnachrichten gesendet, die die Pixel beschreiben, die von Player-Programmen ausgefüllt werden. Wenn ein Spieler keine oder keine gültigen Züge ausführt, wird keine Nachricht über die Züge dieses Spielers gesendet. Ihr Programm erhält auch eine Nachricht über Ihre eigenen akzeptierten Züge (wenn Sie mindestens einen gültigen Zug angegeben haben). Das Pixel 0,0 befindet sich in der oberen linken Ecke des Bildes.
Beim Empfang pick pixels
gibt Ihr Programm X,Y X,Y ... X,Y
bis zu N Pixel aus (eine leere Zeichenfolge, die nur aus einem '\ n' besteht, ist zulässig). Die Pixel müssen in der Reihenfolge des Zeichnens sein. Wenn ein Pixel ungültig ist, wird es ignoriert und ist nicht im Bericht an die Spieler enthalten. Ihr Programm muss nach dem Start innerhalb von 2 Sekunden initialisiert werden, aber nur 0,1 Sekunden, um mit einer Antwort pro Runde zu antworten. Andernfalls wird diese Runde verpasst. Eine Pixelaktualisierung, die nach 0,1 Sekunden gesendet wird, zeichnet einen Fehler auf. Nach 5 Fehlern wird Ihr Programm angehalten und es werden keine Aktualisierungen oder pick pixels
Anfragen gesendet .
Wenn das Richterprogramm von jedem nicht gesperrten Spielerprogramm eine leere oder ungültige Pixelauswahl erhält, wird das Bild als vollständig betrachtet und Programme erhalten die Nachricht "exit". Programme müssen nach Erhalt von "exit" beendet werden.
Wertung
Der Richter erhält Punkte, wenn das Bild vollständig ist. Ihre Punktzahl ist die Anzahl der aktualisierten Pixel geteilt durch die durchschnittliche Pixelerfassung dieser Runde, ausgedrückt als Prozentsatz.
Die Anzahl der vom Player zum Bild hinzugefügten Pixel beträgt A. Die Gesamtanzahl der von allen P-Playern hinzugefügten Pixel beträgt T.
avg = T/P
score = 100*A/avg
Punkte veröffentlichen
Ein Referenzgegner "The Blob" wird gegeben. Benenne für jede Antwort deinen Bot mit einem Namen, einer Sprache und deiner Punktzahl (Durchschnitt von Arena 1 bis 4) gegen den Referenzgegner. Ein Bild oder eine Animation von einem Ihrer Schlachten wäre auch gut. Der Gewinner ist das Programm mit der höchsten Punktzahl gegen den Referenz-Bot.
Wenn sich der Blob als zu leicht zu besiegen erweist, füge ich möglicherweise eine zweite Runde mit einem stärkeren Referenzgegner hinzu.
Sie können auch gerne mit 4 oder mehr Player-Programmen experimentieren. Sie können Ihren Bot auch mit anderen Bots testen, die als Antworten veröffentlicht wurden.
Der Richter
Das Judge-Programm benötigt die gemeinsame Python Imaging Library (PIL) und sollte unter Linux einfach von Ihrem Betriebssystem-Paket-Manager aus zu installieren sein. Ich habe einen Bericht, dass PIL unter Windows 7 nicht mit 64-Bit-Python funktioniert. Überprüfen Sie daher, ob PIL für Sie funktioniert, bevor Sie mit dieser Herausforderung beginnen (aktualisiert am 29.01.2015).
#!/usr/bin/env python
# Judge Program for Image Battle challenge on PPCG.
# Runs on Python 2.7 on Ubuntu Linux. May need edits for other platforms.
# V1.0 First release.
# V1.1 Added Java support
# V1.2 Added Java inner class support
# usage: judge cfg.py
import sys, re, random, os, shutil, subprocess, datetime, time, signal
from PIL import Image
ORTH = ((-1,0), (1,0), (0,-1), (0,1))
def place(loc, colour):
# if valid, place colour at loc and return True, else False
if pix[loc] == (255,255,255):
plist = [(loc[0]+dx, loc[1]+dy) for dx,dy in ORTH]
if any(pix[p]==colour for p in plist if 0<=p[0]<W and 0<=p[1]<H):
pix[loc] = colour
return True
return False
def updateimage(image, msg, bot):
if not re.match(r'(\s*\d+,\d+)*\s*', msg):
return []
plist = [tuple(int(v) for v in pr.split(',')) for pr in msg.split()]
plist = plist[:PIXELBATCH]
return [p for p in plist if place(p, bot.colour)]
class Bot:
botlist = []
def __init__(self, name, interpreter=None, colour=None):
self.prog = name
self.botlist.append(self)
callarg = re.sub(r'\.class$', '', name) # Java fix
self.call = [interpreter, callarg] if interpreter else [callarg]
self.colour = colour
self.colstr = str(colour).replace(' ', '')
self.faults = 0
self.env = 'env%u' % self.botlist.index(self)
try: os.mkdir(self.env)
except: pass
if name.endswith('.class'): # Java inner class fix
rootname = re.sub(r'\.class$', '', name)
for fn in os.listdir('.'):
if fn.startswith(rootname) and fn.endswith('.class'):
shutil.copy(fn, self.env)
else:
shutil.copy(self.prog, self.env)
shutil.copy(imagename, self.env)
os.chdir(self.env)
args = self.call + [imagename, self.colstr, `PIXELBATCH`]
self.proc = subprocess.Popen(args, stdin=subprocess.PIPE,
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
os.chdir('..')
def send(self, msg):
if self.faults < FAULTLIMIT:
self.proc.stdin.write(msg + '\n')
self.proc.stdin.flush()
def read(self, timelimit):
if self.faults < FAULTLIMIT:
start = time.time()
inline = self.proc.stdout.readline()
if time.time() - start > timelimit:
self.faults += 1
inline = ''
return inline.strip()
def exit(self):
self.send('exit')
from cfg import *
for i, (prog, interp) in enumerate(botspec):
Bot(prog, interp, colourspec[i])
image = Image.open(imagename)
pix = image.load()
W,H = image.size
time.sleep(INITTIME)
total = 0
for turn in range(1, MAXTURNS+1):
random.shuffle(Bot.botlist)
nullbots = 0
for bot in Bot.botlist:
bot.send('pick pixels')
inmsg = bot.read(TIMELIMIT)
newpixels = updateimage(image, inmsg, bot)
total += len(newpixels)
if newpixels:
pixtext = ' '.join('%u,%u'%p for p in newpixels)
msg = 'colour %s chose %s' % (bot.colstr, pixtext)
for msgbot in Bot.botlist:
msgbot.send(msg)
else:
nullbots += 1
if nullbots == len(Bot.botlist):
break
if turn % 100 == 0: print 'Turn %s done %s pixels' % (turn, total)
for msgbot in Bot.botlist:
msgbot.exit()
counts = dict((c,f) for f,c in image.getcolors(W*H))
avg = 1.0 * sum(counts.values()) / len(Bot.botlist)
for bot in Bot.botlist:
score = 100 * counts[bot.colour] / avg
print 'Bot %s with colour %s scored %s' % (bot.prog, bot.colour, score)
image.save(BATTLE+'.png')
Beispielkonfiguration - cfg.py
BATTLE = 'Green Blob vs Red Blob'
MAXTURNS = 20000
PIXELBATCH = 10
INITTIME = 2.0
TIMELIMIT = 0.1
FAULTLIMIT = 5
imagename = 'arena1.png'
colourspec = (0,255,0), (255,0,0)
botspec = [
('blob.py', 'python'),
('blob.py', 'python'),
]
Der Blob - der Referenzgegner
# Blob v1.0 - A reference opponent for the Image Battle challenge on PPCG.
import sys, os
from PIL import Image
image = Image.open(sys.argv[1])
pix = image.load()
W,H = image.size
mycolour = eval(sys.argv[2])
pixbatch = int(sys.argv[3])
ORTH = ((-1,0), (1,0), (0,-1), (0,1))
def canchoose(loc, colour):
if pix[loc] == (255,255,255):
plist = [(loc[0]+dx, loc[1]+dy) for dx,dy in ORTH]
if any(pix[p]==colour for p in plist if 0<=p[0]<W and 0<=p[1]<H):
return True
return False
def near(loc):
plist = [(loc[0]+dx, loc[1]+dy) for dx,dy in ORTH]
pboard = [p for p in plist if 0<=p[0]<W and 0<=p[1]<H]
return [p for p in pboard if pix[p] == (255,255,255)]
def updateimage(image, msg):
ctext, colourtext, chose, points = msg.split(None, 3)
colour = eval(colourtext)
plist = [tuple(int(v) for v in pr.split(',')) for pr in points.split()]
for p in plist:
pix[p] = colour
skin.discard(p)
if colour == mycolour:
for np in near(p):
skin.add(np)
board = [(x,y) for x in range(W) for y in range(H)]
skin = set(p for p in board if canchoose(p, mycolour))
while 1:
msg = sys.stdin.readline()
if msg.startswith('colour'):
updateimage(image, msg.strip())
if msg.startswith('pick'):
plen = min(pixbatch, len(skin))
moves = [skin.pop() for i in range(plen)]
movetext = ' '.join('%u,%u'%p for p in moves)
sys.stdout.write(movetext + '\n')
sys.stdout.flush()
if msg.startswith('exit'):
break
image.save('blob.png')
Arena 1
Arena 2
Arena 3
Arena 4
Ein Beispiel Battle - Blob vs Blob
Dieser Kampf hatte ein vorhersehbares Ergebnis:
Bot blob.py with colour (255, 0, 0) scored 89.2883333333
Bot blob.py with colour (0, 255, 0) scored 89.365
quelle
Antworten:
ColorFighter - C ++ - isst ein paar Schlucker zum Frühstück
BEARBEITEN
Gott, ich hasse Schlangen (tu einfach so, als wären sie Spinnen, Indy)
Eigentlich liebe ich Python. Ich wünschte, ich wäre weniger faul und hätte angefangen, es richtig zu lernen, das ist alles.
Trotzdem musste ich mich mit der 64-Bit-Version dieser Schlange herumschlagen, um den Richter zum Laufen zu bringen. PIL mit der 64-Bit-Version von Python unter Win7 zum Laufen zu bringen, erfordert mehr Geduld, als ich bereit war, mich dieser Herausforderung zu widmen. Am Ende bin ich (schmerzhaft) auf die Win32-Version umgestiegen.
Außerdem stürzt der Richter häufig schwer ab, wenn ein Bot zu langsam ist, um zu reagieren.
Da ich kein Python-Kenner bin, habe ich es nicht behoben, aber es hat mit dem Lesen einer leeren Antwort nach einem Timeout auf stdin zu tun.
Eine kleine Verbesserung wäre, die stderr-Ausgabe für jeden Bot in eine Datei zu legen. Dies würde die Nachverfolgung für das Post-Mortem-Debugging erleichtern.
Abgesehen von diesen kleinen Problemen fand ich den Richter sehr einfach und angenehm zu bedienen.
Ein dickes Lob für eine weitere erfinderische und unterhaltsame Herausforderung.
Der Code
Erstellen der ausführbaren Datei
Ich habe LODEpng.cpp und LODEpng.h zum Lesen von PNG-Bildern verwendet.
Auf die einfachste Art und Weise brachte ich dieser verzögerten C ++ - Sprache bei, wie man ein Bild liest, ohne ein halbes Dutzend Bibliotheken erstellen zu müssen.
Kompilieren und verlinken Sie einfach LODEpng.cpp zusammen mit dem Main und Bob ist Ihr Onkel.
Ich habe mit MSVC2013 kompiliert, aber da ich nur ein paar STL-Basiscontainer (Deque und Vektoren) verwendet habe, funktioniert es möglicherweise mit gcc (wenn Sie Glück haben).
Wenn nicht, probiere ich vielleicht einen MinGW-Build aus, aber ehrlich gesagt habe ich keine Lust mehr auf C ++ - Portabilitätsprobleme.
Ich habe in meinen Tagen ziemlich viel portables C / C ++ gemacht (auf exotischen Compilern für verschiedene 8- bis 32-Bit-Prozessoren sowie auf SunOS, Windows von 3.11 bis Vista und Linux von den Anfängen bis zu Ubuntu, das Zebra gurrt, oder was auch immer, denke ich Ich habe eine ziemlich gute Vorstellung davon, was Portabilität bedeutet, aber zu der Zeit mussten die unzähligen Diskrepanzen zwischen der GNU- und der Microsoft-Interpretation der kryptischen und aufgeblähten Spezifikation des STL-Monsters nicht auswendig gelernt (oder entdeckt) werden.
Ergebnisse gegen Swallower
Wie es funktioniert
Im Kern handelt es sich um ein einfaches Brute-Force-Floodfill-Pathing.
Die Grenze der Farbe des Players (dh die Pixel, die mindestens einen weißen Nachbarn haben) wird als Ausgangswert für den klassischen Entfernungsüberschwemmungsalgorithmus verwendet.
Wenn ein Punkt die Nähe einer feindlichen Farbe erreicht, wird ein Rückwärtspfad berechnet, um eine Folge von Pixeln zu erzeugen, die sich zum nächsten feindlichen Punkt bewegen.
Der Vorgang wird wiederholt, bis genügend Punkte für eine Antwort der gewünschten Länge gesammelt wurden.
Diese Wiederholung ist unglaublich teuer, besonders wenn man in der Nähe des Feindes kämpft.
Jedes Mal, wenn eine Reihe von Pixeln gefunden wurde, die von der Grenze zu einem feindlichen Pixel führen (und wir brauchen mehr Punkte, um die Antwort zu vervollständigen), wird die Überflutungsfüllung von Anfang an überarbeitet und der neue Pfad zur Grenze hinzugefügt. Dies bedeutet, dass Sie möglicherweise 5 oder mehr Überflutungen durchführen müssen, um eine 10-Pixel-Antwort zu erhalten.
Wenn keine feindlichen Pixel mehr erreichbar sind, werden arbitratische Nachbarn der Grenzpixel ausgewählt.
Der Algorithmus führt zu einer eher ineffizienten Überflutung, dies geschieht jedoch erst, nachdem der Ausgang des Spiels entschieden wurde (dh es gibt kein neutrales Gebiet mehr, für das man kämpfen kann).
Ich habe es so optimiert, dass der Richter nicht ewig die Karte auffüllt, sobald der Wettbewerb abgeschlossen ist. In seinem gegenwärtigen Zustand ist die Ausführungszeit im Vergleich zum Richter selbst vernachlässigbar.
Da die feindlichen Farben zu Beginn nicht bekannt sind, wird das ursprüngliche Bild der Arena gespeichert, um die Startbereiche des Feindes zu kopieren, wenn dieser seinen ersten Zug macht.
Wenn der Code zuerst abgespielt wird, wird er einfach ein paar beliebige Pixel füllen.
Dies macht den Algorithmus in der Lage, eine beliebige Anzahl von Gegnern und möglicherweise sogar neue Gegner, die zu einem zufälligen Zeitpunkt eintreffen, oder Farben, die ohne Startbereich erscheinen, zu bekämpfen (obwohl dies absolut keinen praktischen Nutzen hat).
Die Behandlung von Feinden auf Basis von Farbe pro Farbe würde es auch ermöglichen, dass zwei Instanzen des Bots zusammenarbeiten (unter Verwendung von Pixelkoordinaten, um ein geheimes Erkennungszeichen zu übergeben).
Hört sich nach Spaß an, das werde ich wahrscheinlich ausprobieren :).
Berechnungsintensives Pathing wird ausgeführt, sobald neue Daten verfügbar sind (nach einer Bewegungsmeldung), und einige Optimierungen (die Grenzaktualisierung) werden unmittelbar nach einer Antwort ausgeführt (um während der anderen Bots-Runden so viel wie möglich zu berechnen) ).
Auch hier könnte es Möglichkeiten geben, subtilere Dinge zu tun, wenn es mehr als einen Gegner gibt (z. B. einen Rechenvorgang abzubrechen, wenn neue Daten verfügbar werden), aber ich sehe jedenfalls nicht, wo Multitasking erforderlich ist, solange der Algorithmus vorhanden ist Volllast arbeiten können.
Performance-Probleme
All dies funktioniert nicht ohne schnellen Datenzugriff (und mehr Rechenleistung als das gesamte Appolo-Programm, dh Ihr durchschnittlicher PC, wenn Sie mehr als ein paar Tweets posten).
Die Geschwindigkeit ist stark vom Compiler abhängig. Normalerweise schlägt GNU Microsoft um 30% (das ist die magische Zahl, die ich bei drei anderen Code-Herausforderungen im Zusammenhang mit Pfaden bemerkt habe), aber dieser Kilometerstand kann natürlich variieren.
Der Code in seinem aktuellen Zustand bringt Arena 4 kaum ins Schwitzen. Der Windows-Leistungsmesser meldet eine CPU-Auslastung von 4 bis 7%, sodass er in der Lage sein sollte, mit einer 1000x1000-Karte innerhalb der Reaktionszeit von 100 ms fertig zu werden.
Das Herzstück eines jeden Pfadalgorithmus ist ein FIFO (möglicherweise priorisiert, aber nicht in diesem Fall), für das wiederum eine schnelle Elementzuweisung erforderlich ist.
Da das OP die Größe der Arena verbindlich einschränkte, habe ich einige Berechnungen angestellt und festgestellt, dass feste Datenstrukturen mit einer maximalen Größe (dh 1.000.000 Pixel) nicht mehr als ein paar Dutzend Megabyte verbrauchen, die Ihr durchschnittlicher PC zum Frühstück zu sich nimmt.
Unter Win7 und mit MSVC 2013 kompiliert, verbraucht der Code in Arena 4 ungefähr 14 MB, während die beiden Threads von Swallower mehr als 20 MB belegen.
Ich habe mit STL - Containern begonnen, um das Prototyping zu vereinfachen, aber STL hat den Code noch weniger lesbar gemacht, da ich nicht die Absicht hatte, eine Klasse zu erstellen, die jedes einzelne Datenbit kapselt, um die Verschleierung zu verbergen (ob das nun an meinen eigenen Unfähigkeiten liegt) Die Bewältigung des STL bleibt der Wertschätzung des Lesers überlassen.
Ungeachtet dessen war das Ergebnis so schrecklich langsam, dass ich zunächst dachte, ich würde versehentlich eine Debug-Version erstellen.
Ich denke, dies liegt zum einen an der unglaublich schlechten Microsoft-Implementierung der STL (wo zum Beispiel Vektoren und Bitsätze gebundene Prüfungen oder andere kryptische Operationen auf operator [] ausführen, die direkt gegen die Spezifikation verstoßen) und zum anderen am STL-Design selbst.
Ich könnte mit den grausamen Syntax- und Portabilitätsproblemen (z. B. Microsoft vs GNU) fertig werden, wenn die Leistungen vorhanden wären, aber dies ist sicherlich nicht der Fall.
Zum Beispiel
deque
ist es von Natur aus langsam, weil es viele Buchhaltungsdaten durcheinanderbringt, während es darauf wartet, dass der Anlass seine superschicke Größenänderung vornimmt, die mir gleichgültig ist.Natürlich hätte ich einen benutzerdefinierten Allokator und andere benutzerdefinierte Vorlagenbits implementieren können, aber ein benutzerdefinierter Allokator allein kostet ein paar hundert Codezeilen und den größten Teil eines Tages, um zu testen, was mit dem Dutzend von Schnittstellen zu tun ist, die er implementieren muss, während a Die handgefertigte äquivalente Struktur ist ungefähr null Codezeilen (obwohl gefährlicher, aber der Algorithmus hätte nicht funktioniert, wenn ich nicht gewusst hätte - oder geglaubt hätte - was ich sowieso tat).
Also habe ich schließlich die STL-Container in unkritischen Teilen des Codes aufbewahrt und meinen eigenen brutalen Allokator und FIFO mit zwei Arrays von ca. 1970 und drei nicht signierten Shorts erstellt.
Schlucken den Schlucker
Wie der Autor bestätigte, werden die fehlerhaften Muster des Schluckers durch Verzögerungen zwischen den Benachrichtigungen über feindliche Bewegungen und Aktualisierungen des Pfad-Threads verursacht.
Der System-Perfmeter zeigt deutlich, dass der Pfad-Thread die ganze Zeit 100% CPU verbraucht, und die gezackten Muster treten auf, wenn sich der Fokus des Kampfes auf einen neuen Bereich verlagert. Dies wird auch bei den Animationen deutlich.
Eine einfache aber effektive Optimierung
Nachdem ich mir die epischen Luftkämpfe zwischen Swallower und meinem Kämpfer angeschaut hatte, fiel mir ein altes Sprichwort aus dem Go-Spiel ein: Verteidigung aus der Nähe, aber Angriff aus der Ferne.
Darin liegt Weisheit. Wenn Sie versuchen, sich zu sehr an Ihren Gegner zu halten, verschwenden Sie wertvolle Moves, um jeden möglichen Pfad zu blockieren. Im Gegenteil, wenn Sie nur einen Pixel entfernt bleiben, vermeiden Sie wahrscheinlich, kleine Lücken zu schließen, die nur sehr wenig zunehmen würden, und setzen Sie Ihre Schritte ein, um wichtigeren Bedrohungen entgegenzuwirken.
Um diese Idee umzusetzen, habe ich einfach die Züge eines Feindes verlängert (die 4 Nachbarn jedes Zuges als feindliches Pixel markiert).
Dadurch wird der Suchalgorithmus einen Pixel von der feindlichen Grenze entfernt gestoppt, sodass sich mein Kämpfer um einen Gegner bewegen kann, ohne in zu viele Luftkämpfe verwickelt zu werden.
Sie können die Verbesserung sehen
(obwohl alle Läufe nicht so erfolgreich sind, können Sie die viel glatteren Umrisse bemerken):
quelle
Tiefen-erster Blob vs. Blob
Sprache = Python (3.2)
Score =
111.475388276153.34210035Update: Verwenden Sie jetzt eine benutzerdefinierte
Set
Klasse, um diepop()
Methode zum Erzeugen einer Art Rastermuster zu erhalten, die den Bereich, der zu Beginn abgedeckt wurde, drastisch verbessert und große Teile des Bildes vom Feind abschneidet. Hinweis: Ich verwende hierfür ein 12 x 12-Raster, das aus einer zufälligen Stichprobe von Rastergrößen die besten Ergebnisse für arena3 zu liefern schien (dasjenige, das vor dem Update die schlechteste Punktzahl erzielt hat). Es ist jedoch sehr wahrscheinlich, dass es optimaler ist Für die gegebene Auswahl von Arenen existiert eine Rastergröße.Ich habe eine einfache Änderung am Referenz-Bot vorgenommen, um die Auswahl praktikabler Punkte zu erleichtern, die von möglichst wenigen eigenfarbigen Punkten begrenzt werden. Eine Verbesserung könnte darin bestehen, dass auch mögliche Punkte ausgewählt werden, die von so vielen feindlichen Punkten wie möglich begrenzt werden.
dfblob.py:
Der ursprüngliche Richter wurde leicht modifiziert, um mit Python 3.2 zu arbeiten (und den Bots eine grobe Protokollierungsfunktion hinzuzufügen + das Bild der Arena regelmäßig zu speichern, um Animationen zu erstellen):
Die Arenaergebnisse folgen. Der dfblob bot erhielt für alle Arenen die rote Farbe.
Arena 1:
Arena 2:
Arena 3:
Arena 4:
quelle
convert -delay 5 -loop 0 result*.png animated.gif
obwohl einige der Gifs später manuell gekürzt werden mussten, um hier hochgeladen zu werdenSchlucker
Sprache = Java
Ergebnis =
162.3289512601408075169.4020975612382575Sucht nach Feinden und umgibt sie.
Möglicherweise müssen Sie eine längere Frist festlegen. Könnte einiges verbessert werden. Druckt manchmal ungültige Pixel.Update: Surrounds viel schneller. Verwendet einen anderen Thread zum Aktualisieren der Prioritäten. Gibt immer innerhalb von 0,1 Sekunden zurück. Die Punktzahl sollte nicht zu übertreffen sein, ohne zuzunehmen
MAX_TURNS
.Wie es funktioniert:
Dieser Bot verwaltet eine Prioritätswarteschlange mit Pixeln, die er hinzufügen kann. Die Priorität eines feindlichen Pixels ist 0. Die Priorität eines leeren Pixels ist 1 höher als die niedrigste Priorität, die es umgibt. Alle anderen Pixel haben die Priorität Integer.MAX_VALUE. Der Updater-Thread aktualisiert ständig die Prioritäten der Pixel. In jeder Runde werden die niedrigsten N Pixel aus der Prioritätswarteschlange entfernt.
Grüner Klecks gegen roten Schlucker
Blobs Score = 1.680553372583887225
Swallower's Score = 169.4020975612382575
Arena 1:
Arena 2:
Arena 3:
Arena 4:
Grüner Schlucker gegen roter Klecks
Blobs Score = 1.6852943642218457375
Swallower's Score = 169.3923095387498625
Arena 1:
Arena 2:
Arena 3:
Arena 4:
Red Swallower gegen Green Depth First Blob
Swallower's Score = 157.0749775233111925
Punktzahl des ersten Blobs der Tiefe = 18.192783547939744
Arena 1:
Arena 2:
Arena 3:
Arena 4:
Grüner Schlucker gegen roten Tiefen-ersten Klecks
Swallower's Score = 154.3368355651281075
Punktzahl des ersten Blobs der Tiefe = 18.84463249420435425
Arena 1:
Arena 2:
Arena 3:
Arena 4:
Green Blob gegen Red Depth First Blob gegen Blue Swallower:
Blobs Score = 6.347962032393275525
Punktzahl des ersten Blobs der Tiefe = 27.34842554331698275
Swallower's Score = 227.720728953415375
Arena 1:
Arena 2:
Arena 3:
Arena 4:
Hier ist Sam Yonnous Richter mit ein paar Änderungen, so dass Sie die Dateien und den Befehl separat angeben:
Beispiel cfg:
Hinweis: Jeder, der es schafft, den Schlucker zu schlucken, erhält ein Kopfgeld von 100 Ruf. Bitte posten Sie in den Kommentaren unten, wenn dies gelingt.
quelle
Zufällig, Sprache = Java, Ergebnis = 0,43012126100275
Dieses Programm fügt Pixel nach dem Zufallsprinzip auf dem Bildschirm ein. Einige (wenn nicht alle) Pixel sind nicht gültig. Nebenbei bemerkt sollte es schwierig sein, ein schnelleres Programm als dieses zu erstellen.
Arena 1:
Arena 2:
Arena 3:
Arena 4:
quelle