*Note: I created the most of the tutorials using the Roboblitz and Gears of War editors. Based on the engine, and the version, some properties specified may be in slightly different locations than what is displayed in the screenshots.

If you need to learn how to create a basic map I would reccomend:
For UT99, UT2K3 & UT2K4: the Unreal Wiki.
For UT3: Waylon's Tutorials.



Prologue - Mode Solo/Co-op/Multi-joueur



Lorsque vous faites vos réglages dans Kismet, il est très important de se demander où le ou les joueurs vont être, et quel va en être l'impact sur les Events. Un trigger par défaut, par exemple, va se déclencher une seule fois avec un seul joueur, ce qui est simple à régler. Mais si vous avez 10 joueurs dans votre map et que vous souhaitiez que le trigger se déclenche seulement lorsqu'un joueur entre dans une zone spécifique, que se passe t-il quand 6 joueurs entrent mais seulement 3 en sortent ? Et quand les 6 sortent ? Que se passe t-il quand 5 sortent et que le dernier meurt dans cette zone ? Il y a beaucoup de possibilités à envisager et de prédictions à faire.
Le mode solo sans co-op est le plus simple à gérer puisqu'il n'y a qu'un joueur et que vous pouvez facilement prédire où il va se trouver. Par contre, un mode solo peut devenir un peu plus délicat si vous avez des PNJs (personnages non jouables) dans votre équipe, dans ce cas vous aurez à concevoir votre Kismet plus comme un mode co-op.
Le mode co-op est lui un peu plus difficile, puisque vous avez maintenant plus d'un joueur, bien qu'il ne devrait pas y en avoir beaucoup. De plus vous pourriez avoir à prendre en compte l'aspect online.
Le mode multi-joueur est le plus difficile parce que vous ne savez pas combien de joueurs seront dans votre niveau, même si vous connaissez en général le nombre maxi de joueurs. De plus, vous aurez beaucoup de questions relatives au mode online à prendre en compte

Mode solo:
Lorsque vous abordez Kismet pour des maps solo, gardez ces quelques questions à l'esprit : Où est le joueur ? Où va t-il aller ? Cela peut-il aider le joueur à sortir de la map ? Le jouer peut-il faire planter ceci ? Peut-il détruire cela?

Dans kismet:
Les quelques propriétés dans kismet dont vous aurez à vous souciez sont le bPlayerOnly et le ClassProximityTypes. Suivant votre éditeur, cochez ou décochez le bPlayerOnly devrait autoriser le joueur seul ou le joueur et les PNJs à déclencher le trigger. Si le joueur et les PNJs peuvent déclencher le trigger alors que bPlayerOnly est coché, alors vous aurez sûrement la possibilité de désigner seulement le joueur en utilisant le ClassProximityType. Cette propriété peut également vous permettre de distinguer les joueurs amis des joueurs ennemis. Un autre réglage dans certaines entités Kismet est le ‘bAllPlayers’. Celui-ci peut par contre poser des problèmes avec des entités comme par exemple l'action Teleport, car si vous le cochez, cela va téléporter non seulement le joueur mais aussi, suivant l'éditeur, tous les PNJs – ce qui conduit au résultat, hilarant mais assez peu utile, où tout le monde dans le niveau se téléfrag puisque tous téléportés au même endroit. Donc c'est une propriété à surveiller. :)





Mode CO-op / mode solo avec des PNJs alliers:
Lorsque vous abordez Kismet pour des maps en mode co-op ou mode solo avec des alliers PNJ qui peuvent également activer les même Kismet que le joueur, gardez ces quelques questions à l'esprit : Où sont les joueurs/PNJs ? Où vont-ils ? Quels sont leur point de départ ? Cela peut-il les à sortir de la map ? Peuvent-ils faire planter ceci ? Ou peuvent-ils détruire cela ? Est-ce que les joueurs et les PNJs prennent des chemins différents et si oui, est-ce qu'un chemin va avoir une influence sur l'autre chemin?


Dans kismet :
Les quelques propriétés dans kismet dont vous aurez besoin sont le bPlayerOnly et le ClassProximityTypes. Suivant votre éditeur, cochez ou décochez le bPlayerOnly devrait autoriser le joueur seul ou le joueur et les PNJs à déclencher le trigger. Si le joueur et les PNJs peuvent déclencher le trigger alors que bPlayerOnly est coché, alors vous aurez sûrement la possibilité de désigner seulement le joueur en utilisant le ClassProximityType. Cette propriété peut également vous permettre de distinguer les joueurs amis des joueurs ennemis et des joueurs en co-op. Comme mentionné plus haut, gardez un œil sur la propriété bAllPlayers de certaines entités.

D’autres considérations plus avancées seraient d’attendre que X joueurs soient dans un certain endroit avant de déclencher quelque chose, ou alors lorsqu’un joueur atteint un certain point, d’activer une séquence qui téléporte les autres joueurs au même endroit que le premier joueur (pour un point de contrôle par exemple). Pour ces deux cas, le problème est de permettre à Kismet de savoir combien de joueurs jouent et d’ajuster le compte en conséquence. Pour l’instant, je ne connais pas de solutions fiables pour compter le nombre de joueurs. Une méthode serait de placer un trigger ou un TriggerVolume autour des points de spawn et de faire un compte initial des joueurs, et de diffuser ce nombre à toutes les autres séquences Kismet. Par contre, si 3 joueurs rentrent dans la partie et que 1 quitte le match ? Le compte serait de 3, mais si seulement les joueurs restant vont au trigger, il ne se déclenchera jamais. Vous pourriez aussi ajouter un Timer qui déclencherait le trigger sans se soucier du nombre de joueurs, mais dans ce cas, pourquoi ne pas commencer directement par ça?



