Aller au contenu

« Caméra » : différence entre les versions

De PLOTFALL Wiki
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.

Vue conceptuelle pour les mouvements de la caméra
Vue conceptuelle pour les mouvements 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.

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.

SetViewTargetwithBlendBP

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_HubCameraRig elle-même (tout son comportement Tick/ActivateRig/DeactivateRig).
  • La classe BP_ZoneTransitionTrigger (le mécanisme de switch entre deux Rigs).
  • La fonction SwitchHubZone sur 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.

Liens externes