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

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

Marsh Posté le 10-01-2002 à 13:02:33    

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

Reply

Marsh Posté le 10-01-2002 à 13:02:33   

Reply

Marsh Posté le 10-01-2002 à 13:58:12    

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]

Reply

Marsh Posté le 10-01-2002 à 16:00:18    

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

Reply

Marsh Posté le 10-01-2002 à 21:44:26    

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?

Reply

Marsh Posté le 10-01-2002 à 22:31:23    

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.

Reply

Marsh Posté le 11-01-2002 à 01:45:17    

ben on aimerai que ce soit fluide qd mm ;)

Reply

Marsh Posté le 11-01-2002 à 01:54:50    

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...)


---------------
Laissez l'Etat dans les toilettes où vous l'avez trouvé.
Reply

Marsh Posté le 11-01-2002 à 02:25:02    

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

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed