In den letzten Wochen habe ich ein Tutorial für Eprobots JS erstellt. Dafür habe ich Schritt für Schritt eine auf das Nötigste reduzierte Variante einer Eprobots-Simulation aufgebaut und erkläre nebenbei die Hintergründe und notwendigen Änderungen.
Das Ganze kommt ohne externe Javascript-Bibliotheken und CSS aus. Es sind Grundkenntnisse in HTML und
Javascript notwendig. Im Idealfall auch Erfahrungen mit Javascript-Klassen.
Eprobots JS Tutorial (PDF): Link 1 Link 2
Es geht weiter. Das wichtigste neue Feature: Gift. Dies können die Eprobots aussondern, was natürlich etwas Energie kostet. Dafür zieht es EprobotEatern, die über so ein Feld stolpern auch Lebensenergie ab. Nach einer Weile verschwindet ausgelegtes Gift aber auch.
Zum Thema Traces: Ich habe dieses Feature benutzt damit die Eprobots eher wurmähnlich aussehen. Aber diese habe ich jetzt anders durch eine explizite „tails“-Eigenschaft gelöst. Traces gibt es trotzdem noch, aber der Aufräummechanismus ist jetzt weniger FIFO sondern mehr stochastisch. Dadurch heben stark frequentierte Bereiche mit der Zeit ab.
Es sind zwei neue Youtube-Videos entstanden:
Kurzfassung mit Smartphone-Kamera
Simulationslauf von 2 Stunden mit Screen Capturing
Auf Codepen gibt es die neue Version ebenfalls wieder: https://codepen.io/setreset/pen/oOvzxJ
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.
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.
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.
In einem weiteren Szenario habe ich mit Farben und „Traces“ experimentiert. Die Traces sind hier einfach so umgesetzt, dass nichts auf der Zeichenfläche gelöscht wird. Es entstehen so interessante Muster. Visuell wird das Ganze dadurch aufgepeppt, dass die Eprobots mit jedem Schritt eine andere Farbe erhalten. Dies wird durch lineare Veränderung des H-Parameters im HSL-Farbraum erreicht.
In diesem Zuge möchte ich auf meinen Tumblr-Blog https://eprobots.tumblr.com/ hinweisen. Es soll eine Sammelstelle für alle möglichen Medien im Zusammenhang mit den Eprobots sein.
Eine Demo gibt es im Branch „voll_bunt“ des Github-Repositories.
Ich habe mich wieder auf die zellenbasierte Eprobots-Simulation zurückbesinnt und das Projekt noch einmal neu aufgezogen. Es gibt jetzt endlich eine schnelle Zeichenfunktion, um auch größere Welten in Echtzeit simulieren zu können. Außerdem möchte ich komplexere Szenarien entwerfen und dafür wird ein Neuentwurf hilfreich sein.
Das Projekt ist „Work in Progress“ und liegt hier auf Github: https://github.com/setreset/eprobots_js_2
Damit habe ich dann eine „Haustier-Demo“ auf einem Raspi realisiert. Dafür habe ich mir das 7 Zoll Touch Screen Display samt Gehäuse für meinen Raspi 3 geholt.
Die Idee war, die Eprobots, wie bei Haustieren, durch notwendige „Fütterung“ abhängig vom „Besitzer“ zu machen. Dazu gibt es stationäre Energieobjekte, die eine bestimmte Energiemenge haben. Realisiert durch einen Zähler in den Energieobjekten. Dieser wird jedes mal dekrementiert, sobald sich ein Eprobot bedient. Ist der Zähler auf 0 verschwindet das Energieobjekt. Ich habe versucht den Zähler so zu initialisieren, dass das Futter bis zu einen Tag ausreicht.
Interaktiv wird das ganze dann, in dem neues „Futter“ durch den Touchscreen gesetzt werden kann.
Die Demo gibt es im Branch „haustier-mode“ des Github-Repositories.
Weiteres zu Eprobots JS 2 in Kürze…
Ich möchte noch ein wenig Bewegtbild zu „Eprobots JS Matter“ an dieser Stelle nachreichen:
Demo auf Codepen: https://codepen.io/setreset/pen/pLBmPq
Demo auf Codepen: https://codepen.io/setreset/pen/jxyjaZ
Ich bin auf matter.js gestoßen und bin davon begeistert, weil es sich auf den Aspekt 2D-Physikengine konzentriert, performant ist und eine einfache API hat. Demzufolge wollte ich umsatteln, bzw. die Engine wenigstens für Eprobots einmal ausprobieren. Das hat gut funktioniert. Hier kann das Ergebnis auf Codepen angesehen werden: https://codepen.io/setreset/pen/pLBmPq
Eine Veränderung gegenüber den vorherigen Versionen ist die Tatsache, dass es wieder getrennte Programm- und Datenspeicher gibt. Dadurch kann der Datenspeicher wesentlich kleiner als der Programmspeicher gehalten werden. Das führt dazu, dass die Wahrscheinlichkeit größer ist, dass die Ausgabezellen durch OISC-Operationen zufällig adressiert werden. Dies gilt sowohl für das Initalisieren der OISC-Programme beim Erzeugen der ersten Eprobots-Generation, als auch für Mutationen während der Fortpflanzung. Subjektiv betrachtet, sind die Eprobots so von anfang an agiler, bzw. fitter.
Matter.js lässt sich auch um Features erweitern, wie zum Beispiel ein auto-wrap. Gemeint ist damit der Fall dass ein Objekt den Rand überschreitet und am gegenüberliegenden Rand wieder auftaucht.
Zusätzlich habe ich auch eine Möglichkeit gefunden mit „Sensors“ Input aus der Umgebung in die Eprobots zurückzuführen. Das kann man sich vorstellen wie eine „Unterlegscheibe“, welche die Kollisionen anders verarbeitet als der Eprobot. Die Kollisionsevents der „Unterlegscheibe“ werden so verarbeitet, dass der Eprobot sie wahrnehmen kann, führen aber zu keiner Gegenreaktion in der Physikengine, im Gegensatz zum eigentlichen Eprobots-Körper. Dies ist für mich aber noch experimentell und verbraucht auch mehr CPU-Leistung, weswegen es in der Demo vorerst noch deaktiviert ist.
Ich habe es jetzt nach längerer Zeit geschafft, mich erneut mit der Javascript-Gameengine Phaser zu beschäftigen. Die Bibliothek hat sich deutlich weiterentwickelt und mein Ziel war es mein damaliges Beispiel mit der aktuellen Version neu umzusetzen und dann auch eine Fullscreen-Funktion einzubauen und das ganze zu einer „richtigen“ Eprobots-Simulation auszubauen. Dazu musste ich mich mit der neuen Physikengine beschäftigen. In der aktuellen Phaser-Version gibt es verschiedene Physik-Systeme: Arcade Physics, P2 Physics, Ninja Physics usw. Ich habe mich auf P2 Physics konzentriert. Das war die Pflicht. Die Performance der Simulation ist erstaunlich gut, auch mit mehreren hundert Objekten.
Die Kür war dann für mich persönlich also endlich meine OISC-Verhaltenssteuerung in die Agenten dieser Simulation einzubauen. Zuerst dachte ich, dass man Berechnung und Verwendung der Steuerwerte nicht in jedem einzelnen Frame machen sollte/bräuchte, aber die Bewegungen sehen so besser und natürlicher aus und die Performance ist trotzdem noch erstaunlich gut. Im Detail läuft es so ab, das die letzten beiden Speicherstellen zur Steuerung des Winkels und der Geschwindigkeit verwendet werden. Aus diesen beiden Werten wird der Impulsvektor berechnet der zur absoluten Geschwindigkeit addiert wird. Die Werte aus den Speicherzellen werden wieder mit Modulo in einen gültigen Bereich gemappt, um in jedem Fall einen verwendbaren Wert zu erhalten (Geschwindigkeit 0 bis 100, Winkel 0 bis 360). Die absolute Geschwindigkeit begrenze ich auch auf 450 Pixel/Sekunde, da es sich gezeigt hat, dass die Individueen sonst schneller umherrasen, als man es mitverfolgen kann, denn umso schneller ein Individuum ist, umso besser kann es sich fortpflanzen.
In dieser Eprobots-Simulation kann erstmals auch ein Körperparameter mitevolviert werden: Die Größe. Ich habe aber auch hier die Maximalgröße beschränkt, weil es sonst schnell aus dem Ruder läuft (große Individuen können sich besser vermehren). Zusätzlich habe ich eingebaut, dass sich der Maximalimpuls verringert, umso größer das Objekt ist, so dass größere Individuen träger sind.
Grundprinzip von Eprobots
Hier nochmal ein paar Sätze zum Grundprinzip. Genaueres kann der Dokumentation zu den zellenbasierten Eprobots entnommen werden. Es werden zufällige Indivuduen erzeugt und kontinuierlich Nahrung verteilt. Stößt ein Individuum gegen ein Nahrungsobjekt, wird das Nahrungobjekt entfernt und in der Nähe ein neues Individuum erzeugt, was die Eigenschaften des Elternobjektes erbt, aber auch einem Mutationsschritt unterworfen ist. Entstehen zufällig Eprobots die umherwandern, wird sich dieses erfolgreiche Verhalten durchsetzen. Nach einer gewissen Lebenszeit erstarren die Eprobots (rote Objekte oder „Fossilien“) und sind nur noch Hindernisse für die lebenden Eprobots, wodurch eine Art Umwelt entsteht.
Wichtig: Es gibt eine Maximalanzahl an Individuen, damit es nicht zu Performanceproblemen kommt.
Durch Experimente an der Simulation und den Einstellungen habe ich ein interessantes Simulationsszenario erhalten. Zur Dokumentation gibt es hier nun auch einen eigenen Eprobots JS – Bereich. Dort sammle ich auch Medien und man kann unterschiedlichen Versionen aufrufen (Snapshots).
Die wichtigsten Neuerungen in der Simulation: Neue Form der Nahrungsverteilung. Die Eprobots müssen durch eine neue Aktionsoption aktiv Felder „fruchtbar“ machen. Die Populationsgröße wird beschränkt und ist nicht mehr gekoppelt an die Energiemenge. Dafür haben die Eprobots einen internen Energiespeicher und pflanzen sich fort, wenn es möglich ist.
Hier der Link zur aktuellen Simulationsvariante: Aktueller Snapshot
Ich habe in der letzten Zeit an einer JavaScript-Version meiner Eprobots gearbeitet. Das Prinzip ist das gleiche wie bei der alten Java-Version von Eprobots mit Dokumentation. Allerdings gibt es keine Räuber-Beute-Beziehungen. Dafür gibt es Schieberegler um live die Simulationsparameter verändern zu können.
Kurzversion des Funktionsprinzip von Eprobots
Es werden einfache Individuen mit einem Lebenszyklus und ihrer Umwelt simuliert. Die Evolutionen kommt folgendermaßen in’s Spiel: Die Steuerung eines Individuums erfolgt über ein eigenes Programm, welches von einem virtuellen subleq-Prozessor ausgeführt wird. Und dieses Programm stellt das Genom dar und wird von Generation zu Generation mit einem Mutationsfaktor weitergegeben. Initial bzw. wenn keine Individuen mehr vorhanden sind, werden neue Individuen mit zufälligen Programmen erzeugt
Fossilien
In den aktuellen Standardeinstellungen habe ich eine starke „Fossilienbildung“ eingestellt, in der Hoffnung interessante Muster erzeugen zu können. Die aktiven Eprobots sind rot. Nach der aktiven Phase werden die Eprobots zu Fossilien, wobei sie mit fortschreitender Zeit ihre Farbe verändern. Nach einer einstellbaren Zeit verschwinden auch die Fossilien. Die Fossilien sind Hindernisse für die aktiven Eprobots und verändern ihre Umwelt.
thewehr 