gérer les déplacements en 3D par le réseau

Recherche :

Dernière réponse
Sujet : gérer les déplacements en 3D par le réseau
LeGreg	si tu peux tu batches tes envois de donnees pas la peine d'envoyer un datagramme par variable. par ailleurs, si tu envoies des datagrammes sur le net, il faut accepter de perdre des donnees (cf l'article sur xwing) et faire en sorte que ton moteur accepte les pertes de donnees et les corrige. (jusqu'a un certain point). en general le pb qui se pose sur un reseau n'est pas trop le debit (si tu n'envoies que les input de chaque joueur, tu ne peux pas saturer un reseau) mais plutot la gestion du lag (retard dans la reception des paquets). Un moteur predictif permet de donner l'illusion de fluidite alors que les donnees arrivent systematiquement en retard. Il vaut mieux que le gameplay et le design technique tienne compte de ces donnees pour un jeu multijoueur des le depart. (et pas faire l'inverse sinon => mur) A+ LEGREG

Dernière réponse

Sujet : gérer les déplacements en 3D par le réseau

LeGreg

si tu peux tu batches tes envois de donnees
pas la peine d'envoyer un datagramme par variable.

par ailleurs, si tu envoies des datagrammes
sur le net, il faut accepter de perdre
des donnees (cf l'article sur xwing)
et faire en sorte que ton moteur
accepte les pertes de donnees et les corrige.
(jusqu'a un certain point).

en general le pb qui se pose sur un reseau
n'est pas trop le debit
(si tu n'envoies que les input de chaque
joueur, tu ne peux pas saturer un reseau)
mais plutot la gestion du lag (retard
dans la reception des paquets).
Un moteur predictif permet de donner
l'illusion de fluidite alors que les donnees
arrivent systematiquement en retard.

Il vaut mieux que le gameplay et le design
technique tienne compte de ces donnees pour
un jeu multijoueur des le depart.
(et pas faire l'inverse sinon => mur)

A+
LEGREG

Votre réponse

Nom d'utilisateur

Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !

Le ton de votre message

Votre réponse

Smilies

Liste des smilies perso
Wiki smilies
Chercher un smiley

Options

Activer votre signature
Désactiver les smilies
Activer la notification par email du sujet

Aperçu

Vous avez perdu votre mot de passe ?

Vue Rapide de la discussion

LeGreg

Mara's dad

maitre_mulot a écrit a écrit :

merci.
Mais ce que j'ai peur c que qd le client court il envoie plein de nouvelle coordonnees, et si y'a 50 personnes qui courent ben ca risque de saturer le rezo non?

Ben je pense pas, des coordonées, c'est pas bien gros à envoyer !
Sauf si t'est dans un espace à 1000 dimentions (et encore...)

maitre_mulot

ben on aimerai que ce soit fluide qd mm ;)

Alload

Un truc simple mais pas terrible serait alors de limiter les mise à jour. En clair, le client n'envoit ses déplacements que les x secondes.

maitre_mulot

merci.
nous on avez pensez à:
qd le client ce deplace il envoie ses nouvelles coordonnees,
le serveur (qui sait dans quelle piece on est grace aux coordonnees) envoit les coordonnees du cliet a tous les clients succeptible de le voir (ds la mm piece).
Mais ce que j'ai peur c que qd le client court il envoie plein de nouvelle coordonnees, et si y'a 50 personnes qui courent ben ca risque de saturer le rezo non?

LeGreg

y'a plein de solutions differentes

premiere solution "server oriented":
le client ne gere que l'affichage et donc
a intervalle regulier il interroge le serveur
pour savoir ce qu'il doit afficher.
A chaque demande le serveur envoie la totalite de l'etat
du monde au joueur (ou ce qui a change depuis la derniere fois).
Les inputs sont envoyees directement au serveur qui
fait les calculs physiques et de visibilite pour chaque joueur.
Le client est simple a programmer et le serveur n'est pas
trop complique, mais on lui fait faire beaucoup de calculs
et le transfert d'information peut etre assez important.
(ca peut etre delicat sur internet par exemple)

Deuxieme solution "client oriented":
le serveur sert uniquement de relai, c'est a dire que chaque
client lui envoie uniquement les inputs utilisateur, qu'il reexpedie a chaque client connecte.
Le client se charge lui meme de maintenir un etat du monde
coherent avec ce que les autres clients croient savoir.
Le serveur est ultra simple a programmer mais le client doit
etre concu de maniere stricte, pour que la vision du monde soit la plus coherente possible avec les autres clients.
(pas de random du cote du client, mise a jour a intervalles
fixes et constants).

une solution intermediaire mais pas forcement simple
a mettre en oeuvre, c'est que chaque client + le serveur
ont leur propre vision du monde, grace aux infos relayees par le serveur. Puis a intervalles reguliers, le serveur envoie des mises a jour completes (plus ou moins longtemps suivant le degre de divergence acceptable) sachant que pour la logique de jeu
(points de vie, score etc..) le serveur a toujours le dernier mot. Le client lui se contente d'afficher une vision estimee
du monde en corrigeant le tir quand il a des infos contradictoires du serveur.

tu peux aller lire l'article suivant:
http://www.gamasutra.com/features/ [...] oft_01.htm

A+
LEGREG

Alload

Moi je ferais une appli avec un serveur à lequel chaque client envoit ses déplacements, le serveur s'occupe de créer une liste des positions de chaque client et l'envoit à chaque client qui affiche alors les images au bon endroit.

[edtdd]--Message édité par Alload--[/edtdd]

maitre_mulot

voila j'ai un projet à realiser, on utilise genesis3D pour...la 3D, c un client serveur, et la on bosse sur le protocole rezo pour gerer les deplacements.

on veut afficher sur l'ecran les autres clients connectés, et qd je me deplace, je veux que les autres me voit se deplacer.
Je supose qu'on peut recuperer les coordonnees d'un perso(de la camera peut etre) sur une map, mais pour que les autres me voit se deplacer il faudrait qu'a chaque deplacement j'envoie mes nouvelles coordonnees a chaque client et qu'il reaffiche mon perso a la nouvelle coordonnee?!
ca me semble pas realisable dans le cas ou il y a bcp de connecte.
coment ki font dans les jeux?

merci