Spiele

XR-Spielentwicklung in Godot meistern: Lektionen aus „Assemble!"

Was die Godot-Produktion eines XR-Spiels ausmacht — von Physik über Performance bis zur Horizon-Store-Review. Mit den APIs und dem Stand von Godot 4.6.

Ingmar Konnow

• 5 Min. Lesezeit
Teilen
XR-Spielentwicklung in Godot meistern: Lektionen aus „Assemble!"

Als CTO von weltfern habe ich die Entwicklung von Assemble! geleitet — einem XR-Puzzlespiel, gebaut mit Godot 4 und inzwischen im Meta Horizon Store. Dieser Beitrag sammelt die Lektionen daraus: Warum Godot, wie die Performance auf Quest-Hardware gelingt und was die Store-Einreichung wirklich kostet. Die technischen Angaben sind auf den Stand von Godot 4.6 gezogen — die ursprüngliche Fassung enthielt einige API-Fehler, die jetzt korrigiert sind.

Von Unity zu Godot: Warum der Wechsel?

Unity wäre der einfachere Weg gewesen — aber das Closed-Source-Modell und der Exodus der Community nach der Runtime-Fee-Debatte unter John Riccitiello haben Godot zur klaren Wahl gemacht. Nach der intensiven Assemble!-Produktion stehe ich zu dem Urteil: Godot eignet sich für professionelle XR-Entwicklung. Was uns überzeugt hat:

  • Jolt Physics-Integration für realistische Interaktionen — mittlerweile auch im Web-Export
  • Dynamisches GLTF-Lade-System mit adaptiver Schwierigkeit
  • Eigene XR-Interaktionssysteme auf Basis von Godot XR Tools (Open Source)

Persönliche Erfahrung: Mehr als ein technischer Guide

Vor den Details eine ehrliche Notiz: Assemble! hat mich mehrfach aus der Komfortzone geholt — von Godots XR-Paradigmen bis zu Performance-Engpässen, die sich erst auf dem Gerät zeigten. Diese Hürden waren keine bloßen Bugfixlisten, sondern der eigentliche Lernzuwachs des Projekts.

Godot XR: Die Evolution seit 2024

Der Godot-Editor im Horizon Store

Seit Dezember 2024 gibt es den Godot-Editor nativ im Horizon Store — XR-Workflows komplett auf dem Headset:

  • Spiel direkt in XR auf dem Quest-Headset laufen lassen (Quest 3 aufwärts — auf der Quest 2 läuft der Editor technisch nicht)
  • Shader und Shading auf dem echten Gerät testen
  • Performance-Validierung ohne PC-Umweg

Bei Assemble! kam die Store-Version zu spät — wir begannen vor ihrer Veröffentlichung und arbeiteten bis zuletzt auf der Quest 2. Heute würde ich sofort auf dem Headset iterieren.

XR Tools und Komfort-Standards

Das XR-Tools-Framework setzt die Best Practices aus dem XR Design Handbook um — Teleport-Locomotion, Snap-Turns, Bewegungs-Vignette, statische Referenzpunkte. Die Komfort-Optionen werden in XR Tools über Nodes im Player-Rig konfiguriert (Movement-Turn mit Snap-Modus, Vignette-Stärke u. a.), nicht über eine einzelne API.

