Re: Re : [Jeux libres] MMorpg

[alpha_one_x86 <alpha_one_x86 AT first-world.info>]

C'est aussi pour ça que je me lance dans la fabrication d'un mmorpg
(lib de base + modules), pour que tout le monde ai une bonne base pour
travailler, et pour faire un demo technologique (pour faire voir que
c'est possible, et comment c'est possible). En plus de pouvoir jouer à
un mmorpg sous linux.

2012/5/4  <asso.lanpower AT free.fr>:
> Bonjour,
> C'est franchement très détaillé, ça sent le vécu.
> Patrice
> ----- alpha_one_x86 <alpha_one_x86 AT first-world.info> a écrit :
>> Bonjour, voila mon retour d’expérience comme joueur/administrateur
>> système et GM de mmorpg, cet avis sera peu être déjà acquis pour la
>> plus part:
>>
>>
>> Bonjour, voila mon retour d’expérience comme joueur/administrateur
>> système et GM de mmorpg, cet avis sera peu être déjà acquis pour la
>> plus part:
>> Point gameplay:
>> - Le jeux doit être amusant en solo comme un multi, pour ne pas
>> abandonner si peu de personne viennes
>> - Juste recopier un gameplay ne sert à rien, leur joueurs irons
>> toujours à gameplay égale la ou il y a d'autre joueurs. Inovez!
>> - Avoir un datapack/rates personnalisable, histoire que chaque
>> personne y trouve sont compte (histoire spécifique, augmentation des
>> levels à un rythmes normal)
>> - Avoir des extensions de protocoles avec une bonne base, pour étendre
>> le gameplay.
>> Partie performance:
>> - Beaucoup de dev font du: multiplayer online role-playing game
>> (MORPG) pas du _Massively_ multiplayer online role-playing game
>> (_M_MORPG), il prévois pour 50 joueurs (pour eux c'est _Massively_, et
>> ce plante quand il ont plus de joueurs)
>> - Ce qui en résulte, que le petit GM qui veux ouvrir sont petit
>> serveur le ferme rapidement car tout les mois il doit claquer des
>> sommes folles en dédié (60€/mois pour avoir un machine correcte chez
>> ovh).
>> - La personne qui veux mettre sont serveur sur sa ligne ADSL ne
>> peuvent en générale pas. Car le débit est trop faible (personne ne
>> fait de compression de la connexion tcp, ni ne prévois des options
>> pour minimisé le débit), et à cause des pings. On peu pour la plus
>> part des jeux, faire des protocoles d'auto-correction des latences qui
>> permette d'évité que les pings n'ont trop d'importance. Pourtant
>> héberger chez soit, ou sur un trés petit hébergement est très utile
>> pour démarrer.
>> - Calcule de complexité, rare sont ceux qui le font, cela ce pose
>> surtout sur les joueurs qui ce vois mutuellement, c'est en générale:
>> bande passant + cpu = nombre de joueur qui ce vois mutuellement ^ 2
>>
>> Lié avec le point au dessus, les performances:
>> - Tout le monde se dit: ont verra après pour les performances, hors
>> une fois que tu as 1000 personnes en ligne et un serveur/client
>> complet, personne n'as le courage de le refaire, surtout si il est
>> crade. Résultat, tout le monde ralle car sa rame.
>>
>> Les pc ont une puissance qui augmente exponentiellement, et le serveur
>> sont exponentiellement plus lent (ce qui fait que depuis des années le
>> nombres moyen max de joueurs reste fixe). Idiot vous direz. La plus
>> part des serveur ne support que <70 joueurs visible mutuellement, et
>> 1000 connectés. Ce qui est très petit (j'ai fait sans problème 500
>> visibles et 100 000 connectés).
>>
>> Pour un petit nombre de joueur (<20), un simple mono coeur atom/arm,
>> quelque centaine de mega de mémoire, et une connexion adsl doivent
>> suffire, et pour les larges échelles (>10 000), un bon serveur (quad
>> core, 8Go de mémoire, 1000Mbps) doit aussi suffire.
>> J'ai déjà vu:
>> - L'utilisation que tout les coeurs en multi-thread avec tellement de
>> mutex qui ce gène mutuellement. Cela fessait des temps système de fou
>> car sur certain cpu il n'y as pas d'optimisation hardware des mutex.
>> Et qu'un seul cpu été utilisé en gros au final. (Je parle de l2jfree
>> comparé au serveur propriétaire).
>> - Des serveur qui prenne 10% du cpu à vide sans aucun
>> joueurs...(minecraft, l2jfree, ...), soit des fois c'est utile (timer
>> et autre), mais pas avec 10% du cpu!
>> - Blockage, les joueurs s'en fiches que vous utilisé vos 56 coeurs si
>> ça rame, il veulent que ça ne rame jamais. Le plus efficace est donc
>> de travaillé en event, d'isoler les complexité exponentielle et les
>> accés db/disk dans un thread. Idem pour les parties lente. Dans le
>> multi-thread avec event, essayer de libéré les boucle d'event+thread
>> critique d'un maximum de chose pour gagner en latence.
>> - Ne sauvegarder pas en continu dans la base de données, faites le à
>> la déconnexion des joueurs, et pour les données continues (tel que les
>> déplacements), à intervalle régulier. Bien sur, les truc ponctuels
>> peuvent être backupé en instantané (mais dans un thread à part).
>>
>> Donc pour tout le monde (hébergeur, celui qui paye le dédié, les
>> joueurs avec compte payant pour payer le dédié), il est indispensable
>> de soigner certain point tel que les performances, le protocole (ça
>> permet aussi de faire d'autres implémentations), la sécurité, la
>> prévention de bug (personne n'aime quand tout le serveur crash, et ça
>> re-roll avec les données d'il y as 1h).
>> Je ne conseille à personne de faire le noob et de se lancer dans un
>> jeux sans avoir déjà une bonne expérience en programmation (et avec un
>> projet claire et réaliste). Les joueurs font partie des utilisateurs
>> les plus exigeants, et ce segment est la ou il y as le plus de
>> concurrence. Ca se traduit par déjà un gros projet grand publique ou
>> une solide motivation + ont vas y jouer même tout seul.
>>
>> Les graphismes (je ne suis pas graphiste, mais j'ai quand même un peu
>> d'expérience, manga, pixel art):
>> - Il ne faut pas les bâcler, car comme moi, beaucoup de joueurs
>> regarde ça pour trier les bon jeux des petits jeux de merde. Donc trés
>> important pour avoir des nouveaux joueurs, bien plus que pour les
>> logiciels. Il vaut mieux en avoir peu et bien, que beaucoup et mal.
>> (J'aime bien mars space shooter pour ça)
>> - Les graphismes personnalisable dans le datapack sont important.
>>
>> Les fonctionnalités des bases importantes:
>> - Toujours prévoir l'envoie du pass en hash (sécurité), beaucoup
>> utilise le même passe partout (dons les visites qu'il visites)
>> - L'update du datapack (voir client) dans le protocole, c'est assez
>> crade d'avoir un updater à coté de sont jeux
>> - Datapack par serveur, pour avoir des données par serveur, et loader
>> soit en fixe (pour les données les - dynamiques) soit à chaud (pour
>> les données les + dynamiques). Important pour la concurrence et
>> minimisé les données transmises, et ne pas charger tout le temps des
>> choses.
>> - Définir de le nombre max de joueurs en ligne, et en db (définir sur
>> 16Bits, 32Bits ou 64bits), et bien proportionner/optimiser son
>> serveur/client.
>> - Ne pas exclure de joueurs (multi-platforme, ou au moins support sous
>> wine). C'est toujours frustrant (surtout quand ont à acheter le jeux),
>> de passer sous windows pour jouer (ou d'être privé du jeux si ont as
>> pas windows ;) ).
>>
>> - Visibilité correcte, faite en sorte que le joueur vois toujours une
>> proportion correcte de l'écran (zoom adaptatif, ...). Quitte à réduire
>> la distance de visibilité si le nombre de joueur est trop grands. Et a
>> ne rien afficher si les calcules a faire sont exagéré (le joueurs
>> préfère ne rien voir, que de tout voir et que ça lag tellement qu'il
>> ne peu pas jouer). N'oubliez pas de mettre des hystérésis pour éviter
>> de lag/prendre trop de bande passante prêt de la limite du serveur.
>>
>> Voila mon avis, dites moi ce que vous en penser.
>>
>>
>> --
>> alpha_one_x86 <alpha_one_x86 AT first-world.info>
>> Main developer of Ultracopier, Esourcing and server management
>> IT, OS, technologies, security and business department
>



-- 
alpha_one_x86 <alpha_one_x86 AT first-world.info>
Main developer of Ultracopier, Esourcing and server management
IT, OS, technologies, security and business department