Skip to content

Architekturübersicht

Systemübersicht

flowchart LR
  C["Game3D Client"] -->|Auth, Chat, RPC, Storage| N["Nakama"]
  C -->|Discovery HTTP| R["Registry"]
  C -->|ENet UDP| H["Headless Hub Server"]
  H -->|Register/Heartbeat HTTP| R
  D["Dashboard"] -->|HTTP/WebSocket polling| R
  R --> RD["Redis"]
  N --> PG["PostgreSQL"]
  A["Launcher API"] --> FS["Release Files/Manifest"]

Nakama ist nicht der Echtzeit-Gameplay-Transport: Auth/Chat/Run-/Replay-RPCs laufen über Nakama, Hub-Bewegung und serverautoritative Dungeon-Waffen-Sessions über Godot ENet. Der Headless-Prozess lädt dasselbe Game3D-Projekt mit --server-mode.

Client- und Serverstart

Godot instanziiert beide Bootstrap-Autoloads. AppBootstrap baut den Serviceprovider, injiziert globale Nodes und navigiert beim Client zum Main Menu. ServerBootstrap baut denselben Provider, erkennt ServerMode, lädt HubServerScene, öffnet ENet und startet HubRegistryService. Normale Scenes erhalten Services über SceneLoader → SceneInjector → IServiceConsumer/InjectedNode.

Run-Ablauf

flowchart LR
  H["Social Hub"] --> S["Terminal / Seed selection"]
  S --> C["DungeonRunConfig"]
  C --> RD["RunDefinition + canonical DungeonDefinition"]
  RD --> G["V3 generation"]
  G --> T["Template selection/instantiation"]
  T --> P["Player spawn + start gate"]
  P --> E["Room encounters"]
  E --> O["Boss + enemy quota objectives"]
  O --> X["Exit unlock"]
  X --> B["chunked replay + rpc_submit_run"]
  B --> SC["Run result overlay"]
  SC --> H
  B --> L["Manual leaderboard"]

DungeonTerminal erzeugt über SeedService einen DungeonRunConfig und legt ihn in DungeonRunContextStore. GameFlowService lädt DungeonRun3DScene. DungeonRun3DController.GenerateWorld wählt den Generator, instanziiert Templates, Türen, Player, Tracker und Exit. DungeonRunService bildet Start/Notify/Abort auf Nakama-RPCs ab; Completion läuft über Replay-Upload und rpc_submit_run.

Waffen-Ablauf

flowchart LR
  PP["PlayerProgressionProfile / Snapshot"] --> PL["PlayerLoadout"]
  PL --> LV["LoadoutValidator"]
  PP --> LV
  RR["RunRules"] --> LV
  LV --> VL["ValidatedRunLoadout + LoadoutHash"]
  VL --> RD["RunDefinition.PlayerLoadoutsByPlayerId"]
  RD --> WF["WeaponFactory"]
  WF --> WR["WeaponInstance/RuntimeState"]
  WR --> AC["AdvancedWeaponController"]
  AC --> A["IRunAuthority"]
  A -->|online| NS["DungeonCombatNetworkSync"]
  A --> R["Replay/replication contracts"]

Shared-Domain, technische Waffen-Scenes und Tests existieren. Der aktive Player verwendet AdvancedWeaponController mit validiertem Run-Loadout; Godot-Input wird als Command ueber IRunAuthority verarbeitet. Finale Assets und Backend-Persistenz bleiben Ausbaupunkte.

Dungeon-Raum-Ablauf

flowchart LR
  S["RoomTemplate3D scene"] --> M["RoomTemplateMetadata + markers/sockets"]
  M --> C["RoomTemplateCatalogV3.tres"]
  RD["Canonical DungeonDefinition"] --> Q["RoomTemplateRequestFactory"]
  C --> SEL["RoomTemplateSelector"]
  Q --> SEL
  SEL --> I["RoomTemplateInstantiator"]
  I --> DS["Open/Sealed socket resolution"]
  I --> RC["RoomRuntimeContext"]
  RC --> SP["Player/enemy/boss/interaction markers"]
  SP --> E["RoomEncounterRuntime3D"]

Template-Auswahl filtert Kategorie, Größe, Rolle, exakte logische Bounds, Depth, positive Gewichtung und Door-Kompatibilität über 0/90/180/270 Grad. Der Room-Seed wird aus Dungeon-Seed, Room-ID, Index und Zweck abgeleitet. Runtime-Verbindungstüren werden einmal pro kanonischer Door erzeugt; Template-Sockets öffnen nur Wand-Plug/Collision/NavigationBlocker.

Autorität und Persistenz

  • Client darf lokale Eingaben, UI, Kamera und Darstellung bestimmen.
  • Headless Server validiert Hub-Bewegung/Walkability sowie Dungeon-Weapon-Intents und verteilt Snapshots.
  • Nakama authentifiziert Benutzer und besitzt server-only schreibbare Run-/Replay-Storageobjekte.
  • Nakama validiert Session/Ticket, Replay-Integrität und Timeline, berechnet Score/Medaille und entscheidet über Leaderboard-Eligibility. Eine vollständige deterministische Re-Simulation des gesamten Runs ist noch nicht implementiert.
  • PlayerProgression und gespeicherte Loadouts haben Contracts, aber keine Nakama-RPC-Implementierung.
  • Leaderboard-UI ruft LeaderboardQueryService als Application Use Case auf; ILeaderboardClient ist der Transport-Port und NakamaLeaderboardRpcClient dessen Infrastrukturadapter.

Weiter: Game3D, Dungeon-Runs, Multiplayer, Backend.