Page 1 sur 1

Comment ça marche le multiplayer ?

Posté : sam. 2 avr. 2011, 00:47
par =[TTK]= Freshmeat
Suite à certaines questions d'une certaine personne souhaitant resté dans l'anonymat, je vous propose ici quelques tuyaux concernant la réalisation de mission multi-joueur (je sais que certains parmi vous aiment bien la langue française, surtout quand elle est de bœuf avec une sauce aux câpres).

1- C'est quoi la différence entre le serveur et le poste client ?

Donc, il faut avant tout faire la distinction entre deux choses : le serveur, et les postes clients.
Le serveur héberge la partie, comme en jeu, mais personne ne dirige de joueur (dans le cas du serveur dédié)
Les postes clients, sur lesquels jouent les joueurs.
Sorti de ça, c'est la même chose en terme de jeu (pour faire simple).

2- Donc mes déclencheurs se déclenchent simultanément et autant de fois qu'il y a de joueurs +1 ?

Exactement.
C'est aussi pour cela qu'il faut éviter d'utiliser des commandes globales directement depuis les déclencheurs.
Par exemple, avec 18 joueurs sur une mission, si un déclencheur doit gérer la création et le déplacement de 10 soldats ennemis, il y aura au final 10 x 19 soldats de créés : même Rambo il ne tenterait pas le coup sans un bon god-mode.

3- C'est quoi une commande globale ?

C'est le contraire d'une commande locale.
Une commande globale est répercutée depuis le poste où elle est exécutée vers tous les autres postes.
Une commande locale ne s'exécute que sur le poste sur lequel elle est lancée.
Lancer :
if (isserver) then {hint "hint qui sert a rien";};
Ne servira effectivement pas à grand chose avec un serveur dédié, puisque hint a une exécution locale.

4- Et comment je fais pour savoir si ma commande est locale ou globale ?

Le moyen le plus sur est d'aller sur le wiki d'arma.
En entête de chaque commande, il est indiqué si elle est globale ou locale.
Toutefois, un peu de réflexion et de bon sens permettent de le deviner : les commandes influant sur le contenu de la carte sont généralement des commandes globales : si on déplace une unité, il est préférable qu'elle se déplace pour tout le monde, si on crée un véhicule, il est aussi préférable que tous les joueurs le voit.

5- Alors il vaut mieux exécuter les commandes globales uniquement depuis le serveur ?

Pas nécessairement, il vaut mieux exécuter les commandes globales depuis un poste unique (qui sera généralement le serveur, cela dit).

6- C'est bien gentil, mais si j'ai dans mon script des commandes globales et des commandes locales, je fais comment ?

Voila une question à laquelle j'ai mis du temps à trouver une réponse : forcément, ils y ont pensé chez Bohémia : ils ont inventé le Multiplayer Framework ! ! (MPF pour les intimes, à chercher dans le wiki pour l'installation, l'exploitation et la maintenance)

7- Super, je peux afficher des messages depuis le serveur ! ! Mais bonjour la syntaxe pour créer un journal de discussion.

Hè oui, sacré journal de discussion.
Alors la solution que j'ai trouvée pour bien gérer rCreateDiaryRecord est assez simple : j'ai laissé tombé.

8- C'est nul

Oui, mais j'ai fait autrement : j'ai affecté à chaque nouvelle entrée un variable que je passe de false à true dès qu'elle doit être ajoutée, puis je l'envoie à mes clients via la commande 'PublicVariable'.
Et sur les clients, j'ai un script tournant en permanence qui surveille quand ma variable passe à true, et dans ce cas, je crée l'entrée avec CreateDiaryRecord :

init.sqf :

Code : Tout sélectionner

gljournal001 = false ; 
journaux.sqf :

Code : Tout sélectionner

_lljournal001 = false ;

while (alive player) do {

if (gljournal001 == true && _lljournal001 == false) then {player createDiaryRecord["Diary",["Journal","ca marche"]];_lljournal001 = true;};
sleep 2;
}; 
monscript.sqf :

Code : Tout sélectionner

gljournal001 = true;
publicVariable "gljournal001"; 
Et le tour est joué.

9- Et le respawn alors ?

Le respawn est une notion spécifique au multi-joueur. Il n'est pas testable en prévisualisation de mission.

Voici quelques points de réflexion sur les différents types :
- INSTANT : le joueur respawn là où il est mort.
Ce type de respawn est assez subtil à gérer : sans délais associé, le joueur revient à la vie dans la seconde, là où il est mort. Cela signifie donc que s'il était pris sous le feu ennemi, il sera bon pour faire le mort une seconde, voir une troisième puis une quatrième fois : totalement décourageant donc.
Laisser un délai permettra donc aux autres joueurs d'assainir un peu la position, avant le retour à la vie du malheureux soldat.
Autre point important, le respawn INSTANT offre un nombre de vies illimités, donc même à un contre mille IAs, l'avantage est au joueur, qui, en toute logique, pourra aller au bout de la mission si l'objectif est de faire du nettoyage : il semble donc pertinant de mettre des conditions de défaites à la mission (protection d'une zone ou d'une unité, délais pour atteindre un objectif,...)

- GROUP : le joueur respawn dans la peau d'une IA encore en vie.
Premier impératif : le groupe du joueur doit comporter des IAs. Cela veut dire, entre autre, qu'il va falloir que le joueur les gère (au moins le chef de groupe). Cela signifie aussi qu'il faut prévoir dans la mission de quoi transporter et nourrir tout ce petit monde, la difficulté de la mission est aussi plus difficile à gérer.
L'avantage premier de ce type de respawn est de limiter le nombre de respawns disponibles : contrairement au respawn INSTANT, à un contre mille, cette fois l'avantage est aux IAs.

- BASE : le joueur respawn sur un marqueur.
C'est un peu l'équivalent du respawn INSTANT, sauf que cette fois le joueur revient à la vie sur la position d'un marqueur, marqueur qui peut très bien être déplacé en cours de partie : c'est le principe du "mobil respawn" qui suit une unité ou un véhicule.
Principale difficulté cette fois pour le créateur de mission : trouver une position idéale pour les marqueurs de respawn : trop loin du champ de bataille et les joueurs passeront 15 - 20 minutes à retourner au combat, ce qui est relativement pénible, et positionné trop près du champ de bataille, il risque de se retrouver sous le feu ennemi.
Et, comme pour le respawn INSTANT, "Il semble donc pertinant de mettre des conditions de défaites à la mission (protection d'une zone ou d'une unité, délais pour atteindre un objectif,...)", sans quoi le joueur a toute les chances d'atteindre l'objectif de la mission.

- SEAGUL : le joueur revient en corbac
Pas vraiment un respawn puisque le joueur ne sera plus qu'observateur, il faut surtout éviter de l'utiliser sur des parties en HvsH, les corbeaux étant de dangereux agents de renseignements.

10- Et en version courte ?

- Respawn INSTANT
-> vies infinies pour le joueur,
-> mettre un délais de respawn,
-> mettre une ou plusieurs conditions de défaites sur la misson.

- Respawn GROUP
-> nombre de vies limitées pour le joueur,
-> oblige à gérer des IAs.

- Respawn BASE
-> vies infinies pour le joueur,
-> trouver une bonne position de respawn ou mettre un "mobil respawn",
-> mettre une ou plusieurs conditions de défaites sur la misson.

- Respawn SEAGUL
-> A proscrire dans les missions en HvsH.