|
Interactions Classiques - Porte/Ouverture par
Proximité, Dégâts, et Bouton
|
J'ai créé une simple map de test consistant en
un peu de BSP, une skylight, un playerstart, un skydome et une
DirectionalLight.
Je vais seulement utiliser des éléments de base
de l'éditeur qui se trouvent dans les packages officiels.
Je vais seulement utiliser des movers/Interpactors (cela revient
au même) qui sont généralement animés
avec Matinee. Si vous avez besoin d'apprendre à utiliser
Matinee, je vous recommande le Tutorial
de Hourences comme point de départ.
J'ai ajouté un static mesh cube dans la map et l'ai converti
en Interpactor. Je l'ai ensuite modifié pour qu'il ressemble
à une porte. Le pivot est au centre et je vais uniquement
l'animer de haut en bas ou d'un côté et de l'autre.
Une porte pivotante nécessitera un point de pivot situé
sur sa charnière, et vous aurez à penser où
le joueur se trouvera pour qu'il ne soit pas écrasé
contre un mur lors de l'ouverture de la porte.
*Note: Les points de pivot (ou d'origine) des statics meshes
servent de point charnière ou de centre de rotation pour
les Interpactors. Si vous avez besoin de créer une porte,
ou n'importe quel autre objet mobile qui tournera, pivotera
ou se balancera, vous aurez besoin de connaître son point
de pivot. Il est impossible de redéfinir un point de
pivot de façon permanente avec ce moteur. Si vous trouvez
un static de porte qui vous plait bien pour en faire une porte
pivotante mais que son pivot est en son centre, et bien vous
n'avez pas de chance ! Le point de pivot est déterminé
lors de la création du static dans un logiciel de 3D
mais pas dans UnrealEd.
Portes activées par Proximité, Boutons
et Dégâts: Ce type de porte est fermée
par défaut. Elle s'active avec un bouton et s'ouvre en
lui tirant dessus ou en étant dans sa zone de collision.
Utilisons notre "recette de cuisine" que j'ai présenté
dans l'Introduction
de cette série de tutoriaux:
1) Que souhaitons nous faire ?
Une porte fermée par défaut et qui lorsque activée
par un bouton, puisse s'ouvrir lorsque l'on tire dessus ou lorsque
l'on est à proximité.
2) Ingrédients:
2 triggers (boutons)
1 trigger (proximité)
1 mover (porte)
2 movers (boutons)
1 matinee
2 events Used (boutons)
1 event Touch (proximité)
3) Mélangeons le tout :
Dans la map, j'ai créé deux murs et placé
mon mover "porte" entre les deux. J'ai aussi ajouté
des interpactors plus petits de chaque côté de
la porte pour représenter les boutons et des triggers
aux mêmes endroits avec des rayons assez courts. J'ai
également changé le material de mes boutons pour
qu'ils soient plus brillants. Enfin j'ai ajouté un trigger
avec un rayon large au centre de la porte.
|
|
Du côté de Kismet, j'ai utilisé les deux
triggers pour créer les 2 events Trigger Used.
J'ai réglé leur MaxTriggerCount sur 1 et décoché
leur AimToInteract. Puis, j'ai créé un event Trigger
Touch à partir
du trigger de la porte et réglé son MaxTriggerCount
sur 0. Maintenant, je dois trouver un moyen de ne pas pouvoir
activer mon trigger de proximité tant que mes triggers
de bouton n'ont pas été activés. Donc,
je vais ajouter une Gate qui sera fermée par défaut.
Enfin, je vais ajouter une Matinee, l'animer et la mettre sur
RewindOnPlay.
|
|
4) Testez dans le jeu, cela fonctionne bien pour moi.
3) Revenons à l'étape 3 car nous avons à
ajouter les dégâts. Si vous créez un système
compliqué comme celui-ci, cela peut être une bonne
idée de tester les différentes fonctionnalités
au moment où vous les intégrées. Donc je
sélectionne la porte, et crée un event TakeDamage
à partir de celle ci. Je change le DamageThreshold à
10, met le MaxTiggerCount à 0 et le MinDamageAmount à
5. Ensuite, je vais le connecter au système en parallèle
de l'event Touch et réfléchir à ce qu'il
va se passer.
Bon, on peut prévoir quelques problèmes …
si je tire sur la porte alors qu'elle est en train de s'ouvrir,
l'event Damage va se déclencher et rouvrir la porte au
milieu de son ouverture. De plus, j'utilise deux déclencheurs
pour ouvrir ma porte mais sans essayer de les désactiver
une fois que l'un est déclenché. Ce qui veut dire
que je pourrais avoir un signal de trop, ce dont je ne veux
pas. Donc je vais ajouter une Gate qui se ferme automatiquement
après le passage du premier signal. J'ai aussi rajouté
un Delay de plus, de la longueur de la Matinee et l'utilise
pour rouvrir la Gate qui contrôle le Touch et le Damage.
|
|
5) Ajustez le. D'abord, pensez aux collisions et à l'éclairage
de vos movers. Ensuite, prévoyez les problèmes
éventuels. Est-ce que je joueur peut planter le système
tel qu'il est là ? Est-ce que le joueur peut dépasser
le mouvement de la porte ? Une fois que vous avez régler
ces problèmes, vous êtes libre d'améliorer
le système. Par exemple, je veux que la porte reste ouverte
si le joueur est dans son rayon de collision et se ferme lorsqu'il
en sort. Cela va un peu compliquer les choses.
Pour commencer, nous activons le système avec l'event
'Used' (les boutons), donc la Gate qui contrôle cette
activation doit rester (ouverte par défaut et se ferme
une fois qu'1 signal la traverse). Maintenant nous avons deux
façons d'ouvrir la porte : le trigger Touch et le Damage
de la porte. Nous allons avoir à jongler avec ces deux
éléments pour qu'ils n'interfèrent pas
l'un avec l'autre. Nous avons également deux façons
de fermer le système : le trigger Untouch et un Delay
qui activera la fermeture une fois la porte ouverte. Si l'on
tire sur la porte ouverte, je veux que le Delay referme la porte
1 seconde après qu'elle se soit complètement ouverte,
donc la durée du Delay est la longueur de la Matinee
plus 1 seconde. Ensuite, nous avons besoin de Gates pour permettre
à l'event Used d'activer le système. Donc j'en
ajoute 3 : 1 pour le TakeDamage, et deux pour le trigger Touch
(une pour le Touched et un pour le Untouched). Ils sont fermés
par défaut et ouverts par l'event Used. Comme nous devons
garder le Damage et le Touch/Untouch séparés,
je vais ajouter un booléen pour surveiller l'état
de la porte (ouverte ou fermée). Il sera modifié
à chaque fois que la porte reçoit un signal d'ouverture
ou de fermeture. Ensuite, je souhaite que le rayon de collision
de la porte soit le principal moyen d'activation de la porte
donc j'ai connecté le trigger Touch directement à
la Matinee. Si le joueur quitte la zone avant que la porte ne
soit complètement ouverte, je souhaite que celle ci reste
ouverte 1 seconde, comme avec le Damage, donc j'ajoute un Delay
d'1 seconde devant le commande Reverse de la Matinee et venant
de la sortie Untouched. Ensuite, je veux que mon event Take
Damage détecte si la porte est ouverte ou fermée,
donc j'ajoute une action Compare Bool. Si la porte est déjà
ouverte, je veux qu'il ne se passe rien, donc je ne connecte
pas la sortie 'True'. Si la porte est fermée, je veux
qu'elle s'ouvre, donc je connecte la sortie 'False' sur l'entrée
de la Matinee et règle la variable sur Open. J'ajoute
ensuite le Delay d'une durée de la Matinee plus 1 seconde,
la porte reste donc ouverte une seconde et puis se referme.
Maintenant, puisque l'on est dans les Delays, vous devez toujours
penser à ce qui passera lorsque le joueur tentera de
faire quelque chose alors que le système est en attente
de la fin d'un Delay. Pour éviter de planter le système,
j'ai des signaux qui disent au Delay de s'arrêter si le
joueur lance une nouvelle action. Si le joueur re-rentre dans
le zone du trigger alors que le Delay de fermeture est en cours,
alors je coupe ce Delay et permet au trigger Touch de se déclencher.
La dernière chose que je règle est de mettre la
Matinee sur WorldFrame et de décocher RewindOnPlay.
|
|
Améliorons cette séquence encore un peu plus.
Je veux que ma porte produise de sons quand elle s'ouvre et
se ferme et je veux contrôler ces moments donc je vais
ajouter des actions PlaySound
au système. Un pour quand la Matinee reçoit une
commande de lecture ou d'ouverture et un autre pour quand la
Matinee reçoit une commande de Reverse ou de fermeture.
Je vais cibler la porte pour que les sons aient l'air d'en venir.
|
|
Je veux aussi ajouter une indication visuelle sur les boutons
que l'on presse au début pour activer le système.
Puisque nous activons le système, mais que l'on ne peut
plus se servir de boutons une fois utilisés, peut-être
pouvons nous faire comme si les boutons étaient détruits
après leur première utilisation. Donc commençons
par quelques trucs … je vais d'abord créer une
Matinee pour animer mes boutons. Je vais créer deux groupes
dans cette Matinee (un pour chaque bouton) et les animer pour
les rentrer légèrement dans le mur, comme s'ils
avaient été enfoncés. Profitons en pour
changer le material des boutons en quelque chose de 'désactivé'
une fois utilisé. Je vais aussi ajouter un emitter d'étincelles
pour donner l'impression que c'est détruit. Nous devrions
peut-être aussi ajouter un son pour ces étincelles.
Enfin, ajoutons une light autour de nos boutons qui s'éteindra
une fois les boutons utilisés. Nous allons déclenchez
tout ça à partir des events Used. Quelques problèmes
à garder à l'esprit : d'abord, n'oubliez pas de
décoché le 'AutoActivate' des emitters, sinon
ils vont se déclencher dès le début de
la map. De plus, s'ils ne s'arrêtent pas tout seul, vous
aurez à rajouter un Delay pour les éteindre au
bout d'un certain temps, que vous connecterez aux Toggles qui
les contrôlent. Egalement, les lights que j'ai ajouté
sont des 'PointLightToggeable', puisque des ligths classiques
n'accepteront pas d'être commandé par des Toggles.
Finalement, j'ai commenté les sons pour pouvoir facilement
savoir à quoi ils correspondent.
|
|
J'ai maintenant un système qui correspond pas trop mal
à mes attentes. Nous avons une porte activée par
bouton. Elle s'ouvre lorsqu'elle reçoit des dégâts
ou lorsqu'on rentre dans son rayon de collision. Ca éteint
les boutons en créant des étincelles qui ont leur
propre son et éteint les petites lights autours des boutons.
La porte se rouvrira lorsqu'un joueur rentrera dans la zone
de collision, se fermera lorsqu'il en sortira, et s'ouvrira
si l'on tire dessus et dans ce cas là, se refermera une
seconde après son ouverture complète (seulement
si le joueur n'est pas dans la zone de collision).
6) Ajustements pour les modes solo/multi-joueur. Comme vous
l'avez sûrement lu dans la section Mode
Solo/Co-op/Multi-joueur, il y a beaucoup de considérations
à prendre en compte pour n'importe quel système
que vous créez. Le système tel qu'il est actuellement
nécessite de se poser des question pour chaque type de
mode avant de dire qu'il est terminé.
Mode Solo: Avec quoi le joueur peut-il directement
interagir dans Kismet ? Les events Used, l'event Touch/Untouch
et l'event Damage. Par défaut, bPlayerOnly est coché
pour chacun de ces events. Est-ce OK ? Est-ce que des bots par
exemple doivent pourvoir activer cette porte avec les boutons
? Est-ce que la zone de collision du Touch/Untouch doit réagir
avec des PNJs ? Et pour l'event Damage ? Cochez ou décochez
le donc en fonction de vos attentes. Si vous voulez que les
bots activent les boutons, vous aurez également à
le scripter.
Mode Multi-Joueur: Que se passe t-il quand un joueur
entre dans le système ? Et quand il sort ? Quand deux
entrent ? Quand un sort mais que l'autre reste ? Ce sont là
de bonnes questions à vous poser. Je peux prévoir
des problèmes avec plus d'un joueur avec le système
tel qu'il est actuellement. Si un sort et que l'autre reste,
celui qui sort va déclencher le Untouch et fermer la
porte alors que le deuxième est encore dans la zone.
Nous devons donc ajouter un système pour dire au Untouch
s'il y a oui ou non des joueurs dans la zone. J'ai donc ajouté
le système de comptage du tutorial Mode
solo/co-op/Multi-joueur après le touch/untouch et
cela devrait régler ce problème.
Je sais que le système complet est assez effrayant, mais
j'ai essayé de tout rassembler au mieux pour que être
sûr que ce soit lisible sur le site. Vous pouvez chez
vous aérer le tout pour que ca devienne plus lisible.
En espérant, qu'une des leçons de ces tutoriaux
est que même si une séquence peut devenir très
complexe, elle consiste toujours en des choses simples juste
emboîtées les unes dans les autres pour former
un tout.
|
|
Souvenez ce que je vous avez indiqué dans l'introduction
de ces tutoriaux : il n'y a pas de bonne ou de mauvaise façon
de créer dans Kismet. L'image suivante représente
exactement le même système avec les mêmes
fonctionnalités, mais au lieu de tout contrôler
avec des Gates, j'ai utilisé des Toggles pour activer
et désactiver les events. Du moment que ce que vous faites
est efficace, si ça marche, c'est bon.
|
|
|
|
|
|
|