Les problèmes que j'entrevois pour un jeu en WS

[Argorate]

Bonjour,

j'aimerais discuter de certains points concernant un potentiel jeu en temps réel via websocket.

_Le premier problème que je vois, c'est le fait de ne pas devoir pusher tout le monde de toutes les MAJ, par exemple si je me déplace, je dois envoyé mes nouvelles coordonnées qu'aux joueurs qui me verrons a mon nouvel emplacement (quand je dis je, c'est au travers du serveur bien sur).

Mais du coup, faire un algo qui parcours tout les joueurs, calcule le champs de vision et regarde si je suis dedans pour savoir si oui ou non il faut les pusher, ça me semble hard niveau temps, tout ce temps de calcul est "perdu" et risque de crée des problèmes de fluiditer.

Maintenant j'ai pris que le cas d'un mouvement, imaginons que je bouge et tire, et que 10 autres personne font pareil en même temps, comment faire pour que le serveur suivent la cadence?


_Après il y le problème lié aux attaques "asyncrone", j'entends par là des attaques où la résolution du combat ne s'effectue au moment de l'envoi au serveur de l'action "j'attaque", typiquement: un projectile qui avance et qui touche une cible qu'au bout d'un certain temps.

Le problème est qu'il y a de la latence entre ce que vois le joueur et ce qui est "vrai" coté serveur.

Si je tire une boule de feu sur un mec, en pensant qu'il sera a tel position, et en me basant sur sa positon de départ (parce que je suis super fort et que je connais le jeu par coeur donc je sais a quel vitesse va le projectile et je peux anticiper), tout ça ne sert a rien si la position de départ de l’ennemi n'est pas la bonne a cause d'un temps de latence.

Sur les fps type CS et autres, j'ai souvent lu qu'il faisait en sorte de recalculer au serveur en fonction de ce que vois le joueur mais j'avoue que je ne comprends pas très bien comment faire concrètement?
Avez-vous des propositions/explication pour un tel problème?


_Enfin, niveau sécurité, existe t-il un moyen, une fois une connexion WS en place, qu'on a identifier notre user via un token ou autre, es-ce qu'un tiers peut arrivé a se greffer/connecté sur cet socket et se faire passé pour un autre en envoyant des requêtes non désiré? Quel méthode pour y remédier si c'est possible?


Merci

[Xenos]

Mais du coup, faire un algo qui parcours tout les joueurs, calcule le champs de vision et regarde si je suis dedans pour savoir si oui ou non il faut les pusher, ça me semble hard niveau temps, tout ce temps de calcul est "perdu" et risque de crée des problèmes de fluiditer.

2 mots: Arbre binaire. (ou 1 mot: régionalisation, cela revient au même).

L'idée est de découper la carte en zones statiques (qui bougent pas dans le temps), et de dresser une table qui permet de savoir quelles zones sont liées entre elles (voisines).
Après, le joueur appartient à 1 seule zone (si le joueur est un point). Pour tous les joueurs de la zone courante, plus les joueurs des zones voisines, le serveur crawle et fait le teste du champ de vision. Pour toutes les autres zones, inutile de faire le test: les joueurs dans ces zones sont forcément trop loin.

Après, mais c'est un avis personnel, tu ne résoudras pas le problème du "serveur surchargé s'il y a des centaines de personne en temps réel". Pourquoi? parce que cette problématique, cela fait plus d'une dizaine d'année qu'elle existe dans les jeux classiques (ceux qui nécessitent une installation): au bout de 16 (puis après, ca a été 32, 64 et maintenant, au mieux, une centaine) de joueurs, le serveur rame.

Donc, à mon sens, le problème n'est pas "comment j'implémente du temps réel?" mais "est-ce que j'ai vraiment besoin d'un pur temps réel?", car implémenter un temps réel, qui plus est par navigateur, qui plus est avec des budgets amateurs, cela me semble totalement cramé... Mais faut pas que ca te décourage trop quand même ^^

Pour la sécurité, j'en sais rien.

Pour les FPS, je sais que Supreme Commander a une solution assez élégante: au lieu de faire des transferts dans tous les sens pour chaque mouvement, le serveur ne fait qu'envoyer, régulièrement, un "paquet" contenant une liste d'évènements majeurs, avec leur date d'occurence. Le client récupère cette liste, et se "recadre" avec ce que dis le serveur. Entre deux listes, le client fait le calcul lui même (cela implique d'avoir une "implémentation javascript", aka coté client, de ce que le serveur fait).
Avec ce système, Sup Com arrive à tenir 8 joueurs et des centaines (1.000 max) d'unités par joueur, sans trop ramer (bon, 8 joueurs avec 1.000 unités, ca dérouille sec, mais ça peut passer).

[Ditret]

Je vais essayer de répondre du mieux que possible avec l'expérience de mon jeu Interstellaires en temps réel.

Déjà comme la dit Xenos découpe ta map en arbre ou tableau ( ou tableau d'index de nom, libre a toi de faire un choix mais les nombres sont toujours traitaient plus vite que les chaines
Exemple : tab[3] est plus rapide en lecture que tab['nom_index']
Après tu boucle les joueurs et envoient les messages à chacun, la y a pas trop vrai solutions pour faire ça mieux =/

Tu peux aussi faire une partit du calcule chez le client et éviter l'envoi au serveur.
1 - Si le client connait le nombre de joueur qu'il y a sur la map alors et si il y a aucun joueur sur la carte actuel ou se trouve le personnage, tu n'es pas obligé de contacter le serveur pour signaler une position vue que au final les autres joueurs ne te verrons pas te déplacer vu qu'il y à personne ^^.

2 - Calculer la vision chez le client !, le client reçoit toutes les positions des joueurs de sa map ( grâce à la boucle d'envoient du serveur ) mais calcule qu'il devra afficher ou pas ( ca évite énormément de calcule du coter serveur ). le problème c'est que un joueur pourrais modifier le javascript client et voir tout le monde .... et la faut te pauser la question si cette exploitation de beug pourrais faciliter le joueur ?, ou si c'est juste pour faire un effet joli en jeu ?

3- Te déplacer à la souris que au clavier, un Click souris = 1 position envoyé au serveur qui sera renvoyer au autre joueur. Comparer au déplacement clavier qui va nécessiter plein de requête et beaucoup de puissance perdue ( ou avoir un super serveur ^^ ).

Ah rajouter aussi que tu dois prendre en compte la technologie que tu va utiliser : si c'est node.js + socket.io tu va être confronté au problème que node n'utilise qu'un processus et pas possible d'avoir des threads ou autres processus pour alléger les calcules ... )

Bref, personnellement j'ai adapté le gameplay de Interstellaires au capacitée que peux fournir un jeu temps-réel sur navigateur.
tout ce qui est en temps-réel client -> socket.io
temps-réel serveur -> socket.io + node.js + SQL
( le SQl est a éviter sur le serveur, a cause des temps de réponse un peu long, le must est une requête à la connexion et une à la déconnexion )
les informations statique client -> PHP + SQL
la générations des fenêtres de jeu : ajax + template js( j'utilise mustache pour les Template ).

Voilà j’espère que ça t’éclairera =3

[Maks]

tu va être confronté au problème que node n'utilise qu'un processus et pas possible d'avoir des threads ou autres processus pour alléger les calcules ... )

http://nodejs.org/api/child_process.html

[niahoo]

le truc relou c'est qu'il faut faire autant de fork qu'on a de CPU et à chaque fois que tu upgrade ton serveur (si tu changes le nombre de CPU bien sur) tu dois re-gérer la distibution. Ou bien écrire un manager qui gère ça, non ?

[Ditret]

Oh merci Maks =3
Je regarderais un peu mieux cette doc demain, j'avais fait beaucoup de recherche la dessus y à longtemps et ça exister pas, mais il semblerais que maintenant oui =3 ( faut encore voir si c'est compatible avec socket.io )

[atra27]

Si c'est pour un jeu de stratégie en temps reel je te conseil cet article écrit par l''un des programmeur/concepteur du netcode du premier age of empire:
http://www.gamasutra.com/view/feature/30...twork_.php

Si ton jeu est plus orienté action je te conseille cet article sur le netcode des jeux source engine:
https://developer.valvesoftware.com/wiki...Networking
A noter que la méthode est similaire sur tous les jeux basés sur le netcode de quake (donc la serie des quake, doom, call of duty jusqu'au 4, half life 1 et 2 et j'en passe)

Le realtime c'est vraiment un gros bout en somme, mais bon courage pour ton projet

[Maks]

le truc relou c'est qu'il faut faire autant de fork qu'on a de CPU et à chaque fois que tu upgrade ton serveur (si tu changes le nombre de CPU bien sur) tu dois re-gérer la distibution. Ou bien écrire un manager qui gère ça, non ?

tu peux boucler sur le nombre de CPU

Je regarderais un peu mieux cette doc demain, j'avais fait beaucoup de recherche la dessus y à longtemps et ça exister pas, mais il semblerais que maintenant oui =3 ( faut encore voir si c'est compatible avec socket.io )

J'ai jamais trop compris comment ça marchait tout ça, tu peux découper socket.io en cluster si j'ai bien suivi (qui communiquent via Redis en mode pub/sub)

[Argorate]

Xenos/Ditret : dans l'exemple d'un jeu où tu tires sur d'autres joueurs, le fait de ne pas envoyé des données tel que les positions d'ennemis qu'on ne voit pas n'est pas un luxe (enfin dans un monde parfait les joueurs tricherais pas et on s'en foutrait) mais voilà c'est pas le cas!

Donc je retiens la technique du découpage, mais ça veux dire que la taille d'une zone doit etre au minimum du maximum de vision que peut avoir un joueur, sinon ça veux dire qu'un joueur à deux zone de distance peu peut etre vous voir et donc ça n'a aucun intérêt, correct?

Après je n'ai pas compris l'histoire des processus multiple. Le principe c'est d'avoir des calcules en parallèle non?
Si tu as un jeu en cours c'est un seul processus, comment le diviser en deux? Si une partie des événements/calcules ce fait sur l'un sans connaissance ou avec retard de ce qu'il y a sur l'autre, ça pose plus de soucis qu'autre chose non?


Sinon j'étais déjà tomber sur l'article sur CS, atra27. J'avoue que j'ai pas encore prit le temps de bien le lire (surtout en anglais ahah), mais je le ferais au besoin. Mais c'est clair que ça semble "complexe", mais en même temps je trouve ça très intéressant perso: comment arriver a contrer le lag générer par le réseau lui même.

[Ter Rowan]

Donc je retiens la technique du découpage, mais ça veux dire que la taille d'une zone doit etre au minimum du maximum de vision que peut avoir un joueur, sinon ça veux dire qu'un joueur à deux zone de distance peu peut etre vous voir et donc ça n'a aucun intérêt, correct?

moi ce que j'ai compris, c'est qu'au lieu de calculer qui est dans la zone de vision du joueur concerné à partir de l'ensemble de tous les joueurs, tu ne fais ce calcul que sur l'ensemble restreint par le découpage