5.5 KiB
CAM-B2d : maniement du personnage à la troisième personne (analyse et proposition, 2026-10-13)
Demande de l'utilisateur (directe) : « le personnage est difficile à manier, renseigne-toi comment gérer un personnage à la troisième personne ». Lecture seule ; aucune écriture d'asset.
1. Référence : le modèle Third Person d'Epic (UE 5.8 installé)
Source : D:\Game\Launcher\Engine\UE_5.8\Templates\TP_ThirdPerson\Source\TP_ThirdPerson\TP_ThirdPersonCharacter.cpp.
Le modèle s'organise autour d'une seule référence partagée, la rotation de contrôle (ControlRotation du
contrôleur) :
| Rôle | Réglage du modèle | Ligne |
|---|---|---|
| La souris ou le stick fait tourner la rotation de contrôle | AddControllerYawInput(Yaw), AddControllerPitchInput(Pitch) |
113-120 |
| La caméra se place derrière la rotation de contrôle, et non derrière le personnage | CameraBoom->bUsePawnControlRotation = true, TargetArmLength = 400 |
39-42 |
| Le déplacement se fait par rapport au lacet de contrôle : avant = « vers où regarde la caméra » | ForwardDirection / RightDirection tirés de GetControlRotation().Yaw |
93-110 |
| Le personnage se tourne vers sa direction de marche, sans suivre la caméra | bUseControllerRotationYaw = false, bOrientRotationToMovement = true, RotationRate = (0, 500, 0) |
21-27 |
| Démarrage et arrêt | MaxWalkSpeed 500, BrakingDecelerationWalking 2000, MinAnalogWalkSpeed 20 |
33-35 |
| Collision de la caméra | le SpringArm recule la caméra devant un obstacle (sonde de collision) |
39-42 (composant) |
Conséquence : avancer éloigne toujours de la caméra et gauche/droite restent gauche/droite à l'écran. Le personnage tourne sous la caméra, mais la caméra ne tourne que si le joueur la tourne.
2. LifePlay aujourd'hui (B2b)
| Rôle | LifePlay | Preuve |
|---|---|---|
| Déplacement ZQSD | par rapport au lacet de contrôle du PC (comme le modèle) | Source/LifePlay/LPDirectControlSubsystem.cpp:885-892 |
| Orientation du personnage | bOrientRotationToMovement = true, bUseControllerRotationYaw = false (comme le modèle) ; RotationRate non réglé (valeur du Blueprint Person, non lue) |
LPDirectControlSubsystem.cpp:864-868 |
| Rotation de contrôle | jamais écrite : 0 écriture dans PC, GI, Room (dumps) ni dans le C++ (seulement 3 lectures, :887, :913, :929). Elle reste fixe, donc Z va toujours dans la même direction du monde |
grep ControlRotation|AddYawInput|SetControlRotation : PC 0, GI 0, Room 0 ; Source : 3 lectures |
| Caméra C2 | placée derrière l'avant du personnage (GetActorForwardVector, + C2Yaw) ; la souris et les flèches font varier C2Yaw |
CAM-SPEC.md B2-3, B2b-5, B2b-6 |
Cause du maniement difficile (établie par le code ; le ressenti reste à confirmer) : la caméra et les commandes n'ont pas la même référence. Exemple : le joueur appuie sur D. Le personnage part vers la droite du monde et se tourne dans ce sens, la caméra C2 pivote derrière lui, et Z désigne alors la gauche de l'écran. À chaque virage, l'image tourne alors que les commandes restent fixes dans le monde.
3. Proposition B2d : aligner C2 sur le modèle d'Epic (Room seul, sans C++)
- C2 derrière le lacet de contrôle : dans
ComputeC2Target, la direction arrière vient deGetControlRotation(GI.PC).Yawau lieu deGetActorForwardVector(MC)(remplace 453 → 454 → PO17 → 497).C2Yawdevient inutile : il est retiré, ou laissé à 0. - La souris et les flèches font tourner la rotation de contrôle : dans
CircleCameraetLeftRight(branches C2 de F6a), on remplaceC2Yaw += …parGI.PC.SetControlRotation(lacet + …). Le déplacement ZQSD suit alors la caméra, sans changement du C++ (il lit déjà ce lacet). - Départ derrière le personnage : dans
PlaceC2(entrée en C2), on fait d'abordSetControlRotation(0, lacet du personnage, 0), pour que la caméra parte derrière lui comme aujourd'hui. - Inchangés : hauteur (
C2Height), distance (C2Dist), confinement dans la pièce, repli, lissage et balayages de B2b. - En option, à décider : un recentrage automatique derrière le personnage après N s sans toucher la caméra (comportement de nombreux jeux, absent du modèle d'Epic).
Effets attendus : Z éloigne toujours de la caméra ; Q et D vont à gauche et à droite de l'écran ; le personnage se tourne vers sa marche sans faire tourner la caméra ; la caméra ne tourne qu'à la souris ou aux flèches.
4. Coût, risques, partage avec STG
- Room seul, ≈ 12 nœuds (2
GetControlRotation, 3SetControlRotation, opérations de lacet, suppression de 3 nœuds de la chaîne 453 → 497). ≈ 25 min de MCP parlp-mcp-bp(1 fiche), V5 et V6 ≈ 5 min, puis build et essai. - Risque faible : la rotation de contrôle n'a aujourd'hui aucun autre lecteur que la marche (
:887) et laFollowCameramorte (:913, :929, retrait prévu en B6). Birdview et les menus ne la lisent pas (0 occurrence dans les dumps PC et GI). - Partage avec STG : la marche (
LPDirectControlSubsystem::Walk) appartient au chantier de STG (perte du déplacement, B-SOL). B2d ne la modifie pas, mais change ce qu'elle lit. À coordonner par Big Boss. Le réglage éventuel deRotationRateou des vitesses (modèle : 500°/s, 500 cm/s, freinage 2000) relève de STG ; leurs valeurs actuelles chez Person ne sont pas lues ici. - Barème : a1 b2 c1 d1 e1 f1 = 7 → N3 ; S = C3 1 (procédure
lp-mcp, fiches B2b) + f 1 = 2 < 3 : une fiche.