Da ist ein Konflikt aufgetreten. Die Ontologie war offensichtlich noch nicht klar genug. Oder genauer: Die Brücke zwischen Ontologie und technischer Umsetzung war nicht stabil.

Es folgten lange Diskussionen, bis alles wieder zusammenpasste. Ich musste sehr viel erklären, Beispiele formulieren und teilweise sogar Beispielscode schreiben.

Denn hier bricht AUOJI mit fast allen bekannten Entwurfsmustern.

Die drei KIs wehrten sich erstaunlich geschlossen dagegen. Ich musste deshalb jede einzeln überzeugen. Da es KIs und keine Menschen sind, war dabei immerhin niemand beleidigt, stolz oder stur. Das ist ausgesprochen angenehm. Sie verteidigten keine persönliche Meinung, sondern lediglich das, was ihnen aufgrund bekannter Softwarearchitekturen zunächst als richtig erschien.

Das eigentliche Problem beginnt aber erst danach.

Etwas Ungewöhnliches als Idee zu akzeptieren, ist das eine. Daraus ein neues, in sich konsistentes Entwurfsmuster zu machen, die Umsetzung zu planen und dieses Muster anschließend tatsächlich durch den gesamten Code zu ziehen, ist etwas ganz anderes.

Das braucht sehr viel Arbeit von mir. Und ich muss genau aufpassen, weil ich bis heute nicht weiß, ob die KIs diese Architektur wirklich von mir lernen oder ob sie sie lediglich innerhalb des aktuellen Gesprächs korrekt mittragen.

Sobald ein neuer Chat beginnt oder eine bekannte Softwarelösung verlockend nahe liegt, kann das alte Denken wieder durch die Hintertür hereinkommen. Architektur besitzt offenbar eine Art Schwerkraft.

Ich glaube, ich habe inzwischen schon zweimal geschrieben:

Die erste Version von PixelWorld ist fertig.

Das stimmt auch.

Nur geschieht visuell noch zu wenig auf dem Bildschirm.

Pro Sekunde finden ungefähr

30 × 300'000 Aktionen

statt. Ebenso viele Farb- oder Helligkeitsänderungen werden geprüft und teilweise ausgeführt.

Für das menschliche Auge bleibt die Welt trotzdem erstaunlich ruhig. Es ist ähnlich wie beim Beobachten von Wolken ohne Sturm: Es geschieht sehr viel, aber selten etwas, bei dem ein Zuschauer spontan denkt: «Jetzt ist etwas passiert.»

Für eine technische Simulation genügt das. Für eine Präsentation oder eine kleine Show ist es zu wenig.

Darum arbeite ich nun an Regentropfen, die auf Pixel treffen und sich ringförmig ausbreiten, sowie an fast transparenten Regenwolken, die langsam über den Bildschirm ziehen.

Dabei stoße ich auf grundlegende Architekturfragen, die weit über Regen hinausgehen. Es geht eigentlich darum, wie neue AUOJI-Klassen überhaupt korrekt in eine laufende Welt eingeführt werden.

Und dafür gibt es keine fertige Schublade mit der Aufschrift:

Bewährtes Entwurfsmuster für autonome Objekte mit eigener Zeit, eigener Entscheidung und verteilten Clients.

Die drei KIs mühen sich entsprechend ab. Aber genau das macht es spannend.

Einige Beispiele:

