Bonjour,
C’est quoi un datapack? C’est le pack de donnée contenant les données du jeux, les ressources si vous préférez. Pour CatchChallenger, c’est les monstres, les attaques, les images, les items et leurs utilisations, les maps, …
En comparant avec certains datapacks (PWO, PokeNet, Pokemium) pour faire des outils d’importation automatique, pour faciliter le passage sur mon jeu, je me suis rendu compte des problèmes des autres datapack:
http://catchchallenger.first-world.info/wiki/CatchChallenger_vs_other
Les traductions sont dans tout les coins (en plus de pouvoir avoir des choses sans traduction et des traductions qui ne sont relié à rien). Plein d’informations sont sortie de leur contexte, soit j’ai eu du mal à comprends ce que c’été, soit j’ai simplement pas compris. C’est souvent une simple liste d’éléments dans un fichier texte (par exemple ont sais même pas à quel map c’est relié, quel monstre, bot, …). Ça veux dire que si ont supprime un ligne, ça décale tout et tout deviens faux. Pour trouver certaines info sur les map, je doit résoudre la map avec son nom, puis de sont nom vers l’info, et donc si le nom change l’info n’est plus trouvable…
Vous aller me demander, mais quel format utilise t’il? Des fois des fichiers binaires, mais bien souvent un mix de fichiers textes de différents types: texte brute avec de simple retour à la ligne, des fichiers ini et des fichiers xml. Le tout en même temps, cela oblige de lire et de programmer de différente manière, cela est typique quand les développeurs ont beaucoup changé sur un même projet. La perte de performance lié au fichiers texte n’est pas important car tout datapack devrai (coté client et serveur) être chargé en mémoire et pas analysé en temps réel.
Avec CatchChallenger, c’est que du xml. Les traductions sont juste au dessous du texte en anglais (avec un lang= »fr » dans la définition de la balise), les attaques à apprendre pour les monstres sont dans la balise du même montres. Les ids sont la pour garder en base de données des nombres simple, minimiser l’espace en db, ne pas changer les références en cas de changement de nom, faire une indexation plus efficace. J’ai vu dans les autres datapack, qu’il y avais pas mal d’info que je n’utilisais pas, comme la classe, l’habitat, … informations que j’ai rajouter dans le xml car le format le permet. Et plus tard pris en compte dans l’application. Le faite d’avoir du xml permet d’organiser les items sous formes de liste mais aussi sous forme d’arbre, ce qui est trés pratique pour les données lié.
Le format des images est assez anarchique dans les autres datapack, elle n’ont pas le même centrage (raison?), certaines avec un fond transparent, d’autre avec un fond noir ou rose, … CatchChallenger supporte le gif, png et jpeg pour s’adapter aux images les plus diverses (jpeg pour les fonds d’écran, png pour les monstres en grands et miniatures, gif pour les miniatures et attaque animé), au choix de celui qui fait le datapack. Le datapack officiel à des images sur font transparent.
L’avantage lié à ces formats comme le xml, png/jpeg/gif (même si ce n’été pas recherché), c’est qu’il sont utilisable dans un navigateur, par exemple pour afficher comme je le fait actuellement sur le site officiel, les images des items/joureurs dans les pages web. Vous pouvez donc voir la partie statique du datapack, comme les informations en temps réél de la base de donnée.
Les données que j’ai vu sont buggées dans la plus part des datapack, même les liens entre les maps. Souvent car il sont à 2 endroits et qu’il ont été mise à jour des fois d’un coté, des fois d’un autre coté. Donc j’ai du coder un minimum de contrôle pour l’importation. Par exemple les attaques, il y as juste l’information power, et pas le changements de status si besoin, cela à cause du format ini pas adapté pour ça. Le xml permet des éléments optionnel, donc pour les bot de combats, ont peu spécifier ou non les attaques des monstres, pour les montres sauvage, ont peu soit ecrire le niveau min/max avec levelMin/levelMax ou un niveau unique avec level.
Dans la db, il stocke des données statique, statiquement, je m’explique… La maximum de vie est stocker sous forme de hp, donc si le datapack change le nombre de hp, il faut adapter toutes la base de données. En plus garder quelque chose en base de donnée alors qu’on l’as dans le datapack c’est bête, ça bouffe de la place en base de données. Dans ce cas, pour minimiser la base de donnée, j’aurai fait un type text, avec comme contenu: « HP:+50;SP:-10 ». Cela permet de ne pas prendre de place quand il n’y as pas de bonus (90% du temps), et de s’adapter au contenu du datapack. Bien sur si un objet est tenu, il est mieux de calculer les bonus directement depuis l’objet, au lieux de stocker l’effet en db. Cela permet d’adapté l’effet, et de limité le nombre d’effet possible. Ensuite une bonne utilisation des types, tant coté C++ que coté db est important pour limiter la taille mémoire et disque, et les index pour obtenir rapidement les infos en gardant à l’espris qu’une db sera toujours lente (et donc avec un temps d’accès).
Le datapack de CatchChallenger est commun entre le client et le serveur. C’est le même. Cela veux dire que si des personnes essayent de m’attaquer juste pour me faire fermer ou pour essayer de me faire cracher du fric, chaque personne s’étant connecté sur un serveur précis, peu facilement remonté le même serveur avec le même contenu lui même, depuis chez lui avec se petit connexion adsl de campagne. Hors fichiers lourd (image, musique), 80% en balise, et 60% en volume sont commun entre le serveur et le client. Le serveur doit avoir la partie client pour que le client puisse télécharger le datapack pour jouer. Et la partie spécifique au serveur qui se retrouve sur le client est minime (<1%). Une grosse partie la pour pouvoir faire les calcules coté client et coté serveur. Car si c’est fait juste coté serveur, cela oblige d’avoir de RTT (round-trip delay time (RTD) or round-trip time (RTT)).
Grace à cela, je me prémuni aussi des fermetures arbitraire de mon serveur. Imaginons que X essaye de faire fermer mon serveur entier par ovh (donc avec Ultracopier, …). Juste parce-que cette personne dit que mon jeu est trop proche d’un autre. Pas grave, je peu l’héberger chez moi, chaque personne peu le reprendre en plus si besoin. Et donc mon serveur se retrouve avec juste des sites, pas le serveur de jeu, et ont peu donc rien lui reprochez. Cela permet aussi que chaqu’un dispose du datapack pour faire sont propre contenu, et donc cela ne limite pas la créativité.
Apparemment PWO, PokeNet, Pokemium, ont été codé par des amateurs (comme beaucoup de petit jeux et de jeux de fan). Sur l’implémentation c’est pas grave car ça peu facilement être changer. Par contre sur le protocole et le datapack cela est fortement handicapant. Le protocole permet une bonne réactivité, sécurité et communication. Et le datapack, d’être repris, modifié, …
Le projet avance, petit à petit. Vu que je le fait sur mon temps libre, il avance pas aussi rapidement que je le voudrai. Pour la version 0.2 beaucoup de changements ont déjà été fait. Mais le changement de moteur n’as pas toujours été fait (Qt -> Qt Quick 2 pour accélération matériel, scripting, …). La roadmap est défini, et sera surement publié pour la sortie de la version 0.4. Avec la 1.0 prévu pour fin 2014 au pire.