Files
2026-08-10 19:23:04 +02:00

5.4 KiB
Raw Permalink Blame History

CLAUDE.md — AfterHours (Boutique Simulator)

Diese Datei ist die Arbeitsanweisung für Claude Code in diesem Repo. Lies sie vollständig, bevor du Code änderst.


1. Projekt in einem Satz

Koop-Ladensimulator (24 Spieler) für PC: Die Spieler betreiben gemeinsam eine diskrete Erwachsenen-Boutique — Ware bestellen, einräumen, bepreisen, Kunden beraten, kassieren, Laden ausbauen.

Codename: AfterHours Zielplattform: Windows (Steam), später Linux/Proton Zielrating: Mature, NICHT Adult-Only. Siehe §7 — das ist eine harte Constraint.


2. Tech-Stack

Bereich Entscheidung
Engine Unity 6 LTS (6000.0.x)
Sprache C# (.NET Standard 2.1)
Netcode Unity Netcode for GameObjects (NGO) 2.x
Transport Unity Transport + Steam Relay (Facepunch)
KI-Pathing Unity NavMesh (NavMeshAgent, nur serverseitig)
Tests Unity Test Framework (NUnit), EditMode
Daten ScriptableObjects (Assets/Data/...)

Warum NGO und nicht FishNet: erstklassige Doku, First-Party-Support, reicht für 4 Spieler + ~30 NPCs vollkommen aus. Nicht ohne Rücksprache wechseln.


3. Die wichtigste Regel: Server-Authority

Der Host simuliert. Clients fragen und zeigen an.

Alles, was Geld, Inventar, Warenbestand oder Kundenlogik betrifft, läuft ausschließlich auf dem Host. Clients senden Absichten via ServerRpc, der Server validiert und schreibt in NetworkVariables.

Konkret:

  • [Rpc(SendTo.Server)] → validieren → NetworkVariable setzen
  • Niemals Geld/Bestand clientseitig verändern und "hoffen"
  • Niemals einem Client-Wert vertrauen, ohne ihn zu prüfen (Beispiel: Client sagt "ich scanne Produkt X" → Server prüft, ob der Client dieses Produkt tatsächlich in der Hand hält)
  • Kunden-NPCs: Bewegung + Entscheidungen nur auf dem Server. Clients bekommen nur Transform-Sync und Zustandsflags.

Jede Methode, die Zustand ändert, wird mit if (!IsServer) return; abgesichert — auch wenn sie "eigentlich" nur serverseitig aufgerufen wird.


4. Ordnerstruktur

Assets/Scripts/
├── Core/           GameClock, ShopEconomy, GameBootstrap — Kern-Loop & Zustand
├── Data/           ScriptableObjects: ProductDefinition, ProductCatalog, Enums
├── Economy/        PricingService, SupplierService, PurchaseOrder
├── Shop/           Shelf, ShelfSlot, CashRegister, StorageCrate
├── Customers/      CustomerAgent, CustomerBrain (FSM), ComfortModel, Spawner
├── Interaction/    IInteractable, PlayerInteractor, Carryable
├── Networking/     NetworkBootstrap, PlayerAvatar, PlayerHands
└── Tests/EditMode/ NUnit-Tests für reine Logik

Namespaces spiegeln Ordner: AfterHours.Economy, AfterHours.Customers, …


5. Code-Konventionen

  • Klassen/Methoden PascalCase, Felder _camelCase mit Unterstrich, Konstanten PascalCase.
  • [SerializeField] private statt public für Inspector-Felder.
  • Reine Logik gehört in statische, engine-freie Klassen (PricingService, ComfortModel). Nur die sind testbar — MonoBehaviours sind es nicht. Wenn du eine Formel schreibst und sie in einem MonoBehaviour landet: rausziehen.
  • Produkte werden im Netzwerk nie als Referenz, sondern als ProductId (int) übertragen. Auflösung über ProductCatalog.
  • Keine FindObjectOfType im Frame-Loop. Referenzen im Awake cachen.
  • Kein async void außer in Event-Handlern.

6. Tests

# Unity CLI (Pfad ggf. anpassen)
Unity -runTests -batchmode -projectPath . -testPlatform EditMode

Neue Logik in Economy/ oder Customers/ braucht einen EditMode-Test. Netzwerk- und Szenenlogik wird nicht getestet — dort zählt manuelles Host+Client-Testing (siehe docs/ARCHITECTURE.md).


7. Content-Constraint (nicht verhandelbar)

Das Spiel darf nicht in Steams "Adult Only"-Kategorie landen, weil das Sichtbarkeit, Regionen und Zahlungsdienstleister massiv einschränkt.

Deshalb gilt:

  • Produkte werden als stilisierte Verpackungen / Icons dargestellt, nie explizit modelliert.
  • Kein sexuell explizites Bildmaterial, keine Nacktheit, keine sexuellen Akte.
  • Humor ist trocken und situativ (Verlegenheit, Beratungspannen, Stoßzeiten-Chaos) — nicht anzüglich.
  • Ton der Kundendialoge: höflich, vage, alltäglich. Die Komik entsteht aus dem, was nicht gesagt wird.

Wenn ein Feature-Vorschlag dagegen verstößt: melde es, statt es umzusetzen.


8. Aktueller Stand

Gerüst steht. Implementiert sind Datenmodell, Preis-/Komfort-Formeln, Regal-/Kassen-Grundgerüst und der Netzwerk-Bootstrap. Es existieren noch keine Unity-Szenen, Prefabs oder Assets — die musst du bzw. der Nutzer im Editor anlegen.

Offene Punkte in Prioritätsreihenfolge: siehe docs/ROADMAP.md. // TODO:-Marker im Code zeigen die konkreten Lücken.


9. Arbeitsweise mit mir

  • Bevor du eine neue Datei anlegst: prüfe, ob die Logik in eine bestehende gehört. Das Projekt soll klein und lesbar bleiben.
  • Ändere nie mehrere Systeme in einem Rutsch. Ein System, ein Commit.
  • Wenn eine Anforderung mit §3 (Server-Authority) oder §7 (Content) kollidiert: nachfragen, nicht raten.
  • Commit-Messages: feat(economy): ..., fix(customers): ..., docs: ...