Vorstellung der aktuellen Simulation:
Inzwischen gibt es „Traces“ als echt Objekte (bzw. Terraineigenschaft). Sie werden also auch wieder nach einer gewissen Zeit „weggeräumt“. Der Trace-Parameter kann auch wieder als Input in die Eprobots rückgekoppelt werden, was auch gerne aktiv ausgenutzt wird 🙂
Für das Thema Dynamik habe ich mal wieder den Klassiker aus der Schublade geholt: Feinde die sich von Eprobots ernähren, bzw. „EprobotEater“. Eine „Master-Control“ regelt das geschehen, so dass immer etwas los ist. Also: Gibt es keine Eprobots mehr werden neue Eprobots erzeugt, gibt es genug Eprobots aber keine EprobotEater, werden EprobotEater initialisiert usw. Die Energieobjekte haben wieder eine unendliche Haltbarkeit.
Data Memory Scaling
Hintergrund ist, dass ich den Eprobots testweise einen größeren Datenspeicher gegeben habe (geben wollte) und dabei feststellte, dass die Eprobots weniger aktiv waren. Der Grund ist, dass es dann unwahrscheinlicher ist, dass die eine Ausgabespeicherzelle getroffen wird. Mit den Eingabewerten verhält es sich genauso. Die Idee war dann, einfach die Ein- und Ausgabewerte mit einer bestimmten Blockgröße zu wiederholen. Zum Beispiel bei einer Datenspeichergröße von 500 Werten mit einer Blockgröße von 20. Die Eingabewerte können dann einfach immer wieder wiederholt werden, was einfach ist. Was macht man aber mit den Ausgabewerten? Meine Lösung dafür lautet: Verknüpfe alle Ausgabewerte mit XOR um den finalen Ausgabewert zu erhalten. Funktioniert sehr gut.
Laufzeit-Überwachung
Ein weiteres Problem zum Thema Laufzeit der OISC-Programmausführungen bin ich auch angegangen. Normalerweise lief es so, dass das Programm normal abgearbeitet wird, aber nach maximal 1000 Schritten abgebrochen wird. Die Laufzeit hatte aber keinerlei Auswirkungen auf die Simulation und so konnte es sein, dass sich Eprobots entwickelten, die immer die vollen 1000 Schritte ausnutzen, obwohl sie evt. gar nicht viel „berechnet“ haben oder schlicht und ergreifend nachdem sie den Ausgabewert gesetzt haben in eine Endlosschleife gesprungen sind. Den Eprobots machte das nichts aus, die Simulationsgeschwindigkeit leidete dann aber spürbar. Also habe ich endlich auch die Anzahl der Ausführungsschritte in die Simulation einfließen lassen. Zu lange Ausführungszeiten werden nun bestraft, indem die Lebenszeit des individuellen Eprobot verringert wird. Dies führt automatisch zu „effizienten“ Programmen. Dabei ist es wichtig darauf zu achten die Strafe nicht so hart zu machen, dass nur völlig simple Programme entstehen, aber eben auch stark genug, damit man keine sinnlosen Endlosschleifen erhält. Ich musste diesbezüglich aber gar nicht viel rumprobieren.
Codepen: https://codepen.io/setreset/pen/WYJNvx
Die Simulation ist im Branch „dev_1“ des EprobotsJS2-Repositories gesichert.
thewehr 