Les portes

Écrit le 09/12/2004 par sUPREz
Dernière mise à jour : 30/01/2006

Introduction

Ca peut paraître idiot mais c'est intéressant de savoir faire de bonnes portes. Surtout que dans Half-Life 2, Tout n'est pas si simple ! On y trouve les portes basiques, les portes un peu plus évoluées (à base de models) et les portes « dynamiques » régies par la physique.

Les portes classiques

Ce sont les portes telles quelles étaient déjà présentes dans Half-Life premier du nom. On trouve les portes coulissantes (« func_door ») et les portes qui tournent (« func_door_rotating »).

[size=16]a) func_door[/size]

Créez un « brush » de la taille de votre porte (la taille générique est de 48x108 pour la porte et de 56x112 avec l'encadrement). Sélectionnez votre porte, clic-droit, « Tie To Entity ». Choisissez « func_door ».

Les champs intéressants sont les suivants :

Name : Le nom de la porte
Speed : Permet de régler la vitesse d'ouverture
Lip : Détermine la position de la porte une fois complètement ouverte. 0 aura pour effet de déplacer la porte de toute sa longueur. 2 fera se déplacer la porte sur sa longueur � 2. C'est intéressant pour créer des portes qui ne s'ouvrent pas complètement.
Move direction : la direction vers laquelle la porte s'ouvre.

[size=16]b) func_door_rotating[/size]

Ces portes sont similaires aux premières mais au lieu de se déplacer en translation, elles s'ouvrent avec une rotation.

Créez un « brush » de la taille de votre porte, clic droit, « Tie To Entity » et choisissez cette fois « func_door_rotationg ». En affichant les aides visuelles (« View » > « Show Helpers ») on aperçoit au milieu de la porte une boule. C'est en fait l'axe de rotation de la porte. Pour les mappeurs Half-Life 1, fini les blocs origin. Dans les vues 2D, il est possible de déplacer cet axe.

http://www.game-lab.com/images/tuts/hl2_doors/image_01.jpg

Les propriétés importantes à connaître sur les portes rotatives (en plus de celles citées pour les portes coulissantes) sont les suivantes :

Origin : emplacement de la boule origine ;
Distance : Distance en degré de rotation de la porte.

Dans les « flags », on retrouve globalement les mêmes choses avec les différences suivantes :

Reverse Dir : La porte s'ouvre dans le sens contraire. C'est-à-dire que la porte se tire.
X-Axis : Définit X comme axe de rotation de la porte
Y-Axis : Définit Y comme axe de rotation de la porte

[size=16]c) L'ouverture des portes[/size]

Maintenant que nous avons notre porte, il faut louvrir :) Nous avons plusieurs possibilités. Soit le joueur se présente devant la porte et elle s'ouvre, soit il clic sur la porte, soit il appuie sur un bouton.

- La présence du joueur

Les portes ont pour comportement par défaut de s'ouvrir si le joueur touche la porte. On peut désactiver ce paramètre dans l'onglet flags (« Touch Opens » à décocher). Dans ce cas, on a alors besoin d'un trigger qui déclanche l'ouverture de la porte. Plaçons notre trigger_multiple devant la porte. Les propriétés n'apportent pas grand chose pour le moment. Attardons nous plutôt sur l'onglet « Outputs ». Cette page va nous permettre de configurer le comportement de notre trigger. En cliquant sur Add, on rajoute un comportement. Le champs « My Output Name » désigne à quel moment notre comportement se déclenchera. « Target entities named » est le nom de l'entité qui sera affectée par le comportement. « Via this input » détermine quel action fera l'entité ciblée. Dans notre cas, on choisira « OnStartTouch » pour le premier champ, ensuite on choisit la porte qu'on souhaite ouvrir et on met « Open » dans le troisième champ. En choisissant « Open », le trigger ne fera qu'ouvrir la porte quoi qu'il arrive et il faudra par conséquent un second trigger pour fermer la porte.

