Discussion :

[jkalzsmu]

Bonjour,

Je suis en train de me lancer dans un projet de jeux video.
J'ai besoin de détailler un peu le jeux pour bien faire comprendre mon problème:

Jeu multijoueur ou chacun contrôle un palet (dans les 4 directions haut, bas, gauche, droite).
Le jeu se joue dans une arène fermée.
Pour gagner une partie, il faut accumuler le plus de points possible (une partie est en temps limité).
Pour gagner des points, il faut foncer des les adversaires
Plus on rentre fort dans son petit copain et plus on gagne de poins

Voila, je voudrais rendre le jeu jouable en ligne, mais ça me pose beaucoup de problème.
En effet, quelles sont les techniques qu'on peux mettre en place pour être sûr que chez tous les joueurs, tous les palets sont a leur bonne place ?!?
J'imagine qu'il y a forcement un délai a attendre à cause du réseau.


Pour essayer de faire plus clair, je vais prendre l'exemple de counter strike.
je suis le joueur A et je joue en réseau contre le joueur B.

Sur mon ordinateur :
J'ai A dans mon viseur ... je tire ! Pleine tête => mon adversaire est mort

Sur l'ordinateur de B :
Aie aie, il m'as vu, il faut vite que je me barre !
Je me déplace
Le joueur A tire => ouf, à côté!

Voila, ce problème peux tout a fait se présenter si on ne le prend pas en compte. en fait, l'information de déplacement n'as pas été répercuté assez vite sur l'ordinateur de A, donc il pense que B est toujours à la même position, et donc mort ...

Voila, j'espère que des gens ont déja été confronté au problème, parce que là, j'ai vraiment pas trop d'idée ...

Thomas

[Kujara]

Pour autant que je sache, pour les jeux comme CS et UT, c'est tout simple : le serveur a une copie du code du jeu, moins la partie graphique, et c'est lui qui decide. Si tu est touché, il te le dit. Comme ça, aucun probleme.

C'est probablement comme ça dans tous les gros jeux, y compris les mmo genre WoW. Par contre evidemment, ça demande beaucoup de calculs sur le serveur, mais bon, vu le resultat final( jamais d'incoherences), ça vaut le coup.

[Kurisu]

Ce n'est pas entièrement faux, mais pas entièrement juste non plus.
Il y a plusieurs architectures pour ce genre d'opérations.
La plus simple est effectivement l'architecture client-serveur, où le client ne sert qu'à afficher les données qu'il recoit du serveur et à transmettre au serveur ce qu'il recoit en entrée du joueur.

Il y a une autre forme d'architecture, dit en etoile, qui peut se passer de serveur (c'est du peer-to-peer en principe): chaque pc représente un noeud qui va envoyer les données à tous les autres noeuds qui lui soient connus et recevoir ainsi de tous les autres noeuds. (Autant de dire que c'est pas facile à mettre en place, voire même à synchroniser).

Une autre architecture est le peer-multicast qui, avec un routeur supportant le multicast, va envoyer les données au routeur qui lui se chargera de les distribuer aux peers connectés au group.

Il me semble que le "Distributed Systems" d'Andrew Tannenbaum en traite.
(De toutes facons, cherche les termes "distributed systems" ou "systèmes distribués" pour plus des infos au sujet de ce passionnant domaine).

[jkalzsmu]

le serveur a une copie du code du jeu, moins la partie graphique, et c'est lui qui decide.

Oui c'est un truc auquel j'avais pensé.
C'est un dire qu'un des joueurs pourrait jouer le rôle de serveur.
Et tant qu'a faire, faire en sorte que le serveur soit l'ordinateur le plus puissant et avec le meilleur ping des joueurs inter connectés.


Mais dans le cadre de mon jeu, cette solution me pose un problème :
Si un joueur C demande un déplacement :
* (1) l'information est envoyée au serveur
* (2) le serveur renvoie cette information a tout le monde
* (3) chaque ordinateur reçoit l'information indiquant que le joueur C a bougé

Mais l'étape (3) est dépendante de la connexion du joueur. Donc l'information peux être incohérente entre les différents joueurs.

Ce qui fait que sur l'ordinateur de A, de B, de C, etc ... le palet du joueur C ne sera pas exactement a la même place ...

C'est assez gênant dans ce cas parce que le jeu se base sur les collision entre palets.
En effet, si on reste dans ces schéma là, c'est le serveur qui va envoyer au joueurs les collisions qu'il aura détecté.
Hors si les joueurs n'ont pas tous le même affichage, on pourra avoir quelques surprises...

[bafman]

c'est un problème insoluble dans l'absolue. tout ce que tu peut faire, c'est limiter les conséquences.
généralement, pour les jeux rapide (prenons l'exemple d'un Quake3 like), chaque client effectue lui même ses collisions, et le serveur le fait aussi de son coté. a chaque "frame" réseau, les clients vont envoyer au serveur les info dont il va avoir besoins pour effectuer sa simulation, et en échange, le client reçoit sa "vrai" position sur le serveur et les positions et info des autres joueurs. ainsi, il est lui même en mesure de simuler le déplacement des joueurs adverses de façon plus ou moins précise.

Une technique simple à mettre en oeuvre consiste à transmettre la position et le vecteur vitesse des adversaires. Ainsi, à tout moment, on peut essayer d'estimer sa position (si il n'a pas changé de direction entre temps bien entendu).

[unmanos]

Comme le dit bafman, c'est un probleme sans solutions, ou plutot avec aucune solution parfaite... A moins d'avoir un ping constant a la vitesse de la lumiere, la vision de chaque joueur sera differente des autres et egalement du serveur.

