« Caméra » : différence entre les versions
| Ligne 54 : | Ligne 54 : | ||
Si le jeu est en « 2.5D » pour les niveaux, certaines zones offriront des déplacements plus libres. La [[caméra]] passera alors à une vue 3D isométrique et prendra de la hauteur tandis que le joueur avance afin d’ouvrir la zone de jeu. Il sera ainsi possible d’explorer les maisons et de se promener sans la contrainte comme dans un jeu en 3D. | Si le jeu est en « 2.5D » pour les niveaux, certaines zones offriront des déplacements plus libres. La [[caméra]] passera alors à une vue 3D isométrique et prendra de la hauteur tandis que le joueur avance afin d’ouvrir la zone de jeu. Il sera ainsi possible d’explorer les maisons et de se promener sans la contrainte comme dans un jeu en 3D. | ||
== Le système de RIG == | |||
Le '''système''' (Rig, Manager, variables) est déjà générique et réutilisable tel quel — mais les '''instances''' de Rig, elles, ne peuvent pas être partagées entre hubs différents, puisque chaque hub a sa propre géométrie et ses propres zones à cadrer. | |||
=== Pourquoi les instances de Rig ne sont pas interchangeables === | |||
Un <code>BP_HubCameraRig</code> est une '''classe''' générique (le comportement : suivi, clamp, zoom), mais chaque '''instance''' placée dans un niveau a des réglages spécifiques à cette zone (<code>TrackedBoundsMin</code>/<code>Max</code>, position, angle du SpringArm, etc.). Donc pour le Village des Dragons, on a <code>HubCameraRig_VillageDragons_</code><code>Main</code>, <code>HubCameraRig_VillageDragons_</code><code>Mella</code> (chez Mella) — et pour un futur second hub (disons un village de poules), il y aura besoin d''''autres instances''', placées et réglées spécifiquement pour cette nouvelle géométrie. | |||
C'est exactement pareil que pour <code>BP_Player_Hub</code>, <code>BP_Theia</code>, etc. — la classe est unique et réutilisée, mais chaque niveau/hub a ses propres instances placées avec des réglages adaptés. | |||
=== Ce qui EST réutilisable sans rien changer === | |||
* La '''classe''' <code>BP_HubCameraRig</code> elle-même (tout son comportement Tick/ActivateRig/DeactivateRig). | |||
* La '''classe''' <code>BP_ZoneTransitionTrigger</code> (le mécanisme de switch entre deux Rigs). | |||
* La fonction '''<code>SwitchHubZone</code>''' sur le Manager (générique, elle prend n'importe quels Rig en paramètre). | |||
* Le principe '''<code>MainHubRig</code>''' — mais attention, il faudra qu'il soit réinitialisé pour le hub actuellement chargé, pas partagé entre tous les hubs simultanément. | |||
Attention : le systèm est pensé pour ne pas avoir deux HUBs chargés simultanément. Il doit y avoir au moins un niveau entre chaque HUB (comme prévu par le scénario) au risque d'avoir un conflit entre les RIG. | |||
== Liens externes == | == Liens externes == | ||
Version du 23 août 2026 à 15:32
Principes de gestion de la caméra.

Principales vues du jeu
Scrolling horizontal (niveaux)
Comme tout jeu de plateforme 2D et 2.5D le joueur se déplace majoritairement horizontalement laissant la possibilité au level design de le conduire en hauteur ou en profondeur mais en gardant toujours une vue de coté.
Un jeu vidéo à défilement horizontal, ou en side-scrolling, est un jeu vidéo dans lequel l'action du gameplay est perçue par le joueur depuis une caméra en vue de côté, et dans lequel les personnages se déplacent généralement de gauche à droite (ou moins communément de droite à gauche) afin d'atteindre un objectif. Ces jeux utilisent le système de défilement d'éléments à l'écran. Wikipédia
2,5D (ou "Pseudo 3D")
La 2,5D est un terme polysémique qui ne désigne pas une technique en particulier, mais un ensemble de techniques, certaines se rapprochant davantage de la 2D, d'autres de la 3D. Certaines donnent au spectateur l'impression de visionner une scène en 3D tout en ayant le moins recours possible à la véritable 3D, soit pour alléger les temps de calcul, soit par choix esthétique. D'autres, au contraire, font entièrement recours à de la 3D pour afficher une scène principalement située dans un plan (2D). Wikipédia
Dans le cas de Gus Adventures, le choix de la 2.5D est purement esthétique, pour le style de gameplay associé mais aussi pour le style graphique choisi.
Les niveaux seront constitués d'assets 3D placés de façon à simuler la profondeur du décors avec un effet de Parallaxe.
Perspective 3/4 ou "Vue isométrique" (hubs)
Les villages (hubs) passeront à une vue en « perspective 3/4 », la presse dédiée aux jeux video employant souvent le terme « 3D isométrique » par abus de langage puisqu'il s'agit de pseudo 3D.
Trigger de changement de caméra
Lorsque le joueur se place dans un zone de transition entre un niveau et un HUB (Trigger box) une notification apparait (Théia vient signaler la possibilité d'entrer). Le joueur peut alors aller vers le haut. L'action déclenche le changement de caméra et de gamemode.
De la même manière à la sortie d'un HUB, le joueur va entrer dans une trigger box mais sera directement orienté dans la vue 2D sans action ou notification.
Il pourra y entrer à nouveau si besoin en orientant le personnage vers le haut à l'entrée du HUB.
Utilisation de "Set View Target With Blend"
Passage d'une caméra à une autre avec Set View Target With Blend
Permet de déclencher, à l'aide de blueprint, un changement de perspective pour passer de la caméra active du joueur à une caméra statique fixée sur une zone spécifique du niveau.
- Cours complet sur L'Epic Dev Community : Camera Framework Essentials for Games Ce tutoriel permet de faire exactement ce qui est prévu dans le jeu avec Blueprint.
- Focus sur "Set View Target With Blend" : Changer de caméra avec View Target With Blend dans UE5
Rend possible le changement de caméra avec un "blend" soit une transition paramétrable entre deux caméras (ou plus) associé au "Begin Play", un action ou une box.

Principes de caméra à appliquer dans les niveaux
Lookahead
à compléter
Jumping
à compléter
Dumping (Zoom, frames, ...)
à compléter
Juice (Shading, speed, hit freeze ...)
à compléter
Changement de vue en fonction de la zone
Si le jeu est en « 2.5D » pour les niveaux, certaines zones offriront des déplacements plus libres. La caméra passera alors à une vue 3D isométrique et prendra de la hauteur tandis que le joueur avance afin d’ouvrir la zone de jeu. Il sera ainsi possible d’explorer les maisons et de se promener sans la contrainte comme dans un jeu en 3D.
Le système de RIG
Le système (Rig, Manager, variables) est déjà générique et réutilisable tel quel — mais les instances de Rig, elles, ne peuvent pas être partagées entre hubs différents, puisque chaque hub a sa propre géométrie et ses propres zones à cadrer.
Pourquoi les instances de Rig ne sont pas interchangeables
Un BP_HubCameraRig est une classe générique (le comportement : suivi, clamp, zoom), mais chaque instance placée dans un niveau a des réglages spécifiques à cette zone (TrackedBoundsMin/Max, position, angle du SpringArm, etc.). Donc pour le Village des Dragons, on a HubCameraRig_VillageDragons_Main, HubCameraRig_VillageDragons_Mella (chez Mella) — et pour un futur second hub (disons un village de poules), il y aura besoin d'autres instances, placées et réglées spécifiquement pour cette nouvelle géométrie.
C'est exactement pareil que pour BP_Player_Hub, BP_Theia, etc. — la classe est unique et réutilisée, mais chaque niveau/hub a ses propres instances placées avec des réglages adaptés.
Ce qui EST réutilisable sans rien changer
- La classe
BP_HubCameraRigelle-même (tout son comportement Tick/ActivateRig/DeactivateRig). - La classe
BP_ZoneTransitionTrigger(le mécanisme de switch entre deux Rigs). - La fonction
SwitchHubZonesur le Manager (générique, elle prend n'importe quels Rig en paramètre). - Le principe
MainHubRig— mais attention, il faudra qu'il soit réinitialisé pour le hub actuellement chargé, pas partagé entre tous les hubs simultanément.
Attention : le systèm est pensé pour ne pas avoir deux HUBs chargés simultanément. Il doit y avoir au moins un niveau entre chaque HUB (comme prévu par le scénario) au risque d'avoir un conflit entre les RIG.