Notez que des « flags » du trigger peuvent être très intéressants pour des cas particuliers ou certains puzzles.

Client : le joueur peut déclencher le trigger ;
NPCs : les NPCs peuvent déclencher le trigger ;
Pushables : le trigger peut être déplacé par l'intermédiaire d'un objet ;
Physics Objects : Les objets physiques (bidons, poutres, etc.) peuvent déclencher le trigger ;
Only player ally NPCs : seulement les NPCs alliés peuvent déclencher se trigger ;
Only client in vehicles : Seulement le joueur avec un véhicule ;
Everything : Tout et n'importe quoi :)
Only client « not » in vehicles : Seulement le joueur sans véhicule peut déclencher le trigger.

- Un bouton

Placez un petit bouton à votre convenance. Convertissez-le en « func_button ». Dans l'onglet « Outputs » nous allons créer un comportement similaire au précédent.

My output named : OnPressed ;
Targets entities named : le nom de votre porte ;
Via this input : Toggle.

« Toggle » permet de contrôler l'ouverture et la fermeture de la porte avec un seul bouton. Dans ce cas, il est intéressant de régler le champ « Delay Before Reset » des propriétés.

- Porte seule

Dans ce derniers cas, on va s'attarder sur les différents comportements de la porte seule, c'est-à-dire sans trigger ni boutons. Dans l'onglet « Flags » on trouve les options suivantes :

Starts Open : Au début du niveau, la porte est en position ouverte ;
Non-solid to Player : Permet au joueur (seulement) de traverser la porte ;
Passable : Equivalent du champ précédent mais pour tout le monde ;
Use Opens : permet d'ouvrir la porte avec la touche utiliser ;
NPCs can�t : les NPCs ne savent pas ouvrir cette porte ;
Touch Opens : Il suffit au joueur de toucher la porte pour l'ouvrir ;
Starts locked : La porte est verrouillée et il faudra un trigger (bouton ou autre) pour la déverrouiller via l'input Unlock ;
Door Silent : La porte ne fait aucun bruit.

[size=16]d) conclusion[/size]

Bon, toutes ces portes sont sympathiques mais elles commencent à faire tâche dans un moteur comme le Source Engine. Elles s'ouvrent comme des automates (l'effet est très moyen sur des portes de maison par exemple) et les ombres sont statiques. Le côté non éclairé de la porte restera noir même si il se retrouve nez à nez avec une lumière.

C'est pourquoi Valve a rajouté des portes utilisant des models.

Les portes à base de models

[size=16]a) fonctionnement[/size]

Ces portes fonctionnent globalement comme les précédentes mais ont l'avantage d'être des models. Cela implique (par exemple) des ombres dynamiques.

L'entité se nomme prop_door_rotating. Les champs importants sont :

Name : Ca ira non ?
World Model : model de base de la porte. Les plus connus sont « models/props_c17/door01_left.mdl » et « models/props_c17/door02_double.mdl » ;
Skin : Le numéro de la skin (faites des essais) ;
Disable Shadow : permet de désactiver l'ombre globale de la porte si elle est en intérieur par exemple ;
Rotation Distance : Distance de rotation en degrés ;
Speed : vitesse de rotation.

Dans les « flags » on remarque les champs suivants « Door Silent (No sound, does not alert NPCs) » et « Door Silent (Does not alert NPCs) ». On apprend donc que l'ouverture de la porte alerte les monstres aux alentours. Ces deux champs sont donc très pratiques dans les zones de combats.

Attention au rendu de hammer, on ne voit par exemple pas les poignées mais elles bien présentes.

[size=16]b) Exemples[/size]

Nous allons faire, pour la même porte, trois situations différentes. La première s'ouvrira avec un clic. La seconde s'ouvrira avec un bouton et la dernière sera verrouillée.

- porte simple

