Für mein NWN/Godot Projekt brauche ich eine Referenzimplementierung für die Client/Server Logik. Client und Server sind in der gleichen Codebase/Projekt. Normal aufgerufen, kann der Anwender Join und Host auswählen. Stellt das Programm fest, dass es headless läuft, wird automatisch als Host gestartet. Die Szenen(Areas) in denen die Spieler laden, werden nach bedarf geladen. Wenn Spieler A in Area 1 ist, hat sein Client nur Area 1 geladen. Wenn Spieler B in Area 2 ist, hat sein Client nur Area 2 geladen. Nur Host hat beide Areas geladen, und synchronisiert seine Area 1 mit Area 1 des Clients von Spieler A und seine Area 2 mit der Area 2 des Clients von Spieler B. Ein Übergang zu einer anderen Area kann vom Host veranlasst werden . Er lädt die neue Area(Szene) und erzeugt den Avatar des Spielers. Der Client des betroffenen Spielers muss die neue Area(Szene) auf seiner Seite ebenfalls laden, damit die Szenenobjekte synchronisiert werden können. Sorge dafür, dass die Areas auf dem Server sich nicht überlagern. Jeder MultiPlayerSynchronizer sollte nur position der Spieler synchronisieren, aber nicht global_position. Jede Area soll auf dem Server einen eigenen SubViewport haben. (Godot Multi-World Physics) Sorge mit Visibility Filtering dafür, dass die MultiplayerSynchronizer nur die Objekte in ihrer jeweiligen Area synchronisieren. Aus Performancegründen soll die Click-to-Move Funktionalität über AStar implementiert werden. Das Spielermodell liegt unter res://systems/player/player.tres Area 1 liegt unter res://maps/outdoor/grass/keuwin_grasland.tscn Area 2 liegt unter res://maps/planes/fugue/halle_der_ahnen.tscn Alle Scripte müssen in einem thematisch passenden Subfolder unterhalb res://systems/ abgelegt werden. Dies ist die Struktur des Projektes: /assets/ # REINE ROHDATEN (Dumm, keine Spiellogik) /characters/ /humanoid/ /base_meshes/ # .glb Dateien und .tres (Mesh-Resources) /materials/ # .tres (Material-Resources) /environment/ /dungeon/ # Tileset-Modelle /nature/ # Bäume, Steine /items/ /armor/ /weapons/ /consumables/ /systems/ # DAS GEHIRN (Logik, muss auf dem Server laufen) /core/ # Game-Loop, Signale, State-Machine /network/ # Multiplayer, Peer-Handling, Headless-Logik /player/ # Player-Controller (ohne Kamera/UI) /ai/ # NPC-Verhalten, Monster-Logik /combat/ # Regelwerk, Würfelwürfe, Stats /dialogue/ # Gesprächs-Logik, Quests /inventory/ # Item-Management, Container /interaction/ # Türen, Hebel, Portale /navigation/ # AStar-Management, Pathfinder /simulation/ # Tag-Nacht-Zyklus, Fraktionen /data/ # Speicher-Logik, DB-Anbindung /fx/ # Wetter-Logik, Sound-Trigger /ui/ # DAS GESICHT (Nur für den Client) /hud/ # Permanente Anzeigen (HP, Chat) /menus/ # Startmenü, Optionen /windows/ # Inventar-Fenster, Charakterbogen /components/ # Buttons, Slots, wiederverwendbare Teile /themes/ # Schriften, Styles, Visual Design /maps/ # DIE WELT (Szenen, in denen man spielt) /templates/ # Basis-Setups für neue Karten /outdoor/ # Wald, Wüste, Gebirge /indoor/ # Häuser, Burgen /dungeons/ # Krypten, Höhlen /planes/ # Andere Existenzebenen /audio/ # KLANGWELT /music/ # Hintergrundmusik (.ogg) /sfx/ # Geräusche (Schwert, Schritte) /ambience/ # Atmosphäre-Loops (Wind, Feuer) /data/ # DIE DEFINITIONEN (Inhaltliche Datenkarten) /items/ # .tres Dateien für jedes Schwert/Schild /tables/ # SQLite .db oder JSON-Tabellen /licencing/ # Rechtliches (Asset-Lizenzen) Erstelle bitte eine Referenzimplementierung, die folgende Funktionen abdeckt: Host Game, Join Game, Scenenwechsel, Server-Authority Erzeuge so wenige Dateien wie möglich.