Discussion :

[Al_th]

Bonjour a tous.
Si certains ont déja lu quelques messages de moi, ils savent que je suis actuellement avec un groupe de projet de 4 personne, en train de coder un ShootEmUp en multijoueurs. Les autres ne le savaient pas, ils le savent maintenant

Cela dit, nous rencontrons un énorme probleme de conception réseau en ce moment, et nous bloquons un peu.

Actuellement, nous possédons un ShootEmUp en 2D, qui marche, avec des ennemis ( maximum de 1000), un boss, des projectiles, des trajectoires, des positions, tout qui va bien.
Notre réseau marche de même en local ( et sur deux machines d'un réseau local), certes avec quelque ralentissement du jeu, mais il marche ( sans doute parceque nous avons choisit d'utiliser le protocole TCP et non UDP, mais la n'est pas le probleme).

Actuellement, les envois sont petits. Nous envoyons un string contenant l'appui des touches par le player, traités a l'arrivée comme si les touches étaient appuyées. Cependant, a cause du lag, il se peut qu'un des joueur evite un ennemi, mais que l'info arrivant plus tards sur l'autre soft, la vie soit décompté.

Nous nous demandions alors comment marchaient les jeux plus évoluées, et si elles envoyaient directement les positions ( puis les affichaient) réduisant ainsi le nombre de calculs. Mais chez nous, avec 1000 ennemis ( soit 2 int par position, 2000 int *4 bit, on arrive, RIEN que pour les ennemis a 8Kb envoyés/recus par update. Nous aimerions avoir un minimum de 30fps, ce qui ramene a 240Kb en envoi/reception, ce qui me parait énorme ( et encore, on envoi pas les positions boss/player ni les projectiles.

Auriez vous une idée de comment on pourrais se démerder svp ?

[theMonz31]

salut

Déja, dans ce genre de jeux, tout est multithreadé et tout passe par un serveur qui centralise les données

Un thread du serveur se "contente" d'écouter les trames qui arrivent et les mets dans une file d'attente (genre Stack par exemple) et son travail s'arrête là.

Un autre thread passe son temps à regarder si il y a des données dans le stack et si c'est le cas, décide de les envoyer aux différents joueurs connecté via un thread d'envoi.. Pour envoyer les données, le thread de traitement mets les données dans une pile d'envoi traité par un thread d'envoi dédié à celà.

Ensuite, les données envoyés contiennent non seulement les informations jeux mais également un temps de jeu qui peut etre une heure, ou bien plus simplement le temps de jeu écoulé depuis le début de la partie.

Ainsi, le poste qui reçoit l'information (par exemple qu'on a tiré à tel position à tel date pourra voir si celà est pertinent ou pas).

Par contre, tous les jeux en réseaux tourne en UDP... car le TCP est beaucoup trop lent pour faire un jeu en réseau avec "un" bon débit.

De plus, les informations envoyées sont limitées aux informations qui ont été modifiées. Les informations qui peuvent se déduirent des autres informations ne sont pas envoyés.

Après, est-ce que les données faisant foi sont celles du serveur ou celle du poste du joueur, je ne saurais répondre de façon précise à cette question. En théorie, les informations serveurs sont celles qui sont les bonnes. Donc, le serveur calcul les dégats, les points, etc...

Je pense que passer en UDP fera quand même gagner bcp de temps. LE multithread aussi.

Maintenant, si mes infos sont insuffisantes, je t'invite à nous donner davantage de détails sur l'architecture client/serveur.

[Graffito]

Bonjour,

En général, il y a un process serveur sur une des machines des joueurs ou sur une machine "serveur" externe. Ce process serveur se charge de la synchro globale.

Chaque player envoie au process "serveur" ses actions (appui des touches par le player). En fonction des actions reçues, le serveur renvoie à chaque joueur les updates.

Mais chez nous, avec 1000 ennemis (soit 2 int par position, 2000 int *4 bit, on arrive, RIEN que pour les ennemis a 8Kb envoyés/recus par update. Nous aimerions avoir un minimum de 30fps, ce qui ramene a 240Kb en envoi/reception, ce qui me parait énorme ( et encore, on envoi pas les positions boss/player ni les projectiles.

Au lieu de retransmettre toutes les positions, le process serveur peut se contenter de retransmettre aux joueurs les positions ayant changé ainsi que les résultats de ces actions (barre de vie, explosions, scores, ...).
Pour réduire les flux, le process serveur peut attendre 10 à 20 millisecondes après la réception d'un événement avant de retransmettre aux joueurs. Ainsi, si on reçoit 5 actions en 10 millisecondes, on ne fera qu'une seule retransmission de toutes les positions ayant changé.

L'horodatage est évidement souhaitable, mais complexe à gérer puisqu'il faut:

• mesurer de façon "synchrone" les temps écoulés depuis le début du jeu
• pouvoir "remonter" dans le temps pour rétablir une situation en recalculant la situation courante à partir de celle existante x messages en arrière et en applicant les dernier messages reçus triès par ordre d'horodatage.

Question : 1000 ennemis = 1000 joueurs ?

[Al_th]

Tout d'abord, merci de vos réponses.

Concernant le choix UDP/TCP, il était toujours en passe de se faire, mais je pense effectivement que nous passerons en UDP.
Actuellement, les deux applis sont en synchrones, d'apres ce que j'ai compris, vous me dites tout les deux qu'une transmissions asynchrone est peut être préférable ?

Concernant les infos envoyés qui seraient seulement les infos modifiées, effectivement, ca peut aider a réduire la somme de travail

Ensuite, les données envoyés contiennent non seulement les informations jeux mais également un temps de jeu qui peut etre une heure, ou bien plus simplement le temps de jeu écoulé depuis le début de la partie.

Travaillant avec XNA, on a une classe GameTime qui fait exactement cela, ca peut effectivement être interessant a mettre en place.

Question : 1000 ennemis = 1000 joueurs ?

Non. 1000 ennemis = 1000 ennemis.
Il s'agit d'un shoot em up vertical en multi splitté, deux écrans donc, et des ennemis qui arrivent par le haut.
Les ennemis sont une classe a part, instancié a travers la classe Player afin d'avoir des ennemis propre a chaque joueur.

Merci a vous deux, on va essayer de mettre vos conseils en pratique

[theMonz31]

ok bonne chance étudiants de l'EPITA

Pense à mettre résolu si celà est le cas

[theMonz31]

pour info:

Kaleta.Network

pourrait aider