Il suffit de laisser les paramètres par défaut et de cocher uniquement « Use Closes » dans les « Flags ». Dans ce cas, je joueur devra cliquer sur la porte pour l'ouvrir.

- porte activée par un bouton

Il faut cocher « Ignore player +USE » dans les « flags ». Ensuite, créez un bouton avec le comportement suivant (onglet « Outputs ») :

My output named : OnPressed ;
Target entities named : le nom de votre porte ;
Via this input : Toggle.

- porte verrouillée

Il suffit de cocher dans les « Flags » « Start Locked ». Pour déverrouiller cette porte, nous allons créer un bouton qui aura le comportement suivant :

My output named : OnPressed ;
Target entities named : le nom de votre porte ;
Via this input : Unlock.

[size=16]c) Conclusion[/size]

Ces portes sont plus jolies que les précédentes avec des ombres dynamiques et des poignées mais elles s'ouvrent toujours d'une manière très automatique.

Les portes régie par la physique

Rappelez-vous dans Half-Life 2, certaines portes étaient bloquées par un cadenas ou bar une barre en fer. Une fois ouverte, un coup de gravity gun les faisait valser contre le mur. Nous allons faire une porte sur le même modèle.

[size=16]a) Porte simple[/size]

Créez votre brush de porte. Comme cette porte sera régie par le moteur physique de Half-Life 2, on va la convertir en entité « func_physbox ». On va ensuite créer une contrainte physique. Ca sera le rôle du « phys_hinge ». Cette entité créé une contrainte d'accroche par rotation. Ce n'est pas très clair mais ça permet de fixer un objet physique à un axe, comme une pancarte accrochée à une barre par exemple. Dans cette entité, on spécifie l'objet physique concerné par cette contrainte (ici c'est notre porte). Le champ « Friction » permet de rajouter des frottements. Par défaut, l'axe d'accrochage est horizontal. Pour changer l'axe, on va tirer la boule (origin de l'entité affichée avec l'option « Show Helpers ») dans l'une des vue 2D pour quelle longe le bord de la porte.

http://www.game-lab.com/images/tuts/hl2_doors/image_02.jpg
http://www.game-lab.com/images/tuts/hl2_doors/image_03.jpg

À ce moment-là, la porte est finie. Seulement il reste un problème. Dans notre cas, l'encadrement de la porte est petit et trop près de l'axe. Le moteur physique aura donc du mal à faire la détection de collision et on risque d'avoir quelques comportements étranges voir un plantage de Half-Life ². On va donc créer un mur virtuel pour la détection des collisions de l'objet physique porte. On crée un mur de chaque côté de la porte dans la continuité de l'encadrement, le tout avec la texture « nodraw ». On converti ces deux murs en « func_clip_vphysics ».

http://www.game-lab.com/images/tuts/hl2_doors/image_04.jpg

Cette entité va fonctionner comme un mur invisible, perméable aux NPCs et au joueur mais qui bloquera tous les objets physiques. Ce n'est pas exactement ce qu'on voulait. Tous les objets physiques ne doivent pas être bloqués par un mur invisible, ce serait idiot. On va donc utiliser un filtre pour savoir quel objet doit être bloqué.

Insérez dans votre niveau l'entité « filter_activator_name ». Comme son nom l'indique (un peu :p), cette va faire un test par rapport au nom et détecter si l'objet qui rentre en collision avec notre « func_clip_vphysics » doit rebondir ou passer à travers. Remplissez les champs comme ceci :

Name : nom de votre filtre ;
Filter Mode : Allow entities that match criteria ;
Filter Name : Le nom de la porte ;

Avec cette configuration, Toutes les entité portant le même nom que la porte passeront le test. Les autres seront bloquées par le filtre. En choisissant Disalow, ca serai exactement l'inverse : la porte passe à travers et tous les autres objets rebondissent. Il reste maintenant à indiquer à notre mur invisible (« func_clip_vphysics ») qu'il doit utiliser notre filtre. Tapez donc le nom du filtre dans le champ « Filter Name ».

