# Survival_projet — Unreal Engine 5.8

Jeu de survie solo à la première personne, gameplay écrit en **C++**, Blueprints réservés au
câblage d'assets. Inspirations assumées : Raft, Aloft, Valheim, esthétique solarpunk.
Assets d'environnement : pack **SoStylized** (sa végétation n'est pas à l'échelle humaine).

## Interlocuteur

L'auteur vient de **Unity** et découvre Unreal. Il écrit en français — **répondre en français**.

Faire systématiquement le parallèle Unity quand un concept nouveau apparaît
(Blueprint ≈ prefab, DataAsset ≈ ScriptableObject, ActorComponent ≈ MonoBehaviour,
BeginPlay ≈ Start, Trace Channel ≈ LayerMask). Il raisonne déjà très bien en composants,
inutile de réexpliquer les bases.

Signaler en revanche les endroits où le modèle **diverge réellement** de Unity, ce sont ceux
qui le piègent : framework GameMode/Controller/Pawn imposé, `UPROPERTY` obligatoire pour le GC,
constructeur qui tourne dans l'éditeur (CDO), pas de matrice de collision globale.

Il valide les décisions de design lui-même. Proposer **une recommandation argumentée**, pas un
catalogue d'options. Quand un choix change matériellement le code (modèle d'inventaire, règles
de mort), demander avant de coder plutôt que de deviner.

## Compiler

```powershell
& "C:\Program Files\Epic Games\UE_5.8\Engine\Build\BatchFiles\Build.bat" Survival_projetEditor Win64 Development -Project="d:\Projet\Perso\Unreal\Survival_projet\Survival_projet.uproject" -WaitMutex
```

- Un DLL nommé `UnrealEditor-Survival_projet-000N.dll` signifie que **l'éditeur était ouvert** :
  c'est un hot reload. Prévenir l'auteur de fermer et relancer l'éditeur.
- `-Rebuild` échoue tant que l'éditeur tourne (DLL verrouillés).
- **Ne jamais réécrire en masse les timestamps** des fichiers source pour forcer un build.
- L'outil Edit renvoie parfois `EPERM` sur `FpsPlayer.cpp` (watcher qui tient le handle) :
  réessayer, ou passer par Write sur le fichier entier.

## Règles d'architecture établies

**Un système = un `UActorComponent`.** Jamais de logique empilée dans `AFpsPlayer`, qui n'est
qu'un assemblage de composants plus la caméra et le déplacement.

**Où va quoi** — le critère est « si le pawn meurt, est-ce que ça doit survivre ? » :

| Nature | Emplacement |
|---|---|
| Le corps : déplacement, caméra, inventaire, stats, interaction | **Pawn** |
| Le joueur : widgets HUD, input d'interface (Tab, Q, hotbar) | **PlayerController** |
| Les règles de la partie, le respawn | **GameMode** |
| Ce que les autres savent de toi (plus tard, si multi) | **PlayerState** |

**Données vs état.** `UItemDataAsset` décrit ce qu'un objet **est** (nom, mesh, icône, effets).
Quantité, charges restantes, durabilité sont de l'**état** et vivent sur le slot ou l'acteur.
Mettre de l'état dans un DataAsset le partagerait entre toutes les instances du jeu.

**Un Blueprint par comportement, un DataAsset par objet.** 200 objets et 3 comportements
donnent 3 Blueprints et 200 DataAssets. `BP_Pickup` est générique, son `ItemData` change
par instance.

**Réglages exposés.** Toute valeur qui se règle à l'œil est une `UPROPERTY(EditAnywhere)`,
pour itérer en PIE sans recompiler.

**Pièges C++ Unreal rencontrés** : ne pas nommer un membre `Player`, `OldPawn`, `Slot` ou
`CrouchedEyeHeight` dans une classe dérivée du moteur (masquage → erreur C4458 / UHT).
`TWeakObjectPtr` ne permet pas de détecter une transition par simple comparaison de pointeurs,
il faut un booléen d'état à côté.

## Systèmes en place

| Système | Fichiers |
|---|---|
| Personnage, caméra, game feel | `FpsPlayer.h/.cpp` |
| HUD, input d'interface, fondus, respawn | `FpsPlayerController.h/.cpp` |
| Interaction (trace + interface) | `Interactable.h`, `InteractionComponent`, `InteractionPromptWidget` |
| Objets | `ItemDataAsset`, `PickupItem` |
| Inventaire | `InventoryComponent`, `InventoryWidget`, `InventorySlotWidget`, `HotbarWidget`, `InventoryDragDropOperation` |
| Survie | `SurvivalStatsComponent`, `SurvivalStatsWidget` |

### Décisions de gameplay figées

- **Inventaire** : un seul `TArray` de 30 slots. Index **0-9 = barre rapide**, **10-29 = grille**.
  Conteneurs **indépendants** (un objet dans la barre n'apparaît pas dans la grille), même
  tableau uniquement pour que le glisser-déposer n'ait aucune conversion d'index à faire.
- **Ramassage** : complète les piles existantes partout, puis ouvre un slot dans la **barre en
  priorité**, puis déborde dans la grille.
- **Glisser** : normal = pile entière, **Maj** = moitié arrondie au supérieur, **Ctrl** = un seul.
  Lâcher hors de la grille jette au sol ; lâcher entre deux cases est absorbé (jamais de perte
  accidentelle).
- **Clic gauche** = utiliser l'objet actif de la barre. Bindé sur le **pawn**, donc muet quand
  l'inventaire est ouvert — le conflit avec le drag & drop se règle tout seul.
- **Objets à charges** (`MaxUses > 1`) ne s'empilent jamais. Les valeurs de restauration
  s'appliquent **par utilisation**. L'usure suit l'objet jusqu'au sol et revient avec lui.
- **Mort** : tout tombe au sol autour du corps, respawn au `PlayerStart`, jauges pleines.
- **Fondus** : un unique voile plein écran `WBP_Fade` au ZOrder 1000. Fondre widget par widget
  est fragile — les cases réécrivent leur propre `RenderOpacity`.
- Après un respawn, le pawn est un **nouvel acteur** : les widgets doivent se rebrancher via
  `BindToOwningPawn()`, appelé depuis `OnPossess`.

## Conventions

- Commentaires **en français**. Ils expliquent le *pourquoi* et les pièges, jamais le *quoi*.
- Nommage éditeur : `BP_` acteurs, `WBP_` widgets, `DA_` data assets, `IA_` input actions,
  `IMC_` mapping contexts, `GM_` game mode.
- Widgets : classe C++ `Abstract` pour la logique, Widget Blueprint enfant pour la mise en page.
  Les widgets liés utilisent `meta = (BindWidget)`, ou `BindWidgetOptional` quand l'élément
  est décoratif.
- Les widgets s'abonnent à des délégués, **jamais de Tick** pour lire un état.

## État actuel et suite

Boucle complète : récolter → ranger → consommer → survivre → mourir → réapparaître.

Prochaine étape recommandée : **spawner de ressources avec repousse** (`AResourceSpawner`,
liste pondérée de DataAssets, rayon, densité, délai). Sans lui la carte se vide en dix minutes.

Ensuite, par ordre de valeur : craft, objet visible en main, coffres, sauvegarde,
cycle jour/nuit.