This commit is contained in:
2026-08-10 19:23:04 +02:00
commit 404d15a56c
134 changed files with 5374 additions and 0 deletions
+143
View File
@@ -0,0 +1,143 @@
# 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 `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: ...`