Pokemon Eternity [MMORPG]

Alexy · Message par **Alexy** » jeu. 02 juil. 2009, 13:58

C'est certe mon premier message sur ce topic,mais j'ai suisvi le proet depuis le début (avec un autre compte)
Alors si y a besoin de quelque un pour la Béta,je suis là

Sherry · Message par **Sherry** » ven. 03 juil. 2009, 10:57

Donc,j'aime bien l'dée...

Kamui Shiro · Message par **Kamui Shiro** » sam. 04 juil. 2009, 00:48

Merci à vous. Je contacterais des gens si besoin!

Alors, pour ce soir:
On peut voir les autres joueurs en ligne (Mais on ne peut pas les voir marcher) !
On peut marcher sans lag !

C'est tout, mais ça m'a valu pas mal d'heures

Kamui Shiro · 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!

Mr. Bubble · Message par **Mr. Bubble** » sam. 04 juil. 2009, 18:10

j'aurais du mal à t'aider, mais (si ça peut t'aider), je préfère la 3

Silver_lugia · Message par **Silver_lugia** » sam. 04 juil. 2009, 20:43

Moi aussi, je préfère la 3. Parce qu'au fond, les dresseurs, on s'en fiche un peu si leurs mouvements sont saccadés ou quoi, l'important que les pokémons se déplacent en temps réél !

Kamui Shiro · Message par **Kamui Shiro** » dim. 05 juil. 2009, 13:06

Merci à tous de vos avis, j'ai enfin la solution. Il ne reste plus qu'a l'implanter, maintenant...

Ps : Pour la solution 3, il n'y a pas de saccade, juste que le joueur *pourrait* ne pas être tout à fait à la bonne position, de 2-3 pixels.

dylden28 · Message par **dylden28** » dim. 05 juil. 2009, 13:55

dsl si j'ai pas vraiment tout lu mais tu utilise quelle "langage" en code comme c, c++ (en tout cas moi j'apprent c en ce moment)

pour revenir au sujet , oui la 3 me convien aussi

Mr. Bubble · Message par **Mr. Bubble** » dim. 05 juil. 2009, 13:58

il (elle) utilise le langage python

cyberclic · Message par **cyberclic** » lun. 06 juil. 2009, 20:55

Bonjour,

Sera-t-il possible d'avoir accès au code source ?

Kamui Shiro · Message par **Kamui Shiro** » lun. 06 juil. 2009, 20:59

Hello,
Je ne sais pas encore. Quelle utilisation veux-tu en faire?

RayKable · Message par **RayKable** » lun. 06 juil. 2009, 21:02

Il veux trixher en temps reel (ok je sors)

cyberclic · Message par **cyberclic** » lun. 06 juil. 2009, 21:06

J'ai été impressionné par ta rapidité à coder un éditeur aussi performant. Je suis assez curieux de voir comment t'as fait. Rien de plus.

Nougami Neuro · Message par **Nougami Neuro** » mar. 07 juil. 2009, 18:36

Solution 3: étant donné que le nombre de joueurs va croitre, il est intéressant de ne pas saturer le serveur.

Maintenant pour ce qui est de la gestion des déplacements en combat, la solution 1 conviendrai. Maintenant faut voir si tu fais du TCP ou de l'UDP. Si c'est en TCP, il y aura un temps de décallage lors de la vérification des paquets. En UDP, il n'y a aucune vérification, ce qui diminue le temps de réaction, en négligeant l'intégrité des paquets. Il faudra donc envoyer de temps en temps des paquets "sûrs" en TCP pour mettre à jour les positions.

cyberclic · Message par **cyberclic** » mar. 07 juil. 2009, 19:27

Et surtout ne pas oublier de chiffrer le flux de donné pour éviter qu'il soit intercepté a des fins plus ou moins douteuses. Un chiffrement avec un algorithme Blowfish me semble un bon compromis entre sécurité et rapidité. Avec quelques vérifs MD5 sur certains paquets choisis aléatoirement, pour renforcer la sécurité.

Nougami Neuro · Message par **Nougami Neuro** » mar. 07 juil. 2009, 19:54

Le MD5 est un outil de hash dont l'algorythme est cassé depuis un certain temps. Le SHA1 est plus performant. A la limite coupler les deux, mais ca prendrait trop de temps.

Kamui Shiro · Message par **Kamui Shiro** » mar. 07 juil. 2009, 20:07

Je ne vois pas l'intérêt d'ajouter une sécurité sur les paquets, sauf pour le mot de passe.

