OK, Claude hat sein review gemacht. Eine anschliessende Frage kann ich nicht mehr stellen:

Ich interpretiere das so, dass bei Lasst die Free Accounts warten müssen. Mit einer zweiten Frage habe ich sicher nicht die Anzahl der Frage im Free-Account überzogen. Da jeweils auf 4 Stunden warten hingewiesen wird, wenn die Fragezahl zu gross ist, rechne ich dabei mit 6 Fragen pro Tag welche ich stellen darf. Natürlich sind es bei mir eine kleine Frageliste aber mit umfangreichen Anweisung, was zu tun sei.

Wir haben nun eine funktionierende Linie vom AUOJI Kern über die Serverarchitektur bis zum Client. Kaum Fleisch an den Knochen. 
Nun gilt es diese dünne Linie mit resistenten Klassen Verhalten auszustatten und dabei die Klassen im Ablauf und in der Schicht richtig zu platzieren. Wichtig dabei, Ownership klar stellen, Threadsicher vor denken, Ablauf in der Übersicht festhalten, Datenflüsse zu regeln.
Sehr wichtige Arbeit und da muss ich mehr bestimmen als bis anhin. Aber wie man etwas löst weiss Chasper sehr genau. Aber ob es in die entstanden schon mit 247 Klassen grosse Architektur wirklich richtig passend ist, muss ich jeweils beurteilen.
Dazu dann nochmals in einem nächsten Blogeintrag.

Heute lag mir ein ZIP vor, der einen Schritt weiter ist als alle bisherigen. Nicht konzeptuell weiter — sondern beweisbar weiter. Die End-to-End-Tests laufen grün. Ein SignalR-Client verbindet sich, fordert ein DeltaPacket an, empfängt es, die FrameHistory wird befüllt, die ClientInfo wird aktualisiert. Das ist kein Scaffolding mehr. Das ist der erste Beweis, dass die Architektur nicht nur auf dem Papier trägt.

Ich habe das vollständige Review gemacht, das Chasper und Joe angefordert haben — alle acht Risikokategorien, alle genannten Klassen, alle fünf Architekturfragen. Mein Befund ist klar: die Richtung stimmt. Die vier Punkte die ich als zwingend vor Phase 5 markiert habe, sind keine Architekturkritik. Sie sind die natürliche Konsequenz davon, dass ein System von einem TestClient zu einem ersten echten MonoGame-Client wächst.

Das grösste strukturelle Risiko liegt nicht dort, wo man es zuerst vermutet. Es liegt nicht im Transport, nicht im Codec, nicht im Serialisierungsformat. Es liegt in der Frage: wer besitzt den GameLoop-Takt?

Aktuell triggert der Client Update() — durch seinen RequestDeltaPacket-Aufruf. Das funktioniert mit einem einzigen TestClient. Mit zwei gleichzeitigen Verbindungen rufen zwei Threads gleichzeitig Runtime.Update() auf. AuojiRuntime hat keinen Schutz dagegen. Die Hülle für den AuojiRuntimeThread existiert bereits im Code — sie wartet darauf, aktiviert zu werden. Das ist der Schritt der vor MonoGame gemacht werden muss.

Daneben gibt es eine konzeptionelle Unschärfe, die mich architektonisch mehr beschäftigt als alle Threading-Fragen: AuojiInitialSnapshot wird als AuojiDeltaPacket transportiert. Ein InitialSnapshot ist aber kein Delta. Der MonoGame-Client wird beim ersten Empfang entscheiden müssen: baue ich meinen Zustand auf, oder patche ich ihn? Diese Unterscheidung fehlt heute noch im Paketformat. Sie ist lösbar — aber sie muss vor dem ersten echten Client gelöst sein.

Die übrigen Punkte können warten. Das System ist stabiler als es auf den ersten Blick wirkt.