weltenauge/prompts/main.txt

83 lines
4.3 KiB
Text
Raw Permalink Normal View History

2026-02-21 10:07:53 +01:00
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.