jeudi, mai 24, 2018
CARMA A3
Nouveautés

Les localités – Fondamentaux de l'édition multijoueur

Accueil Forums Espace Edition Ressources du Pr Frankenstein Les localités – Fondamentaux de l'édition multijoueur

Ce sujet a 2 réponses, 2 participants et a été mis à jour par  Forxtop, il y a 1 an et 7 mois.

3 sujets de 1 à 3 (sur un total de 3)
  • Auteur
    Messages
  • #1183 Répondre

    Forxtop
    Admin bbPress
    • Messages 444
    • Lieutenant

    Il s’agit probablement de la plus grosse difficulté que rencontre les éditeurs, comprendre comment fonctionnent les localités. Je vous propose de tenter d’éclaircir le mystère. Prenez un doliprane, on y va!

    1- Introduction

    Quand on joue en multijoueur, on use d’un réseau. Un serveur, la maison (qui ici fait corps avec un propriétaire lui donnant une personnalité pour nos besoins) héberge des joueurs, des habitants. Ce qu’on appelle les localités, ce sont les portées des actes de chacun dans ce réseau. Qui va pouvoir exécuter un acte (notion d’argument)? Qui va pouvoir en voir les conséquences (notion d’effet)?

    Comprendre les localités, c’est s’assurer de savoir moduler et gérer les répercussions des commandes que vous allez employer dans vos scénarios. Tout le monde devra-t-il calculer tel élément ? Ou pourrions nous simplement en transmettre directement le résultat à tous (et le faire calculer uniquement par le propriétaire), dans un soucis d’efficacité?

    En reformulant ces deux questions et en se basant sur notre métaphore initiale, tous les habitants devraient-t-il calculer le montant des charges financières (et perdre du temps) ? Ou pourrions nous simplement laisser faire le propriétaire le calcul qui est là pour ça (et le plus efficace) et répercuter l’information ? Et puis cette information mérite t-elle vraiment d’être connu de tous ? Cela ne risque-t-il pas de préoccuper inutilement les habitants qui ont déjà tant à faire ?

    Principe directeur: moins les communications entre les différents agents d’un réseau sont nombreuses, plus l’ensemble sera allégé, la mission optimisée. Il convient toujours de s’efforcer de les limiter quand cela est possible.

    2- La notion d’espace

    La question initiale à se poser quand on veut savoir quel sera l’effet d’une commande est : qui va connaître son existence même ? Qui va la lire ? Dans quel pièce de la maison l’on pourra savoir qu’il existe cette action à exécuter ? Serait-ce dans une chambre individuelle ? Ou alors dans la grande pièce commune ? Cet espace que l’on pourrait dire « livre » contenant des instructions est donc soit placé dans la salle commune, tout le monde le consultera, soit dans une chambre et seul son occupant aura alors la possibilité de le lire.

    • Il se peut que l’espace soit dit local. C’est à dire qu’il n’existe que sur UN agent du réseau. Il n’est pas connecté au reste. Seul cet agent va lire ce qu’il contient. C’est par exemple le cas d’un déclencheur paramétré en « serveur uniquement » ou ayant la condition « isServer ». Ce qu’il contiendra d’instructions ne sera lu que par le serveur. Ici, on pourrait dire que c’est une chambre individuel, visitée uniquement par son propriétaire.
    • Il se peut aussi que l’espace soit global. C’est à dire que le contenu sera connu de tous, lu par tous les clients. C’est en quelque sorte la salle commune.

    Exemples de différents espaces :

    • Un init.sqf, présent sur toutes les machines est de facto un espace global. Tous les clients et le serveur liront ce que l’on y mettra.
    • Un déclencheur présent uniquement sur le serveur, espace local.
    • Une initbox d’une unité placée sur la carte est un espace global, tous liront son contenu.
    • Vous vous demandez pour un script ? Lisez-la suite pour comprendre. Réponse immédiate : tout dépends de où vous l’avez lancé! Ce qui nous amène à …

    3- La portée des commandes

    Vous avez déterminé la nature de votre espace contenant des instructions. Votre livre est soit placé dans la salle commune, global. Soit dans une chambre, local.

    Maintenant, chaque instruction qui y est inscrit a une portée définie. Pour connaître cette portée, vous devez vous rendre sur le wiki et regarder les informations qui y sont données ici.

    Faisons une nouvelle métaphore appropriée. Je suis dans un jardin entouré de gens, éloignés de moi de 10 mètres. Si je chuchote, seul moi entendra ma parole, on pourrait dire qu’elle locale effects_local. Si maintenant je cris, tout le monde l’entendra, ma parole est globale effects_global.

    Il convient maintenant d’articuler cela avec la notion d’espace précédemment décrite.

    • Je suis dans ma chambre individuelle, je chuchote effects_local ce que je lis sur le livre. Nul doute que seul moi m’entendra. Si maintenant, toujours dans cette chambre, je gueule très fort effects_global. Tous les habitants de la maison m’entendront. Traduit techniquement : dans un espace local une commande à l’effet local (je chuchote) n’aura de conséquences que pour celui présent dans l’espace (ici la chambre). Dans ce même espace local, une commande à l’effet global (je cris) aura des conséquences pour tous, la commande se développera en dehors de ce seul espace. Elle est puissante. Exemple d’une telle commande : deleteVehicle (voyez en haut à gauche les symboles, EG en rouge).
    • Je suis maintenant dans la salle commune, disons que les autres y sont tous aussi, et collés à moi. Le livre est placé devant nous et tout le monde va lire en chuchotant ses lignes effects_local. Il n’y aura pas de soucis et l’on se gênera pas. Nous seront également plus ou moins synchronisés. Une commande à l’effet local, dans un espace global, aura des conséquences pour tous, une visibilité générale. Nouvelle situation, identique à la précédente, mais cette fois-ci tous le monde parlent à haute voix effects_global. Une commande à l’effet global, dans un espace global a des effets qui peuvent être trop fort. Comme une commande à effet local, tout le monde fera et saura. Mais ce sont généralement des commandes puissantes! Exemple de la commande createVehicle (créant un objet) : cette dernière, nous est-t-il dit, a un effet global. Elle est puissante. Exécutée dans un espace local (déclencheur serveur), cette commande de création d’un véhicule se fera une fois mais tous pourront voir le véhicule créé. Exécutée dans un espace global (un init.sqf par exemple), la commande sera exécutée autant de fois qu’elle est lue (serveur + clients) et tous verront TOUS les effets qu’elle aura engendré. Soit un joli empilement de plusieurs véhicules en perspective.
    CONFIGURATION  
    ESPACE EFFET

    (de la commande)

    RESULTAT
    LOCAL effects_local Execution 1x

    Visibilité pour un

         
    LOCAL effects_global Execution 1x

    Visibilité pour tous

         
    GLOBAL effects_local Execution pour tous

    Visibilité pour tous

         
    GLOBAL effects_global Exécution pour tous  risque de problèmes importants (commandes puissantes)

    Visibilité pour tous

     

    Autre manière de résumer, presque arithmétique.

    Espace x Portée = Résultat

    1. LOCAL x LOCAL = LOCAL
    2. LOCAL x GLOBAL = GLOBAL
    3. GLOBAL x LOCAL = GLOBAL
    4. GLOBAL x GLOBAL = GLOBAL²

    Méthode pour savoir le comportement d’une commande :  Je détermine la nature d’ou j’exécute la commande (ESPACE) puis je vais chercher l’information sur sa portée (wiki).

    4- La notion d’argument

    Le plus compliqué est passé, détendez-vous. La notion d’argument est assimilable à la notion de « titre de propriété ». Certaines commandes, assez peu nombreuses (mais suffisamment pour être rencontrées de temps en temps), exigent un argument local.

    L’argument est l’objet, au sens de l’édition (objet, IA, véhicule, logique de jeu, déclencheur etc..) sur lequel va s’appliquer la commande.

    • Quand l’argument est local arguments_local (liste des commandes), il faut que la commande soit exécutée sur la machine détenant cet objet. Pour une unité par exemple, c’est dans la plus part des cas le serveur. Le serveur a la propriété de l’unité et peut décider de la modifier. Exemple : commande playMove. L’argument local est donc une exigence de propriété.
    • Quand l’argument est global arguments_global, tout le monde peut interagir avec cet objet.

    La plus part du temps l’argument n’est pas mentionné car inutile voir inexistant, mais si vous tombez sur un argument local, vous saurez désormais de quoi il en retourne.

    J’espère que ces éclaircissements vous aideront à mieux comprendre ce concept de localité. Si vous ne comprenez toujours pas, faîtes vous violence pour y arriver. Les localités sont la principale problématique d’édition multijoueur (et surtout première rencontrée). Alors du nerd!

    #1194 Répondre

    BoBX68
    Admin bbPress
    • Messages 253
    • Sergent Chef

    Merci pour ce post intéressant et je te rassure, très clair et compréhensible. On lève le voile du mystère des « commandes & localités » !

    #1197 Répondre

    Forxtop
    Admin bbPress
    • Messages 444
    • Lieutenant

    Super alors, c’est parfait! Merci du retour!

3 sujets de 1 à 3 (sur un total de 3)
Répondre à : Les localités – Fondamentaux de l'édition multijoueur
Vos informations:




Aller à la barre d’outils