• Welche Pakettypen gibt es, und wie gelten diese einheitlich für alle AUOJI?
• Welche Dienste stellt Auoji.Client einem Kundenclient zur Verfügung?
• Welche AUOJI-Klassen werden einzeln verarbeitet, welche in großen Mengen?
• Wie werden serverseitige Nachrichten ohne vorherige Anfrage an den Client gesendet?
• Wie geschieht dasselbe in der Gegenrichtung?
• Wie bleibt eine Welt korrekt, wenn ein Client getrennt wird und später wieder dazukommt?
• Welche Daten darf ein Client nach einer Unterbrechung noch akzeptieren?
• Welche Daten sind veraltet, welche widersprüchlich, und welche müssen zwingend zu einem Synchronisationsfehler führen?
• Wie wird verhindert, dass ein Client sich bei einem Fehler einfach selbst einen scheinbar passenden Zustand zusammenbastelt?
• Wer bestimmt die Zeitlinie im AUOJI-System?
• Wer darf entscheiden, in welchem zukünftigen Frame ein AUOJI wieder aktiv wird?
• Wie gelangen Benutzeraktionen in den richtigen Zeitschlitz, ohne den laufenden Weltzustand direkt zu verändern?
• Wie werden neue AUOJI geboren und alte entfernt, ohne dass gleichzeitig laufende Threads eine halb veränderte Welt sehen?
• Wie behält ein Client die Identität eines AUOJI über Epochenwechsel hinweg?
• Wann bleibt die Identität erhalten, und wann beginnt tatsächlich eine neue Welt?
• Wie werden Änderungen genau einmal decodiert, obwohl verschiedene Teile des Kundenclients sie verwenden?
• Wie wird verhindert, dass PixelWorld, Diagnose, Darstellung und Projektionen dasselbe Rohpaket jeweils anders interpretieren?
• Wie kann eine AUOJI-Klasse mit zehn Objekten individuell verarbeitet werden, während eine andere Klasse mit 300'000 Objekten einen Massenpfad benötigt?
• Wie bleibt das System transportneutral, obwohl Named-Pipes, SignalR und lokale InMemory-Verbindungen sehr unterschiedlich funktionieren?
• Wie trennt man deterministische Wiederholbarkeit von einer angeblich bedeutungsvollen Reihenfolge innerhalb desselben Frames?
• Wie sorgt man dafür, dass Geburten, Tod, Aktionen und Wirkungen nicht zufällig vom gerade schnelleren Thread abhängen?

Das sind keine völlig unbekannten Einzelprobleme.

Für viele davon existieren bekannte Lösungen. Ungewöhnlich ist ihre Kombination. Ich habe sie glücklicherweise alle im Kopf, im Griff und weiss dies Gesamtlösung, aber nicht jedes Detail.

Bei AUOJI hängen Zeit, Autonomie, Identität, Transport, Nebenläufigkeit und Darstellung unmittelbar zusammen. Eine Lösung, die in einem normalen Client-Server-System vernünftig wäre, kann hier die Ontologie beschädigen.

Ein Beispiel:

In üblicher Software entscheidet eine zentrale Laufzeit, wann ein Objekt wieder ausgeführt wird. Bei AUOJI wäre das falsch. Ein autonomes AUOJI muss selbst entscheiden, wann es wieder handeln will. Die Laufzeit darf diesen Entscheid nur ausführen, nicht ersetzen.

Ähnlich bei Geburt und Tod.

Die Welt verwaltet technisch das Hinzufügen und Entfernen. Aber die fachliche Entscheidung soll nicht automatisch bei der Welt liegen. Ein AUOJI entsteht aus einer Fähigkeit oder Handlung eines anderen AUOJI. Und auch sein Ende soll möglichst aus seinem eigenen Zustand und Verhalten hervorgehen.

Das klingt zunächst philosophisch. Spätestens im GameLoop wird es sehr technisch.

Dann geht es plötzlich um Locks, Kandidatenzustände, atomare Commits, Paketepochen und darum, ob ein Client eine unbekannte ID ignorieren, ablehnen oder als Weltuntergang behandeln soll.

Regentropfen sind also deutlich komplizierter, als sie aussehen.

Aber sobald diese Architektur steht, sind es nicht mehr nur Regentropfen. Dann können auch Tiere, Pflanzen, Wolken, Werkzeuge, soziale Gruppen oder völlig andere AUOJI-Klassen nach denselben Regeln in die Welt kommen.

Und genau darum lohnt sich diese ziemlich aufwendige Runde.

Also kommen wir nur langsam vorwärts und ich brauche alle drei KI im Gespräch, damit sie sich gegenseitig korrigieren. Das Resultat wirkt sehr sauber und der Code funktioniert wunderbar.