144 lines
5.4 KiB
Markdown
144 lines
5.4 KiB
Markdown
# 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 (2–4 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 `NetworkVariable`s.
|
||
|
||
**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
|
||
|
||
```bash
|
||
# 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: ...`
|