Le client ne fait que de l'affichage ou des requêtes d'affichage. Si un bot envoie au serveur "Je veux le texte du npc 324", le serveur vérifiera si le joueur se trouve sur la même map et à proximité du NPC, avant d'accepter sa requête.
Si le client envoie un paquet du genre "Teleporte_moi_là", ce paquet sera simplement ignoré. Même si quelqu'un sait quelle est la structure du paquet, je ne vois pas comment il pourrait tricher.

Actuellement j'utilise TCP pour mes tests, mais dès que tout fonctionnera correctement, je passerais en UDP. Si des paquets sont perdus, je pense que ce n'est pas trop grave, puisque l'affichage sera régulièrement mis à jour.
(à vrai dire, je ne sais pas quelle est la probabilité qu'un paquet soit perdu ou abimé)

Ajouter des protection augmenterait considérablement le nombre de bit à envoyer. ça m'aiderait que vous me précisiez où cela vous semble nécessaire d'en ajouter.

PS: Désolée de pas trop donner de nouvelles, c'est pas que ça avance pas, au contraire, c'est juste que y'a rien à montrer à part des lignes de code

cyberclic · Message par **cyberclic** » mar. 07 juil. 2009, 20:55

Un flux de donnée doit-être chiffré, dès lors qu'il est dynamique ou qu'il contient des données confidentielles.

Dans ton cas, il s'agit d'un flux dynamique, qui indique différentes informations sur l'adversaire, comme sa position, son pseudo, son score, ses PV, son équipe pokémon, toutes les stats de chaque pokémon et des attaques... Il n'y pas que la position des joueurs qui transite dans les tuyaux.

Un exemple tout bête :

Je lance ton jeu et je lance un analyseur de trame en parallèle. La trame envoyée étant claire, je sais quel bit correspond à quoi.
Donc j'envoie une trame avec l'ID de l'attaque la plus puissante du jeu + des stats d'attaque et de dégât boostés à fond directement à l'adversaire.

Le client adverse va analyser ma trame pirate comme étant une trame légitime (ben ouais, après tout, c'est pas interdit d'envoyer une attaque surpuissante) et je vais faire un One Hit KO à tout les coups.

D'où l'intérêt de toujours sécuriser des données sensibles. La fraude est bien réelle.

Kamui Shiro · Message par **Kamui Shiro** » mar. 07 juil. 2009, 21:01

Un exemple tout bête :

Je lance ton jeu et je lance un analyseur de trame en parallèle. La trame envoyée étant claire, je sais quel bit correspond à quoi.
Donc j'envoie une trame avec l'ID de la taque la plus puissante du jeu + des stats d'attaque et de dégât boostés à fond directement à l'adversaire.

Le client adverse va analyser ma trame pirate comme étant une trame légitime (ben ouais, après tout, c'est pas interdit d'envoyer une attaque surpuissante) et je vais faire un One Hit KO à tout les coups.

D'où l'intérêt de toujours sécuriser des données sensibles. La fraude est bien réelle.

Ce cas est impossible, sachant que le serveur est l'intermédiaire et traite seul ce genre d'information. Voici comment cela se passe:
Joueur X veut attaquer, il en informe le serveur qui active telle attaque Si c'est possible (En gros, si ton personnage la possède, etc), et calcule le résultat.

Le serveur envoie à joueur Y que X lance telle attaque, et il lui demande d'afficher celle-ci à l'écran.

La seule chose que voit joueur Y, c'est le résultat "du calcul" qui a eu lieu coté serveur. Au mieux, la fraude pourrait être une fraude d'affichage, mais cela ne changerait rien à la réalité coté serveur.

Dis moi si je me trompe.

cyberclic · Message par **cyberclic** » mar. 07 juil. 2009, 21:32

Ok, je ne savais pas qu'on était en configuration client/serveur. Je pensais que c'était une liaison PPP (Point à Point), recommandé et indispensable si on n'a pas un voire plusieurs serveurs capables de débiter derrière. Sinon bonjour les collisions entre les paquets à cause du taux de réponse élevé (UDP impossible et TCP qui lag à mort)

Bref, cela n'empêche pas de "mal" informer le serveur afin de le gruger pour tricher.

Qu'est-ce qui m'empêche indiquer au serveur que j'ai un Dracaufeu au niveau 85 avec l'attaque "Rafale Feu" par exemple alors qu'en réalité je n'ai qu'un petit salamèche au niveau 5 avec son "Flammeche" ?

Si le serveur sait que j'ai triché, j'aimerais savoir comment ? Comment peut-t-il savoir qu'en réalité j'ai un salamèche au niveau 5 et non un Dracaufeu au niveau 85 ?