Message
par Kamui Shiro » sam. 04 juil. 2009, 18:02
Bonjour, j'ai besoin de vos idées!
J'ai un petit soucis "technique", en gros, J'ai plein de moyens de faire quelque chose, mais aucun ne me convient tout à fait, et j'ai peur de me tromper dans mon choix. Avant tout, deux trois petites notions de vocabulaire:
client = le programme du jeu, l'affichage
serveur = là ou tous les calcul ont lieu (sur un ordinateur externe)
octet = une mesure informatique (Une connection internet personnelle peut environs envoyer de 70000 octets/s à 120000 octets/s)
Mon but est:
Je dois faire bouger mon personnage, et voir les autres joueurs bouger.
La question est, quel système adopter, sachant:
- Que l'information à envoyer pour dire qu'un joueur bouge fait environs 10 octets
- Que si j'envoie 10 fois cette information à un joueur en une seconde, ça prend 100 octets/s
- Que si 50 joueurs sont connectés et sont tous dans la même zone, et qu'un seul joueur bouge (cas minimal), ça prend 5000 o/s
- Que si tous les joueurs bougent (cas maximal), ça prend 250000 o/s
Et ceci ne me parait pas acceptable, ou bien trop grand. (Certes, un serveur normal peut facilement envoyer 250000 o/s, mais ça me semble tout de même trop grand.)
à cela, j'ai des solutions:
1) N'envoyer que la différence de position (plutôt que de dire, trucmuch est en 300,400), j'envoie que trucmuche à avancé de -2,3 pixels. ça réduira la taille du paquet.
inconvénients:
-Pas d'inconvénients à priori, excepté le fait qu'il faut s'assurer de temps en temps de la position exacte du joueur
2) Envoyer la direction dans laquelle se déplace le joueur, et laisser le client mettre à jour la position des joueurs.
Avantage :
-Réduit considérablement le nombre de paquets à envoyer
Desavantage :
-Il y a des imprécisions de quelques pixels entre la position réelle, et celle que l'on voit sur l'écran. En combat, ça serait vraiment gênant, hors combat, ça ne doit pas être trop grave.
3) Utiliser deux système différent pour le déplacement des pokemons et des dresseurs. Celui des pokemons sera plus précis (à définir) et celui des dresseurs, moins précis.
Avantage :
-Un surplus de joueurs ne sature pas le serveur
Desavantage :
-Le déplacement des joueurs semblera moins bon
4) Quand un dresseur veut bouger, il envoie au serveur dans quelle direction il veut se déplacer. Le serveur calcule la nouvelle position, et renvoie aux clients connectés celle-ci. Le dresseur peut ensuite se déplacer vers ce point.
Avantage :
-on ne peut pas tricher
-Tous les clients sont informés en même temps du déplacement d'un joueur (pas de décallage)
Desavantage :
-Léger temps de réaction de l'ordre d'une demie seconde avant chaque mouvement du joueur
-Il faut réenvoyer en permanence des paquets à tous les clients pour dire que tel joueur se déplace à tel endroit
-Saturation du serveur en paquets envoyés, et en calcul (peut-être).
-Le joueur ne peut pas se déplacer pixel par pixel. il est obligé d'avancer de 5-6 pixels d'un coup.
4) Quand un dresseur veut bouger, il bouge coté client, et indique au serveur qu'il bouge. Les deux calculent ses nouvelles positions, et de temps en temps, le client envoie au serveur la position du joueur. Le serveur compare la position envoyée par le client et la sienne, et si la différence n'est pas trop grande, il se met à jour. Sinon, il envoie au client la vraie position.
Avantage:
-Peu de paquet à envoyer (pour la gestion d'une seule personne)
-Temps de réaction rapide chez soi
Desavantage:
Chez les autres client, le déplacement du joueur a tout de même un décallage de l'ordre de 0,5s.
J'espère que ce n'est pas trop du charabia. En fait, ce qui m'aiderait, se serait que vous imaginiez un système pour faire bouger les joueurs (comme je l'ai fais en haut). Donnez moi des idées, n'importe lesquelles. Celles du dessus sont des exemples que j'ai testés, mais qui ne me conviennent pas encore tout à fait, et je ne trouve pas d'autres solutions, malheureusement.
Voilà, merci d'avance, à bientôt!