[Jeux libres] MMorpg

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

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