Une map pour le moteur Source avec Hammer 4

Payload ne vous dit certainement rien. Pourtant, c'est le préfixe de la map officielle pl_goldrush. Ce type de jeu particulier mérite à lui seul son petit chapitre .

Préparation du terrain

Une map payload est basée sur un système d'attaque-défense, comme cp_gravelpit ou cp_dustbowl. Les bleus attaquent et les rouges défendent.
Ce qui change dans une map payload, c'est que les captures doivent se faire en faisant passer un charriot dessus. Dans pl_goldrush, le charriot est représenté par un caddie transportant une bombe bleue destinée à détruire la base rouge. Cela dit, le charriot est juste un prop_dynamic, donc théoriquement, n'importe quel model peut convenir.

Le contrôle des points

Nous allons avoir besoin de paramétrer le team_control_point_master, de cette manière :

Ensuite, on va ajouter un team_control_point_round, à nommer comme le team_control_point_master :

Ça, c'est fait. Maintenant, on va mapper l'environnement, histoire d'avoir une base de travail.

Le chemin de fer

La création du chemin de fer se fait en deux temps :

1. le placement des models

2. les path_track

Oui, les path_track ! On va les utiliser pour indiquer au charriot (le train) quel itinéraire employer.

Itinéraire

Les rails sont à poser au moyen de prop_static. Pour rechercher les models, utilisez le filtre track dans l'explorateur de models. Il y a tout une kyrielle de models de rails que vous pouvez utiliser .

Pour symboliser les points de capture, vous pouvez, c'est recommandé, utiliser le model odels\props_trainyard rack_midcap.mdl. Voici ce que j'obtiens après avoir joué quelques minutes avec Hammer (c'est très basique ) :

Maintenant, placez les path_track. Si vous ne vous souvenez plus comment les placer, reportez-vous au chapitre qui leur est destiné. Notez qu'au niveau des checkpoints (points de capture), le charriot "monte" dessus, vous devez donc adapter vos path_track en conséquent. Mettez aussi un path_track au centre du checkpoint. Quand le charriot passera sur celui-là, le point sera capturé.

Au centre de chaque checkpoint, mettez un team_control_point, comme on le fait dans les maps CP, et donnez-lui un nom. Par exemple, CP_Partie1_x (x = numéro).

La capture

Pour déclencher la capture, on va utiliser l'output OnPass du path_track situé au milieu du point de capture. Lors de cet output, on déclenchera la capture (le SetOwer du team_control_point) et on empêchera le charriot de reculer, en désactivant le dernier path_track juste avant le path_track servant de point de capture. Voici mes outputs d'exemple pour mon point 1 :

Le CP_Partie1_1_relay est tout simplement un lien vers un logic_relay qui se chargera d'ouvrir ou de fermer des barrières et faire d'autres trucs en rapport avec la capture comme ajouter du temps.

La prochaine capture

Nous allons le voir dans la sous-partie suivante, mais je vous en touche un mot maintenant. La capture des points se fait à l'aide d'un trigger_capture_area qui bouge en même temps que le charriot (il lui est parenté). Cette entité possède une propriété Control Point qui désigne le point de capture pour lequel elle est utilisée. Or ici, il n'y a qu'un trigger_capture_area. Il faut donc, dès qu'un point est capturé, définir le prochain point à capturer, au moyen de son input SetControlPoint, comme ceci :

Dans mon exemple, CP_Partie1_2 est donc le deuxième point de capture.

This cart is a train

Comme je l'ai laissé entendre dans l'introduction, le charriot est un func_tracktrain. Mais attention le func_tracktrain est invisible. Le model du charriot est parenté au func_tracktrain.

Créez un bloc texturé en toolsclip, que vous transformez en func_tracktrain. Nommez-le Bomb_Train.
Ensuite, insérez un prop_dynamic en utilisant le model models/props_trainyard/bomb_cart.mdl, et parentez-le au func_tracktrain :

Le tracktrain demande un certain nombre de propriétés, et dans le cas du charriot, il va falloir en ajouter 3 manuellement.

Voici les propriétés habituelles à adapter :

Avant de commencer ce chapitre, je pensais naïvement que Valve avait faire une entité toute faite pour le charriot, avec gestion du dispenser, de la zone de capture et tout et tout. Evidemment, je me trompais .

La zone dans laquelle les joueurs sont habilités à faire avancer le train est faite tout simplement d'un trigger_capture_area. Créez-le, tout autour du charriot, et parentez-le au train. Pensez à recouvrir le dessus du train aussi, comme ça si quelqu'un s'y trouve (moi, j'adore me mettre dessus ), il capturera aussi. Nommez cette entité Bombe_CaptureArea, et associez-lui le premier point de capture (CP_Partie1_1 dans mon exemple).

