Mouvement et jeu en temps réel?

[Ter Rowan]

Un cas classique :
Client émet 'move', {direction: 3}
Serveur traite la demande de mouvement
Si c'est ok serveur émet pour tout le monde dans la room : 'move', {_id: "uuid", direction: 3}
Sinon émet pour tout le monde 'setDirection', {_id: "uuid", direction: 3}
pour replacer le personnage dans le bon sens (important pour la gestion des ciblages)

autant je comprends qu'on envoie au serveur le mouvement, autant je me pose la question du serveur vers le client

pas de soucis pour setDirection
mais pourquoi move, et pas trajectoire= (x, y)(x2,y2), ... charge au client de gérer le déplacement, en fonction de qui il est :
- si client = joueur du personnage à déplacer alors "téléportation" sur position définitive, normalement sauf lag, la prédiction fait qu'il n'y a pas de téléportation, on est déjà au bon endroit
-si client = autre joueur alors animation pour chaque case.


au moins ainsi on revient à une égalité (asynchrone) serveur / client
si on fait que des mouvements relatifs (donc jamais x,y, mais que direction) on ne revient jamais à une égalité (si y a un souci)

je me trompe quelque part ?

[Maks]

Mais le joueur peut utiliser ton code d'ouverture de socket, il n'a qu'a simplement remplacer les handlers par les siens ... Du coup tu ne sais pas s'il vient d'ouvrir une page ou si c'est une reconnexion.

Oui imaginons, le joueur injecte io.connect() et ensuite ? Que peut-il faire mise à part dégrader sa vue client sans interagir sur les autres clients ?

Ca fera peut être planter mon code mais je peux savoir s'il s'agit d'une reconnexion car je n'utilise pas les rooms socket.io (pas pour les sessions de jeu en tout cas, seulement pour les chats privés). J'ai une grosse surcouche par dessus et je peux parfaitement vérifier s'il est déjà connecté dans une room.

Là de tête je sais comment faire planter facilement. Sur la socket 'move', j'ai pas prévu de cas alternatif si tu envoies autre chose que 0, 1, 2 ou 3. Mais je suis pas encore rentré dans la phrase tests unitaires + intégration (tester socket.io ça va être drôle).

Donc le truc c'est que toi tu n'as pas de bd derriere et que tu ah juste un serveur node, du coup tu mets a jour la variable coté node et c tout? forcement c plus rapide, en plus de l'utilisation des ws, je comprends que ça lag moins34

Oui je fais qqes requêtes de temps à autre. Niveau vitesse ça ne change rien car c'est asynchrone et je n'ai pas besoin d'attendre l’exécution d'une requête pour continuer.

Pour bombermine, hote moi d'un doute, je suis habitué a push avec pubnub (n'ayant pas d’hébergement autre que mutu pour l'instant), qui lui utilise le longpolling, du coup y a tjs une trace de requête qui tourne en boucle dans firebug, hors là pour bombermine, je ne vois absolument rien dans firebug, les websocket ne laisse pas de trace?
j'avoue qu'il y a l'air d'avoir pas mal de joueur syncro en meme temps, et ça marche plutot bien...

Oui c'est des WS. En fait je pense qu'autre chose que des WS en production ça doit pas être terrible. Tous les jeux du genre utilisent les WS (cf. browserquest aussi) sans s'occuper de fallbacks

autant je comprends qu'on envoie au serveur le mouvement, autant je me pose la question du serveur vers le client

pas de soucis pour setDirection
mais pourquoi move, et pas trajectoire= (x, y)(x2,y2), ... charge au client de gérer le déplacement, en fonction de qui il est :
- si client = joueur du personnage à déplacer alors "téléportation" sur position définitive, normalement sauf lag, la prédiction fait qu'il n'y a pas de téléportation, on est déjà au bon endroit
-si client = autre joueur alors animation pour chaque case.


au moins ainsi on revient à une égalité (asynchrone) serveur / client
si on fait que des mouvements relatifs (donc jamais x,y, mais que direction) on ne revient jamais à une égalité (si y a un souci)

je me trompe quelque part ?

Je comprends pas trop lol. Dans mon cas il n'y a pas de prédiction

[niahoo]

J'ai une grosse surcouche par dessus et je peux parfaitement vérifier s'il est déjà connecté dans une room.

Il peut fabriquer un faux client et te connecter une seule fois avec. Il peut aussi laisser ton code intact sauf récupérer la variable et pouvoir faire des envoi de données vers ton serveur .. A aucun moment il n'est obligé de déco reco. Et ce qu'il peut faire avec ça, c'est t'envoyer 50 messages de déplacements, ou bien si tu gérais des positions alors il pourrait t'envoyer des positions à 50 cases de distance d'un coup. C'est pas dur.

