Befund: Unitys Mono 6.13 rechnet float32-Zwischenwerte doppelt genau (ECMA-335 I.12.1.3). Der erste Editor-Lauf fand 5 von 157 Golden- Abweichungen: Blickrichtung bis 1,6e-3 rad; in mirror_match Runde 7 verliert eine Einheit in Schritt 599 ihr Ziel, und der Kampf dauert 4,8 s länger. Eine Toleranz ist dafür nicht begründbar. Maßnahme: Vec2 rundet jeden Zwischenwert explizit auf float32 (conv.r4). Keine Regeländerung, R1 unverändert. .NET 8: 402/402, Golden 0, Trace byteidentisch zu vorher. Unity-Editor (Release und Debug): 402/402, Golden bitgleich in allen Bereichen, Float-Probe 4000/4000. - CoreIntegrationTests: keine Engine-Referenzen im Kern, Float-Arithmetik wie Godot. - docs/port/U1.5-UNITY.md: Versionen, Lizenz, Pakete, Tests, Golden je Bereich, Float-Befund, Editor-Benchmark, fehlende Build-Module. - docs/port/KNOWN-BEHAVIOR-DIFFERENCES.md mit "Legacy defects retained for parity" (R1) und F1. - Protokolle unter docs/port/logs/u1_5/. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.3 KiB
3.3 KiB
Port-Status · Champions of Luneraria in Unity
Stand: 30. September 2026.
Referenz ist der Godot-Stand luneraria/g3 (1b540f2) in ../saumwacht-godot; er wird nicht mehr verändert. Engine: Unity 6.3 LTS (6000.3.20f1), Renderer URP. HDRP ist ausgeschlossen, bis ein Vergleich mit einer echten Szene etwas anderes nahelegt.
Zielplattformen sind Fedora 44 und Windows 11; macOS ist die Entwicklungsplattform.
| Meilenstein | Zustand | Nachweis |
|---|---|---|
| U1 · C#-Simulation | fertig (Referenzmeilenstein, luneraria/u1 = 4d6ed17): 402/402 Prüfungen, Golden-Parität mit Godot |
U1-RULES.md |
| U1.5 · Unity-Integrationsprüfung | fertig: Kern im Unity-Editor 402/402 (Release und Debug), Golden bitgleich nach expliziter float32-Rundung in Vec2, Editor-Benchmark |
U1.5-UNITY.md |
| U2 · Unity-Spielwelt | nächster Schritt | U2-WORLD.md |
| U3 · G3-HUD portieren | nicht begonnen | U3-UI.md |
| U4 · Netzwerk | nicht begonnen; M4-Umfang ist erfasst | U4-NETWORK.md |
| U5 · Visuelle Neuausrichtung (Vertical Slice Mid-Lane) | nicht begonnen | U5-VISUAL.md |
QA je Meilenstein: PORT-QA.md.
Bekannte Verhaltensunterschiede, auch die bewusst übernommenen Referenzfehler: KNOWN-BEHAVIOR-DIFFERENCES.md.
Offene Voraussetzungen
- Build-Module für die Zielplattformen fehlen: Windows Build Support (Mono) und Linux Build Support (Mono), optional Linux IL2CPP und Linux Dedicated Server. Installation nur nach Freigabe (Details in U1.5-UNITY.md).
- Kerntests und Player auf Windows 11 und Fedora 44 stehen deshalb aus.
Entscheidungen
- Regelkern ohne Unity (
Luneraria.Core,noEngineReferences). Unity wird Adapter und Präsentation. - Verhaltensgleichheit statt Bitgleichheit. Verglichen wird mit dokumentierten Toleranzen; gemessen wurde auf dem Mac trotzdem Abweichung 0, in .NET 8 und im Unity-Editor.
- Explizite float32-Rundung in
Vec2(U1.5). Unitys Mono rechnet float32-Zwischenwerte doppelt genau. Das änderte in einem Szenario eine Zielentscheidung, deshalb ist eine Toleranz hier nicht begründbar. Die Casts erzwingen Godots float32-Semantik auf jeder Laufzeit; Regeln und .NET-Ergebnisse bleiben unverändert. - Tabellen einmal aus Godot erzeugt (
tools/port/gen_content.py); danach istContentData.csdie gepflegte Quelle. - Referenzfehler R1 im Bot-Gedächtnis ist bewusst übernommen (Parität) und für eine spätere Bot-Phase vorgemerkt.
- Geplante Helden (Lucy, Ghaliga, Siegfried, Feena) stehen im Datenmodell, sind aber inaktiv, bis eine Heldenphase ihre Regeln umsetzt.
- Assets: Blender-Quellen und Generatoren sind die Quelle. Ein zentraler, reproduzierbarer Blender-Export erzeugt FBX für Unity; GLB nur, wo keine bessere Quelle existiert (U2).
Arbeitsweise
- Ein Zweig je Meilenstein:
luneraria/u1,luneraria/u1.5,luneraria/u2, … Nach jedem Meilenstein kommen Tests, Bild, Leistung, bekannte Unterschiede und ein Commit. - Werkzeuge:
tools/run_core_tests.sh(Kern mit .NET).- Unity Test Runner (EditMode) und
CoreBatchim Batchmodus (Kern im Editor). tools/godot-golden/run_godot.sh(Godot-Referenz).tools/dotnet/Luneraria.Core.BenchundCoreBatch.Benchmark(Leistung).