Avec tout ceci vous devriez avoir une porte qui s'ouvre et se referme en fonction des interactions physiques qu'elle subit. Il reste tout de même un petit défaut que je n'ai pas réussi à enlever. Ca concerne l'effet de va et vient incessant de la porte qui va finalement la remettre en position d'origine. Je suppose que cela vient de l'encadrement qui génère une force sur les coins. Je n'ai pas trouvé (pour le moment) comment rendre l'encadrement de la porte neutre pour qu'il ne subisse ou n'applique aucune force physique. Affaire à suivre...

[size=16]b) Porte bloquée[/size]

Sur le modèle de la porte précédente, on va faire une porte bloquée par une planche de bois par exemple. On va d'abord mettre des petits crochets derrière la porte avec notre planche en bois en travers. La planche sera elle aussi un « func_physbox ». Il faut aussi bloquer la porte pour qu'elle ne puisse s'ouvrir que dans un sens (ça me rappelle The Big Lebowski et sa planche censée bloquer sa porte... ^^).

http://www.game-lab.com/images/tuts/hl2_doors/image_05.jpg
http://www.game-lab.com/images/tuts/hl2_doors/image_06.jpg

Une fois tout ceci terminé, il faut simplement modifier un peu notre « func_clip_vphysics » pour qu'il soit collé contre la porte du côté où elle ne s'ouvre pas, toujours pour simplifier la détection des collisions. Pour être sur que la planche ne casse pas, on coche « Don't take physics damage » dans les « Flags ».

http://www.game-lab.com/images/tuts/hl2_doors/image_07.jpg

Voila c'est fini ! Oui déjà :) Le moteur physique s'occupe du reste. En tirant au gravity_gun sur la porte, elle s'ouvrira, le moteur physique détectera une collision, la planche ne pourra pas être cassée par une force physique, et la porte rebondira et se refermera.

[size=16]c) Porte à ouverture automatique (ou presque)[/size]

Le seul problème qu'il reste avec ce type de portes, c'est qu'elles paraîssent peser des tonnes. Le joueur arrive à peine à l'ouvrir en la poussant. On va donc utiliser un trigger qui va déclencher une force qui ouvrira la porte.

Toujours sur le modèle de la première porte, on va rajouter un « trigger_multiple » juste devant la porte. Ce trigger déclenchera un « env_physimpact » qui ouvrira la porte. Placez cette entité vers le bord extérieur de la porte très près pour éviter que des objets s'interposent entre la porte et elle. Dans mon cas, j'ai mis la magnitude à 150 et la distance à 10. Le champ « Point to Entity » peut être intéressant pour les petits objets car il frappe sur le centre de gravité mais nous le laisserons vide. Dans les « Flags » on coche « No fall-off » et « Ignore Mass ». J'ai aussi remonté la friction du « phys_hinge » à 200 pour que la porte se bloque une fois ouverte. Tout ceci se paramètre à votre convenance et si vous préférez une porte qui se referme, ne changez pas la friction. En ce qui concerne le trigger, on rajoute le « Output » suivant :

My output named : OnStartTouch ;
Targets entities named : le nom de votre « phys_impact » ;
Via this input : Impact.

Ca devrait être bon pour cette petite fonctionnalité en plus. Ce n'est qu'un exemple et avec ce moteur physique, on peut s'amuser et trouver d'autres trucs ben plus originaux alors à vos cerveaux messieurs.

Conclusion

Voila, si vous avez bien lu ce tuto, vous devriez maintenant être calés sur les portes. Pour ceux qui en redemandent, choppez le vmf pour voir comment tout ça fonctionne « en vrai ».

http://www.game-lab.com/images/tuts/hl2 ... _doors.vmf

Si vous trouvez des erreurs, des incohérences, enfin des conneries quoi, mailez-moi, je corrigerai tout ça.