Pour travailler dans une boite de jeux online, je peux dire que ca nous arrive souvent de jetter des bonnes idees a cause de ce probleme. Sachant qu'il y a des joueurs qui peuvent etre a moins de 5 ms de ping avec le serveur (ou entre eux dans le cas d'un jeu P2P), d'autres qui seront a 150 ms (par example US/Europe). Comment faire que tout ce monde la puisse jouer ensemble est un vrai casse tete. Et que dire des joueurs (enfin tricheurs plutot) qui bloquent l'envoi ou la reception des packets temporairement (si ca peut leur procurer un avantage a cause justement d'une mauvaise conception du systeme reseau).

Si on met de cote les MMO (ou la decision est rarement base sur une question de vitesse, sinon ca avantagerait les gens qui ont une bonne connection avec le serveur) la regle c'est de ne frustrer personne.

En gros pour un jeu d'action si tu shoot quelqu'un et qu'au moment d'appuyer sur la gachette il est clairement pas dans ton viseur mais que tu as quand meme le frag c'est plutot une bonne surprise. A l'inverse si tu vois passer un missile a 15 metres de toi et que tu le prends la c'est horrible, enervant...

Il faut que ta librairie reseau supporte une simulation de lag dans l'envoi/reception de packets et simuler en local les conditions les plus mauvaises et s'assurer que ca reste jouable. Faut aussi faire gaffe au couts, si tu as besoin d'un serveur dedie par tranche de 32 joueurs simultanes ca peut revenir tres tres cher, donc il faut limiter les calculs au maximum cote serveur, tout en gardant a l'esprit que chaque joueur est un hacker (ou tricheur) potentiel.

Un vrai casse tete...

[jkalzsmu]

Merci beaucoup a ceux qui ont participer.
J'ai laissé un peu mûrir ces réflexions dans ma tête et voila ce que je pense faire.

Un des joueur joue le rôle de serveur (pas les moyens d'avoir un serveur a nous, c'est un jeu sans grande prétention !)

Ensuite je définit un deltaT qui est "la granularité" de mon moteur de jeu.
C'est à dire que le jeu n'est rafraîchit que tout les deltaT.

Le temps peux donc etre découpé en :
* 1 DeltaT
* 2 DeltaT
* 3 Delta T
* ...
* n deltaT

Ainsi je développe le scénario suivant :
* le joueur A appuie sur une touche
* l'information est envoyée au serveur
* le serveur envoi a tous les joueurs :
- Id du joueur (codée sur 6 bits => 32 joueurs possibles)
- touche enfoncée (codée sur 4 bits => 4 déplacement possible)
- a quel detaT il l'a pris en compte (codee sur 8 bits => 256 possibilités)
* chaque joueur reçoit cette information
* chaque joueur fait les ajustement nécessaire sur les palets (actualisation de la position).

ça me fait un trame réseau, mais je transmet toutes les informations nécessaires.

Qu'en pensez-vous ?

[Ozwald]

Seulement 256 deltaT possibles ça semble peu non ?
En plus tu n'as pas vraiment besoin de jouer l'économie des bits pour espérer passer tes trames réseaux plus vites puisque là tu as de toute façon un contenu bien plus petit que ton overhead causé par les headers (et donc contenu négligeable).

Rien qu'un header IP ça va faire dans les 20 octets donc ton contenu de moins de 3 octets à coté...Et même si tu sacrifie la possibilité "internet" pour rester en local afin d'économiser le header IP et coder directement dans le header ethernet en espérant aller plus vite, tu aura de toute façon au moins les 12 octets de mac du header ethernet à trimballer...

Bref je verrai bien un peu plus que 256 deltaT
(en plus ne pas coder sur des alignements "classiques" de bit c'est se compliquer la vie un petit peu )

[jkalzsmu]

Quand je dis que l'octet sert a coder 256 deltaT, ça veux pas dire qu'on peux avoir que 256 deltaT.

ça veux dire que ce que j'envoie, c'est l'identifiant du deltaT module 256. ça laisse entre le client et le serveur une marge de 256 deltaT.
Donc même si deltaT = 0.02 secondes alors ça laisse une marge de 5 secondes environ !

Après c'est sur que cette histoire de header, va me prendre du temps.
Mais bon, c'est toujours sain de pas alourdir les communications.

[unmanos]

Si tu tiens a faire des packets a la main, dans un premier temps je te conseille de faire un protocole qui puisse fonctionne en binaire et en xml genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
struct    Packet
{
    void Serialize(BinaryWriter&);
    void Deserialize(BinaryReader&);
    void Serialize(XmlWriter&);
    void Deserialize(XmlReader&);
}

Ainsi tu peux developper ton protocole entierement en texte (pour debugger c'est tres utile), et une fois que ca fonctionne tu pourras faire du binaire sur tes packets avec toutes les optimisations possibles.

En pratique, avec des packets, ca devient vite la pagaille selon la complexite du jeu, et je te conseille plutot d'utiliser des RPC, ou du moins un systeme qui au moins te genere le code de Serialization/Deserialization des packets.

[jkalzsmu]

Ok, merci pour l'info !

[IrmatDen]

Salut,

Pour rendre cette abstraction un peu plus générique, tu peux préférer une approche basée sur un template. Si un jour tu veux utiliser JSON plutôt qu'XML pour alléger un peu la version lisible par un humain, tu auras juste à développer la classe (dé)sérialisant ce format et l'utiliser comme paramètre template sans avoir à modifier quoi que ce soit d'autre.