Mode multi-joueur:
Lorsque vous abordez Kismet pour des maps en mode multi-joueur, gardez ces quelques questions à l'esprit : Où sont les joueurs ? Où vont-ils ? Cela peut-il les à sortir de la map ? Peuvent-ils faire planter ceci ? Ou peuvent-ils détruire cela?

Dans Kismet :
Comme décrit plus avant, vous garderez un œil sur les propriétés ‘bPlayersOnly’, ‘AllPlayers’ et ‘ClassProximityTypes’ dans votre Kismet car cela peut faire échouer pas mal d’essais s’ils ne sont pas réglés correctement.

Il y a vraiment beaucoup de choses à prendre en compte lorsque vous créez votre Kismet pour un mode multi-joueur, beaucoup trop pour tous les expliquer dans un seul tutorial puisqu’il sont tous basés sur des questions de logique (avec beaucoup trop de « si … alors… ») . Cependant, nous allons quand même examiner une situation:

Si vous souhaitez créer une séquence Kismet qui surveille le nombre de joueurs qui entrent et sortent d’une zone spécifique, vous aurez besoin de bien la penser pendant sa réalisation. Supposons que 6 joueurs soient dans la map, et que vous vouliez que dans une zone se déclenche des bruits d’ambiance ou des emitters, mais seulement quand des joueurs s’y trouvent. Vous aurez besoin d’un système qui détecte si des joueurs sont présents ou pas. Ca semble simple : si des joueurs entrent, alors je fais ceci, si les joueurs sont sortis alors je ne fais pas ceci. Ca ressemble à un simple système vrai/faux. Dans le fond, c’est ca. Mais on ne peut pas utiliser un simple système vrai ou faux pour déclencher cela. Regardez l’image ci-dessous : cela ressemble à un système qui va nous dire si oui ou non un joueur est dans une zone de trigger. Si on connecte un Compare Bool au système, ne va-t-il pas nous dire quand un joueur entre, puisque le Bool "Inside" va mettre le booléen sur "True" et donc le Compare autorisera le trigger à se déclencher ? Et si un joueur sort, le Untouched va remettre le Bool sur faux, le Compare verra Faux et éteindrait le système ? Bien, avec un joueur : Oui. Avec plusieurs joueurs : non.



Gardons l'exemple simple en prenant deux joueurs. Si le joueur 1 entre dans le système, le Booléen est mis sur vrai, et si on fait une comparaison, l'Event se déclenchera. Si le joueur 1 quitte le système, le booléen basculera à faux et le Compare éteindra le système. Donc là ça marche. Si le joueur 1 ET le joueur 2 entrent dans le système, le booléen est mis sur vrai deux fois. Quand le Compare est activé, il se mettra sur vrai et l'event va se déclenchez. Mais que se passe t-il si le joueur 1 sort et que le joueur 2 reste ? Le Untouched du trigger va s'activer quand le joueur 1 va sortir et le système va s'éteindre alors que le joueur 2 est encore dans la zone. De ce fait, le système est défectueux.
Ce dont on a besoin, c'est que le système prenne en compte le nombre de joueurs qui entrent et qui sortent. Nous avons donc besoin d'un compteur qui déclenchera un système lorsqu'il sera supérieur à 0 et s'arrêtera quand il sera à 0. Voici ce système:



Dans l'image ci dessus, les trigger events sont tous réglés sur un nombre illimité d'utilisations (MaxTriggerCount=0) et les deux IntCounter surveillent le nombre de joueurs présent dans le système. Pour le compteur du haut, l'incrément est mis à 1, ce qui signifie qu'à chaque fois qu'un signal entre (quand le Touched du trigger se déclenche), 1 est ajouté à la valeur A. De manière identique, l'incrément du compteur du bas est -1. Ce qui signifie que 1 est soustrait à la valeur A à chaque fois le Untouched du trigger est activé. Donc la valeur A va monter et descendre en fonction du nombre de joueurs qui entrent et qui sortent de la zone de trigger. Les valeurs B des deux compteurs sont à 0 parce que nous utiliseront 0 pour désigner le trigger comme vide. Donc reprenons notre exemple. Joueur1 entre dans le trigger et la sortie Touched est activée. Le signal entre dans le compteur du haut, et la valeur 0 de A est augmentée de 1. A=1 et B=0, donc le Int Counter active sa sortie A > B, qui par conséquent déclenche (Turn On) le Toggle. Si le joueur1 sort, la sortie Untouched s'active, et le IntCounter du bas soustrait 1 à la valeur A. Donc A=0 et B=0, par conséquent la sortie A==B du compteur du bas s'active et éteint le Toggle. Si le joueur1 et le joueur2 entrent, la sortie Touched du trigger se déclenche deux fois, ce qui donne A=2. Comme A>B, le Toggle s'active. Si le joueur2 sort, la sortie Untouched est activée une fois. Donc A devient égal à 1. Comme A est toujours supérieur à B, rien ne se passe puisque la sortie A>B du compteur du bas n'est connectée à rien. A est toujours à 1, et lorsque le joueur1 sort, la sortie Untouched re-déclenche et A devient égal à 0. Comme A est maintenant égal à B, le Toggle s'éteint.
Logiquement, ce système devrait fonctionner mais il nécessite plus de tests. Je ne l'ai pas testé online, et je ne sais ce qu'il peut se passer si un joueur meurt dans la zone du trigger, cela compte t-il comme un Untouched ? Je le suppose mais je ne l'ai pas vérifié.

J'espère que cela vous aura aidé à voir comment gérer vos différents modes de jeux, et spécialement pour le mode multi-joueur. Bonne chance!