Pour terminer le montage du train, il faut s'occuper du dispenser. A la manière du trigger_capture_area, créez un bloc, avec la texture de trigger, et transformez-le en dispenser_touch_trigger (ça aurait été plus malin de nommer cette entité trigger_dispenser, mais bon, le codeur devait être dans un mauvais jour). Hum, bref, donnez un nom à cette entité (Bombe_dispenser par exemple), et parentez-là au train.

Quand vous vous faites soigner par le charriot, le rayon soignant sort de la cheminée du charriot. Ce "point de départ" du rayon est placé via l'entité mapobj_cart_dispenser (je maudis ce codeur avec ses noms stupides ). Pas besoin de nommer l'entité (mais bien de la parenter). Spécifiez juste le nom du dispenser_touch_trigger dans la propriété Custom touch Trigger, et spécifiez bien la team qui peut bénéficier du soin.

Voici ce que donne mon charriot, avec tous ses triggers autour :

L'avancée du charriot

Faire avancer

3 joueurs au maximum

La vitesse du charriot est influencée par le nombre de joueurs présents dans la zone de capture. Ok, mais comment connaitre leur nombre ?
L'output OnNumCappersChanged du trigger_capture_area envoie le nombre de joueurs présents en son sein (le scout compte pour deux joueurs).

Le trigger_capture_area va donc transmettre le nombre de joueurs à un math_remap qui va s'occuper de redéfinir le nombre. C'est une nouvelle entité dont je ne vous ai pas encore parlé. A son tour, le math_remap va envoyer le nombre redéfini à un logic_case, qui lui va s'occuper de déterminer la nouvelle vitesse (entre 3 différentes) à donner au charriot.

Avant de voir le math_remap, voyons d'abord le logic_case, ce sera plus facile pour comprendre :

Et en voici les outputs :

Comme on peut le voir, en fonction du nombre de joueurs, on fait changer la vitesse du charriot. Maintenant, supposons qu'il y ait 5 joueurs. Dans ce cas, il ne se passe rien ! C'est pour cela qu'on va avoir recours à un math_remap .

Le math_remap

Le math_remap est un entité qui reçoit une valeur, qui l'analyse et qui en retourne une nouvelle, ou tout simplement la même en fonction de l'analyse. Le math_remap permet de fixer deux valeurs (deux bornes) : une minimale et une maximale. le math_remap, en recevant une valeur, va la comparer aux deux bornes. Si la valeur est comprise en les deux bornes, cette valeur est renvoyée telle-quelle. Si la valeur est plus petite que la borne inférieure, une valeur définie à l'avance est renvoyée, de même que si la valeur est supérieure à la borne supérieure :

• Minimum Valid Input Value : borne inférieure. Mettez 0.

• Maximum Valid Input Value : borne supérieure. Mettez 3 (au plus 3 joueurs).

• Output Value When Input Is Min. : valeur renvoyée si la valeur d'entrée est plus petite que la borne inférieure. Mettez 0.

• Output Value When Input Is Max. : valeur renvoyée si la valeur d'entrée est plus petite que la borne supérieure. Mettez 3.

En mettant 3 dans Output Value When Input Is Max, ça signifie que si la valeur d'entrée est 5, la valeur de sorte sera 3 .