Table des matières
COMMENT CORRIGER UNE ARÈNE ?
Tutoriel réalisé par Itsumi, merci à lui !
Il ne faut pas prendre la correction d'une arène comme une corvée car une fois que vous avez assimilé le processus, vous remarquerez qu’elles se ressemblent toutes.
Tout d’abord qu’est ce qui est important dans une arène ? La réponse principale est la sécurité ! Il est impensable de faire passer une arène où l’on a un doute sur sa sécurité.
La sécurité est un bien grand mot, je vous l’accorde.. Qu’est ce que la sécurité actuellement dans une arène ?
Ce n’est pas essentiellement une arène avec un mot de passe ou bien des gadgets pour aider à la modération de l’arène. C’est :
- Garantir une arène sans bug et avec une jouabilité dans les règles;
- Veiller à ce que le joueur ressorte avec les mêmes configurations que lorsqu'il est entré dans l’arène;
- Faire en sorte que celui-ci ne puisse pas se retrouver bloqué dans l’arène.
Pour cela il est nécessaire de faire hélas tous les cas de figure possibles.
Généralement dans les arènes que nous recevons, il y a trois types d’accès concernant trois types de personnes :
- Les joueurs
- Les admins
- Les joueurs avec accès spécifiques (ex : appartenance à une guilde)
Je vais donc développer les trois points ci-dessus pour une correction standard d’une arène. Nous prendrons en postulat une arène de forme rectangulaire telle que l’arène des Templiers que tout le monde connaît normalement. Pour ceux qui ne la connaissent pas… La voici :
Bugs & jouabilité
Attaque hors arène
Comment assurer au joueur de ne pas se faire attaquer en hors arène. Grande question ?
Beaucoup de joueurs utilisent actuellement le %BloqueAttaque% a des endroits de passages obligatoires. Comme lorsque que l’on traverse une porte ou qu’on rentre dans l’arène. C’est une idée qui a fait son chemin néanmoins qu’est-ce qui se passe lorsque l’on déco de la map et on reco ? On peut taper de nouveau !
Pour assurer que le %BloqueAttaque% soit toujours actif dans la zone voulue, on peut le généraliser avec un « Auto une seule fois » et le situer dans l’arène. Vu que la forme d’une arène est souvent rectangulaire, il nous suffit de quadriller les endroits où l’on veut que le bloque attaque agisse. L’avantage est que si le joueur déco et reco ensuite, l’“Auto une seule fois” se relancera donc il ne pourra toujours pas attaquer.
Pour bloquer sur la gauche en sachant que l’arène commence à la case X = 3 :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Pour bloquer le haut de l'arène :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Et ainsi de suite, on fait en sorte de couvrir toute la zone hors de la zone de combat. Il est bien évident que si il y a plusieurs arènes dans une même map, le tout est de découper chaque fois la map en plusieurs rectangles où l’on applique son évènement.
Il suffira ensuite de mettre à l’entrée de l’arène si on est en mode avec chevauchement par exemple :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Centre qui disparaît
C’est une tendance qui apparaît de plus en plus. L’idée est donc qu’il y a un mode avec centre où les joueurs peuvent observer mais ne peuvent pas attaquer et un mode où l’arène n’a pas de centre. Cela se gère avec une variable serveur.
Le problème principal vient dans le passage de l’arène d’une position à l’autre : il faut que lorsque vous activez la variable à la valeur où le centre disparaît que les joueurs qui se trouvent dans cette zone soient téléportés ailleurs et non vulgairement tués.
On va utiliser par exemple ce genre d’évènement :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
On cible bien la zone et on téléporte si on se trouve dans la zone. A noter que Serveur[templierpiege]=3 est le moment où le centre n’existe plus.
Page 2 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Là c’est notre protection de base si on a le centre activé.
Cela vous paraît bien ? Eh bien non car nos amis seront continuellement téléportés dans cette partie du terrain s’ils se combattent.
→ Comment remédier à cela ? Cela s’appelle un automatisme du séquentiel, nous allons utiliser une variable intermédiaire qui dira comment est entré le joueur dans l’arène. Prenons par exemple la variable publique n°13 : Variable[13] (on peut prendre aussi une bool ).
Nous allons faire en sorte que le joueur, lorsqu’il utilise un escalier pour se rendre dans le centre, ait la Variable[13] qui passe à 1.
Il suffit alors dans l’exemple des Templiers de faire pour notre ami l’escalier :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Page 2 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Puis ensuite quand on quitte le centre, faire repasser la Variable[13] à 0. On simule ainsi avec cette variable le fait que le joueur se trouve ou non dans le centre dans l’arène pendant que le centre est activé.
Il suffit maintenant de changer dans nos pages précédentes pour renvoyer les joueurs au centre à une position voulu dans l’arène :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Page 2 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Page 3 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Tout se passe bien et personne ne meurt !
Configurations joueurs
Qu’est ce cela veut dire ? Tout joueur qui entre dans la maison doit ressortir avec les mêmes variables que lorsqu’il est entré. Pour appliquer une bonne sécurité, il faut toujours mettre un Auto Résu dans la pièce adéquate de la maison lors de l’entrée dans l’arène.
Les changements de vision
%CentreY% et %CentreX% sont les deux variables concernées. Il faut toujours réinitialiser ces variables à la sortie du joueur et à sa mort. « Sa mort » veut dire qu’à coté du point de résu, il doit exister un évènement de ce type :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
A noter que bien sur qu'il est mieux de faire en sorte que le joueur ne puisse entrer dans l’arène avec une vue changée pour lui éviter tout désagrément.
Les «Bloque...», local ou non
Idem que les changements de visions, un évent “Auto une seule fois” en rappel de ce type est toujours le bienvenu.
NUMERODELAPAGE | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
A coupler avec les changements de vision et à changer selon les variables du joueur qui ont été modifiées.
Les variables
Idem que les deux précédents sauf que cela concerne par exemple la Variable[13] → ne pas oublier qu’elle doit être remise à 0. On ne sait jamais qu’une super magie frappe les joueurs dans l’arène.
C’est globalement ce que l’on retrouve mais cela s’applique à toutes variables propres au joueur qui ont été modifiées.
Joueur bloqué dans l'arène
Cela reprend exactement le préambule que j’ai fait pour présenter les principaux problèmes que l’on retrouve dans une arène. Il vous faut constamment contrôler que chaque modification faite par les joueurs dans l’arène ne devienne pas un obstacle pour les joueurs, dans le sens où ils seront bloqués.
Cela peut se trouver dans l’utilisation d’un mot de passe pour verrouiller l’arène.
Exemple chez les Templiers :
Page 1 | ||
---|---|---|
Conditions de déclenchement | Commande événements | |
Lorsque le joueur est dans l’arène (si sa position est supérieure ou égale à X = 3) et qu’il y a un mot de passe, il sera téléporté hors de l’arène.
Ne pas oublier dans la vérification des accès dans les évènements que les premières pages doivent avoir des « Condition de Déclenchement » très précises.
En conclusion
Lors de la correction d’une arène il faut :
- Mettre un “Auto Résu” à l’endroit où la résu est prévue et assurer la sécurité quant aux variables des joueurs lorsqu’ils meurent.
- Tester l’arène avec les différents accès.
- Appliquer les points expliqués plus haut.
Si vous avez des questions, vous voyez des potentielles erreurs (c’est possible mais le principe normalement est juste) et d’autres idées, n’hésitez pas