Je suis entrain de concevoir un mmorpg et donc un serveur.
En local mon serveur de position marcher bien meme si les mouvement du personnage etait hasher.
Apres l'installation du serveur sur un kimsufi OVH.
Je me suis connecter ainsi que quelqu'un de mes membres afin de debugguer.
Et nous nous sommes finnallement rendu compte que le taux de rafraichissement atteignez seulement les 2/3 fps secondes.
J'ai donc penser a continuer avec les positions pour eviter les hack mais ajouter un systeme de vecteur de deplacement afin de ne pas avoir a raffraichir seulement via le serveur.
Si quelqu'un pouvait me dire si ma solution serait bonne ou si il y en a une meilleur je prend .
Oui, ça peut etre a tester !
Quel est votre protocole de connexion ? Je te conseille un UDP pour gagner en rapidité (par de ACK), mais derriere, la gestion risque d'etre difficile.
Le probleme avec un déplacement par vecteur, c'est que si le joueur change brusquement de direction : chez toi, tu verras le joueur avancer a un endroit ou il n'est jamais allé, puis d'un coup, ça "corrigera" donc il sautera.
Et pour les collisions, ouch !!
Quoiqu'il en soit, si quelqu'un a des astuces de ce genre pour pouvoir faire du "multijoueur fluide" en ligne, je suis preneur !
Cette technique est bonne, si on maîtrise asser bien les FPS on peut éviter les corrections brutals.
Si on limite les FPS à 25(suffisant je pense), cela laisse 40 ms entre chaque frame, 40 ms pour envoyer les changement de direction au serveur qui les retransmet au autre clients.
Après faut voir, si on arrive à avoir un ping inférieur a 40 sa devrait passer.
Après avoir un ping inférieur à 40 sa dépend de l'ampleur des message et du débit client/serevur mais en UDP sa doit être faisable non ? (pour un réseau local sa devrait aller, pour internet j'ai un doute...)
Hum oui en effet.
Je pense que tu pourrait par exemple non pas envoyer un vecteur de déplacement mais la cible sur laquel va ton personnage, bien sur ce n'est possible que si tu déplace le perso avec ta souris.
Pour le clavier c'est une autre histoire.
Mais en tout cas sa permettrais d'éviter que le perso rentre dans un mur alors qu'en réaliter il a tourner à gauche.
Certe il serais arrêter pendant un cours temps mais au moins il n'irat pas dans le mur.
Par contre sa ne règle pas le problème du personnage qui serat en gros téléporter 3 mètres plus loins si le ping commence a monter...
Juste comme ça si tu tourne a 2 ou 2 fps seconde c' est que tu attend d' avoir une reponse du serveur pour afficher quelque chose ....
La c' est vraiment pas bon !!
Il faut que l' affichage soit totalement independant de la partie reseau !
La meilleur solution ( a mon avis ) c' est le vecteur de deplacement avec remise a niveau : POS x y z VECTEUR vx vy vz
Ainsi il y a mise a jour de la position ( evite ainsi un decalage entre les clients ) et tant qu' il n' y a pas de changement le serveur n' a pas besoin de renvoyer des donnée a propos du Client X ou client Y Z W , car il connaisse le deplacement
Apres si tu veux eviter les hack tu rajoute un petit truc du coter serveur qui compare si les differentes position ainsi que le temps avec une marge d' erreur si le deplacement est impossible : Hack
Mais pour faire un MMO il faut deja faire la partie reseau avant le reste !!
La bande passante et les ressources serveur ne sont pas illimiter !!
J'ai jamais dis que le client devait attendre la réponse du serveur pour afficher la scene.
Et je pense que si on définit une cible a atteindre c'est mieux car le personnage s'arrêteras au niveau de la cible et n'irat pas indéfiniment dans une direction fixe si il n'a pas reçus de réponse du serveur sur le changement de vecteur.
Un déplacement par vecteur sans fixée de limite peut causer des collisions cher certain client qui ne doivent pas avoir lieux...
Après la définition des positions en plus du vecteur/cible est évidemment indispensable.
pour le hack j'ai la solution.
Quand a rentrer dans les murs c'est impossible car le client calcul les colisions.
Le serveur ne calculera finalement pas les collisions.
J'ai presque finit mon proceder de map streaming.
Ce procede assemble des morceaux de map dans la ram et ensuite les load grace a irrlicht.
Quand je l'aurais finit il se peut que je fasse un tuto dessus.
pour le hack j'ai la solution.
Quand a rentrer dans les murs c'est impossible car le client calcul les colisions.
Le serveur ne calculera finalement pas les collisions.
C'est pas ça qui empêchera le hack! Il suffit que le client envoie un paquet comme quoi il est allé dans le mur et ça suffit.
Atoboldom je ne parlais pas a toi mais a tenmaCA. Il n'a rien donné de son protocole , mais bon en deduis pas mal de ce probleme !!
Le client attend une reponse du serveur pour afficher , d'ou les 2 ou 3 fps !!
Le serveur calculais les positions !!
Le serveur dans un MMO doit avoir le moins a faire , fiable solide et rapide !! Meme avec un cluster de serveur jamais il ne pourra calculer la position et les deplacements de 1000, 3000, 5000 joueur en meme temps !!
Et puis bon en allant sur le site du projet de tenmaCA j'ai vu un vieux copin !! Maitrelame2 en personne ,C'est au moins sont 15eme projet de MMO et jusqu'q maintenant ça n'avais jamais depasser l'affichage d'une map et de 2 model sous Illrich . Mais bon au 15eme MMO je penssais qu'il avait quand meme pensez a une architecture reseau un peu plus solide que ça !!.
Sinon atoboldomle probleme cést aue le reseau internet n'est pas temps reel !! Pour certain application ça pose pas trop de soucis (Telephone par examlpe) mais pour un jeux reseau il faut qu'il y ai une contraite temps reel !! En immaginant qu'il y ai un temps de latence entre le client X et le Client Y de 200 ms (qui devrait etre inferieur de 100 pour 2 client en ADSL) ne represente que 0.2s de decalage, corriger par l'envoie de l'info position lors du changement d'etat !!
Pour l'envoi des positions pour corriger les trajectoire la dessus on est d'accord.
Mais pour en revenir à la différence vecteur cible je dirais que l'avantage de la cible est que le mouvement d'un personnage est délimité, alors en théorie l'envoie des position actuelle est la pour coriger la trajectoires des perso qui partent dans le décore mais il peut arriver qu'un client ai une hausse soudaine du ping qui peut duré quelques secondes.
Si le ping commence a dépasser les 400, ceux qui peut arriver pour un serveur distant ou encore l'utilisation de la bande pasante par une autre appli pour quelque secondes.
Dans ce cas la cible empêcherait le perso de continuer sa route tant que le serveur ne lui à pas renvoyer les véritable positions !
Le resultat serais que le perso resterait en place jusqu'a ce que le serveur donne de nouveau ordre, c'est toujours mieux que de rentrer dans le mur, non ?
On peut faire ça du coter client !! le client X envoie par exemple POS x1 y2 z3 MOVE vx vy vz
Le client Y calcul donc les deplacement du personnage X avec la gestion des colisions, il est contre un mur , y peut pas aller plus loin voila tout. Le probleme c'est apres il y aura un petit effet de teleportage si le ping est un peu elever.
Moi je pensais que le fait d'arrêter le perso au niveau de la cible permetrais de le stopper et de ne lui faire aucun mouvement, pour moi c'est toujours mieux que de lui faire faire un mouvement qu'en réaliter il n'a jamais fait.
Mouais bon de toute façon on va pas chipoter des heures sur un petit détaille comme celui là
Après sa dépend aussi du type de jeu, sur un FPS, on fait ce que l'on veut, sur un RTS c'est plus simple avec ma méthode puisqu'en principe le clique de la souris définit déjà la cible et on n'a pas besoin de la calculer comme dans un FPS où il faudrait faire cible = posPerso + direction...
Mais bon puisqu'il s'agit d'un FPS je suppose que la méthode move peut être appliquer, mais par contre sa serait mieux que le client X calcul les collisions de ses personnages, comme sa un seul client le fait et pas les 100 clients qui vont recevoir le mouvement...
Je n'ai fait qu'un mmorpg propre a moi.
C'etait un mmorpg DBZ mais cela etait trop fantaisiste donc ca n'a pas marcher.
Sinon mes 15 projets etait des projets de connaissances que j'ai essaye d'aider a trouver du monde.
Et je paticipe a evemu (emulateur pour eve online) et le boss demande un bon niveau de code donc si je suis dedans c'est que je suis pas si mauvais.
J'ai quand meme etait a l'universite en programmation et en gestion de projet.
Quand au serveur.
Citation : Ptidel
Juste comme ça si tu tourne a 2 ou 2 fps seconde c' est que tu attend d' avoir une reponse du serveur pour afficher quelque chose ....
La c' est vraiment pas bon !!
Je n'ai jamais dis que les fps du rafraichissement de l'ecran etait de 2 fps.
C'est le rafraichissement reseau.
Oui c'est un thread pour le reseau qui a une priorite moyenne.
Je pense que le hack n'est pas possible car le serveur verifie si la position est bonne.
De plus les packets sont crypter donc ca devrait enmbetter les lamers meme si les hackers n'auront aucun probleme a hackers.
Sinon voici la liste des packets qui seront envoyer.
Lors de la connexion le serveur listera a partir de MySQL le skin, model, arme...
Que le client a sur lui.
Quand la sphere de load du client 2 collide avec le nouveau client le serveur envoie le skin... du client.
Quand la sphere de vision du client 2 collide avec le nouveau client le serveur envoie les paramettre de vision... du client.
La sphere de load est 30% plus grande que celle de vision afin d'avoit finit le load avant que le client entre dans la sphere de vision.
Le serveur fonctionne en multi thread il utilise pthreads.
En premier lieu le serveur cree des services ; le collisionHandler, chat service, math service, physique service, spaceship service (a venir), creep service, game service, BDD service, map stream, voice service...
et tout les autres services pour faire fonctionner le serveur.
Les services sont des class qui retourne un pointeur a chaque thread qui cree un pointeur dessus.
A chaque client connecter le thread cree une class game.
Qui contient la position, action...
Ensuite chaque thread utilises des mutex partout pour ne pas avoir de conflict entre les differents services.
Certes cela ralenti l'execution mais pas de crash ou de conflict.
Et nous nous sommes finnallement rendu compte que le taux de rafraichissement atteignez seulement les 2/3 fps secondes.
Alors je ne sais pas trop ce que veux dire fps pour toi ... La traduction c'est image par seconde ... Et puis bon si ton serveur n' arrive qu' a envoyer 2 ou 3 paquets de donnée par seconde alors que tu as seulement 2 joueur connecté tu peut commencer a revoir son architecture
Ensuite si tes thread utilise des mutex partout , pas la peine dans utiliser puisque leur execution sera bloquer en attente de la liberation !! Autant faire du monothread !! Il y a une erreur de conception la dedans !! normalement les thread doivent etre independant au maximum juste quelques resources partagé !!
Et juste comme ça tu as été dans quelle université Car bon il me semble que tu n' as pas plus de 15 ou 16 ans selon mes souvenirs.
enfin j' dis ça j' dis rien
atoboldom:
Pour un RTS je vois bien ça comme ça , les coordonnées d' origine et le points d' arriver , mais pour un RPG ou un FPS ou l' on ne connait pas la cible du joueur ( qui se deplace avec les touches flechées par example ) on ne connais pas la cible du deplacement, seulement le mouvement actuelle du joueur
Pour les 2 - 3 packets ca venez de ma connexion internet (56k).
Pour ce qui est des mutex je dis plein de mutex j'exagere y en a 2 ou 3 qui bloque au debut pour utiliser MySQL qui est commun a chaque thread.
Ensuite ou j'ai 15 ans, je rentre en 1er S apres avoir sauter la seconde (1 an d'universite a la place).
Aux US (ou je vis) quand on est bon a l'ecole les universite viennent et demande si on veut prendre des cours gratuitement chez eux en echange d'un tres bon boulot (ca leur fait de la pub), C'est ce que j'ai fait.
Section suivante :
Administration de reseau.
Apllication designing.
Introduction to C/C++.
Databases in C++.
Oriented Object programming in C++.
OS conception ASM.
Web designing HTML/CSS/php.
[serveur] Serveur par position inconcevable
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Recueil de code C et C++ http://fvirtman.free.fr/recueil/index.html
Google
Google
Google
Google