Evidemment, un simple contrôleur côté serveur réduit à néant l'intérêt de la chose, et il ne pourra pas avoir d'influence sur les autres joueurs, on est d'accord. C'est juste que Argorate flippe à propos de ça, mais un bon contrôleur et *pouf* plus de risque a priori.

[Maks]

La boucle physique tourne également sur le serveur. Ainsi si tu envoies 10 messages de déplacement avec une direction d'un coup, il va n'en prendre en compte qu'un seul car les 9 autres seront bloqués, un déplacement étant (simulé) en cours à un rafraichissement théorique de 60 FPS (ramené au même niveau sur le client grâce à au principe de framerate indépendance).

Cherche pas tu m'auras pas :p

[niahoo]

Tu ne comprends pas. C'est bien ce que je dis quand je parle de contrôleur, si tu contrôles tu le bloque, et c'est ce que Argorate doit faire. Mais le joueur a la possibilité d'envoyer les 10 requêtes vers le serveur sans problème, room ou pas room, socket.io ou WS natif, etc...

---

Evidemment, un simple contrôleur côté serveur réduit à néant l'intérêt de la chose, et il ne pourra pas avoir d'influence sur les autres joueurs, on est d'accord. C'est juste que Argorate flippe à propos de ça, mais un bon contrôleur et *pouf* plus de risque a priori.

Enfin si seulement tu as lu mes posts

[Ter Rowan]

autant je comprends qu'on envoie au serveur le mouvement, autant je me pose la question du serveur vers le client

pas de soucis pour setDirection
mais pourquoi move, et pas trajectoire= (x, y)(x2,y2), ... charge au client de gérer le déplacement, en fonction de qui il est :
- si client = joueur du personnage à déplacer alors "téléportation" sur position définitive, normalement sauf lag, la prédiction fait qu'il n'y a pas de téléportation, on est déjà au bon endroit
-si client = autre joueur alors animation pour chaque case.


au moins ainsi on revient à une égalité (asynchrone) serveur / client
si on fait que des mouvements relatifs (donc jamais x,y, mais que direction) on ne revient jamais à une égalité (si y a un souci)

je me trompe quelque part ?

Je comprends pas trop lol. Dans mon cas il n'y a pas de prédiction

dans ce cadre là, j'appelle "prédiction" l'affichage du client sans attendre le serveur
ie

je suis sur mon navigateur je joue à ton jeu. Je me déplace à gauche, je vois mon personnage bouger d'une case.

soit il bouge une fois que le serveur a dit "oui tu peux bouger" soit il bouge dès que j'appuie, sans attendre une réaction du serveur, pour moi cette deuxième solution est une prédiction (vis à vis du comportement attendu du serveur)

[Maks]

Oui le client a la possibilité de bombarder le serveur de requêtes, mais ça doit pouvoir se contrôler ça aussi

[niahoo]

La prédiction ça va être indispensable si tu n'est pas en local ...

[Argorate]

Je "flipe" car je ne comprends tjs pas comment vous voulez contrôler quelques chose à retardement...

Si tu stocks les X derniers mouvements et que tu les envois aux serveurs, au moment du contrôle, le monde n'étant plus ce qu'il était au moment des n-1 autres mouvements, je vois mal comment le serveur peux contrôler ces cas là.

Quand au fait d'envoyer chaque déplacement individuellement, je vais tester voir avec les WS si ça passe, mais pour l'instant le serveur n’arrivai pas a suivre en ajax (c'était ça mon problème du topic à la base).

Alors c'est là que je vais enfin voir la réel différence et pouvoir quantifié le rapport AJAX/WebSocket. Apparemment Maks a dit qu'il faisait comme ça, donc c'est que ça doit passé, le problème c'est que ça passe en étant seul et en local. Maintenant rajoute 100 clients et avec un serveur distant... et on en reparle^^ (je serais le premier ravi que ça marche encore!)

Donc à tester...

[niahoo]

ben mon point de vue je te l'ai donné : tu ne controles que les X derniers mouvements qui ne sont vieux tout au plus que de quelques secondes. Donc si il y avait un foutu rocher au moment ou le mec a bougé et que deux secondes apres y a plus de rocher, bon ben tu fais bouger le type et c'est bon ..

Maks tu pourrais faire un démo peut-êter ? par exemple si on avait un ping de 500ms, pourrais-tu rajouter un sleep() de 500ms avant de répondre sur ton websocket pour voir comment ça tourne en local ?