Die Initialisierung sieht im Kern so aus (Pattern aus dem offiziellen „Better XR Start Script"):

var xr_interface := XRServer.find_interface("OpenXR") as OpenXRInterface
if xr_interface and xr_interface.is_initialized():
    DisplayServer.window_set_vsync_mode(DisplayServer.VSYNC_DISABLED)
    get_viewport().use_xr = true
    # Ziel-Refreshrate auf dem Headset setzen (Quest: 72/80/90 Hz)
    if 90.0 in xr_interface.get_available_display_refresh_rates():
        xr_interface.display_refresh_rate = 90.0

Performance: Lektionen aus dem Trench

Asset-Disziplin

  • Polygone unter ~100k pro Szene halten
  • Texturen maximal 2048×2048
  • Glow/Postprocessing in VR deaktivieren — das frisst das Budget auf Mobile-Hardware

Monitoring — mit den richtigen Monitoren

Ein Hinweis zur Ehrlichkeit: Die ursprüngliche Fassung dieses Posts nannte Performance.TIME_FPS als „GPU-Zeit" — falsch, der Monitor liefert die Bildrate, nicht Millisekunden. Eine echte GPU-Zeit liefert Godot nicht als Monitor; auf dem Quest misst man sie mit dem OVR-Metrics-Overlay (siehe unten). Was in Godot 4 korrekt funktioniert:

func _process(_delta):
    var fps := Performance.get_monitor(Performance.TIME_FPS)
    var cpu_ms := Performance.get_monitor(Performance.TIME_PROCESS) * 1000.0
    var draws := Performance.get_monitor(Performance.RENDER_TOTAL_DRAW_CALLS_IN_FRAME)
    var tris := Performance.get_monitor(Performance.RENDER_TOTAL_PRIMITIVES_IN_FRAME)
    if cpu_ms > 11.0 or fps < 72.0:
        $OptimizationAlert.trigger()
MetrikGodot-4-MonitorRichtwert Quest
BildratePerformance.TIME_FPS≥ 72/90 FPS
CPU-FramezeitPerformance.TIME_PROCESS< 11 ms
Draw CallsPerformance.RENDER_TOTAL_DRAW_CALLS_IN_FRAME< 150
DreieckePerformance.RENDER_TOTAL_PRIMITIVES_IN_FRAME< 100k
Statischer SpeicherPerformance.MEMORY_STATICso niedrig wie möglich

Performance lässt sich nicht am Code ablesen — sie muss auf dem Gerät beobachtet werden. Bei Assemble! waren es am Ende die Tag/Nacht-Zyklus-Shader und die schiere Teilezahl, die massiv ins Budget fraßen; die Jolt-Physik spielte mit hinein. Gekämpft haben wir letztlich um Polygonzahl und Shader.

Die Meta-Horizon-Standards erfüllen

Eine Korrektur aus der ersten Fassung: Das OVR Metrics Tool ist kein Unity-Exklusivwerkzeug — es ist ein Overlay-APK, das systemweit auf der Quest läuft und damit auch Godot-Builds misst (FPS, CPU-/GPU-Last, Thermik). Für das Store-Review also direkt nutzbar, keine Godot-Umwege nötig.

Auf Basis von Metas VRC-Requirements hat sich diese Checkliste bewährt:

  • Framerate stabil auf der Zielrate halten (72/90 Hz via display_refresh_rate)
  • Speicherbedarf im Blick — via Performance.MEMORY_STATIC (nicht mehr über die Godot-3-API OS.get_static_memory_usage()); Achtung: liefert nur in Debug-Builds Werte, im Release-Export hilft OVR Metrics
  • Thermik und Frametimes über längere Sessions prüfen, nicht nur im ersten Level
  • Früh auf Referenz-Hardware testen — heute ist das die Quest 3S, nicht mehr die eingestellte Quest 2
Entscheidungsfluss für die Store-Einreichung: erst Performance stabilisieren, dann VRC-Checkliste

B{Framerate stabil
72/90 Hz?}

B -->|Nein| C[Assets &<br/>Shader optimieren]
C --> B
B -->|Ja| D{Speicher &<br/>Thermik ok?}
D -->|Nein| E[Texturen &<br/>Objekte reduzieren]
E --> B
D -->|Ja| F[VRC-Checkliste<br/>durchgehen]
F --> G[Submit]

-->

Die Store-Realität: MVP zuerst

Während Assemble! in Arbeit war, hat Meta den App Lab in den Horizon Store überführt — alle bisherigen Titel landeten vermeintlich direkt im Shop. Falsch gedacht: Die Richtlinien wurden massiv verschärft, und der schnelle Weg in den Store war Geschichte.

Meine Empfehlung: die erste, einfachste Version (MVP) einreichen und mit einer ausgewählten Testgruppe prüfen. Der Aufwand für Dokumente, rechtliche Nachweise und schlicht das Verstehen des Review-Feedbacks wird unterschätzt. Am Ende habe ich wörtlich nachgefragt, WAS GENAU mit dem Feedback gemeint ist — als eigene Notiz im Ticket. Das hat die wilde Interpretationsarbeit drastisch reduziert.

Stand September 2026

Die Werkzeugkette hat sich seit Erscheinen deutlich weiterentwickelt:

  • Godot 4.6 (stable seit Januar 2026, aktuell 4.6.3) ist in die Polish-Phase eingetreten: Performance-Optimierung, engere Standard-Integration, weniger Bruchkanten.
  • XR Tools 4.5.1 (Dezember 2025) — aktuelles Release, setzt Godot 4.4+ voraus; u. a. verbesserte Pickables, Grab-Points und Viewport2Din3D-Performance.
  • OpenXR Vendors Plugin 5.x — die Versionsschiene für Godot 4.6; das im Originaltext genannte 3.1.2 ist überholt.
  • Godot Meta Toolkit: GDExtension mit Platform-SDK-Anbindung (IAP, Achievements, Leaderboards), Meta XR Simulator zum Testen ohne Headset und automatischer Export-Konfiguration für Quest.
  • Hardware-Basis: Quest 3S als Referenz für die Entwicklung; die Quest 2 ist aus dem Verkauf (Sicherheitsupdates bis Dezember 2027).

Pro-Tipps für XR-Entwicklung mit Godot

  1. Mit dem offiziellen XR-Setup-Guide starten
  2. Das dokumentierte Better XR Start Script als Basis übernehmen
  3. Früh und oft profilen — auf dem Gerät, nicht im Editor
  4. Die Godot-Community nutzen — sie ist in jeder Projektphase hilfreich

Fazit

Mit Metas offizieller Unterstützung und dem Editor im Headset ist Godot für XR keine Nischenwahl mehr. Assemble! hat gezeigt: Die Kombination aus Jolt-Physik, XR Tools und disziplinierter Performance-Arbeit trägt ein kommerzielles Quest-Spiel bis in den Store. Wer dieselbe Strecke plant, findet die Spielseite des Projekts im Assemble!-Beitrag — und die größten Zeitfresser lauern weiterhin in Shadern, Polygonzahl und Store-Bürokratie.

Update September 2026: Dieser Artikel wurde überarbeitet — auf Godot 4.6/XR Tools 4.5.1/Vendors 5.x aktualisiert, API-Fehler korrigiert (Godot-4-Monitor-Namen, display_refresh_rate statt iterations_per_second, MEMORY_STATIC statt OS.get_static_memory_usage()), OVR-Metrics-Einordnung richtiggestellt und das Mermaid-Flowchart als Bild umgesetzt.

Quellen

Wer ein Godot-XR-Projekt Richtung Quest-Store bringen will oder bei der Performance-Optimierung festhängt: Nachricht an ingmar@konnow.de oder über LinkedIn — ich habe diese Strecke komplett durchgespielt.

0%
5 Min. Lesezeit