Passage sur NSIS et Qt5

Bonjour,
J’utiliser Inno setup 5, mais j’ai découvert qu’il avais des problèmes de multi-thread et de variable non initialisé. Wine m’as permit de mettre en évidence le probléme, windows ne gérant pas les thread de la même façon, je problème est plus difficile à faire apparaître. Ont m’as dit que c’été pas leur probléme car wine n’est pas une platforme supporté (il ont pas envie de faire du code propre, solide, qui passe partout quelque soit la manière de géré les threads. Il vont être bloquer si un jour windows change ce code).
Donc me voila avec NSIS pour ultracopier, qui marche parfaitement sous wine en console pur. En passant, Inno setup 5 ne marche pas en console pur, il crée des fenêtres caché qui font planté certain partie du programme quand je le lance en console pur.

J’ai fait le tour d’ultracopier avec Qt5. Voila rapidement ce que je me suis noter:
– Mac: Le menu quand ont click droit sur l’icone dans le systray n’apparaît pas totalement. Certain signals/slots sont bugger/manquant. Le dialogue pour obtenir un fichier ne marche pas (ont peu pas le fermer, ni click sur open/close)

– Linux: RAS, tout semble marché

– Windows: Grosse lenteur pour le dialogue pour sélectionner les fichiers, Mingw64 en 32Bits à un bug à cause de gcc 4.7.2 (suppression de -02 obligatoire pour mettre -m32), et un plugins (le moteur de copie) ne marche pas en 32Bits, il ne ce charge pas, et Qt5 ne me remonte pas l’erreur

Je continue à avancé sur pokecraft, il commence à étre jouable (crafting, farming, pas encore de combat, ni d’histoire, ni de map)

Bye

Création de mmorpg

Bonjour, voilà mon retour d’expérience comme joueur/administrateur système et GM de mmorpg, cet avis sera peut-être déjà acquis pour la plus part:
Point gameplay:
– Le jeu doit être amusant en solo comme un multi, pour ne pas abandonner si peu de personnes viennent
Seulement recopier un gameplay ne sert à rien, leurs joueurs irons toujours à gameplay égale là où il y a d’autres joueurs. Inovez!
Avoir un datapack/rates personnalisable, histoire que chaque personne y trouve son compte (histoire spécifique, augmentation des levels à son rythmes)
– 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évoit pour 50 joueurs (pour eux c’est _Massively_, et se plante quand ils ont plus de joueurs)
– Ce qui en résulte, que le petit GM qui veut ouvrir son petit serveur le ferme rapidement car tous les mois il doit claquer des sommes folles en dédié (60€/mois pour avoir une machine correcte chez ovh).
– La personne qui veut mettre son serveur sur sa ligne ADSL ne peuvent en général 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 peut pour la plupart des jeux, faire des protocoles d’auto-correction des latences qui permettent d’éviter 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 se vois mutuellement, c’est en général: bande passant + cpu = nombre de joueur qui se vois mutuellement ^ 2

– Tout le monde se dit: on verra après pour les performances, hors une fois que tu as 1000 personnes en ligne et un serveur/client complet, personne n’a 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 nombre général maximum de joueurs reste fixe). Idiot vous direz. La plupart des serveurs ne supportent que <70 joueurs visibles 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, 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 de tous les coeurs en multi-thread avec tellement de mutex qui se gène mutuellement. Cela fait des temps système énorme car sur certain cpu il n’y a pas d’optimisation hardware des mutex. Et qu’un seul cpu était utilisé en gros au final. (Je parle de l2jfree comparé au serveur propriétaire).
– Des serveur qui prennent 10% du cpu à vide sans aucun joueur…(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 utilisez vos 56 coeurs si ça rame, ils veulent que ça ne rame jamais. Le plus efficace est donc de travailler en event, d’isoler les complexités exponentielles et les accés db/disk dans un thread. Idem pour les parties lentes. Dans le multi-thread avec event, essayer de libérer les boucles d’event+thread critique d’un maximum de choses pour gagner en latence.
– Ne sauvegardez pas en continu dans la base de données, faites le à la déconnexion des joueurs, pour les données continues (tel que les déplacements), à intervalle régulier. Bien sûr, les choses 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 jeu sans avoir déjà une bonne expérience en programmation (et avec un projet clair et réaliste). Les joueurs font partie des utilisateurs les plus exigeants et ce segment est là où il y a le plus de concurrence. Cela se traduit par déjà un grand projet public ou une solide motivation + 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 regardent ça pour trier les bons jeux des petits jeux de merde. Donc très important pour avoir de 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 personnalisables dans le datapack sont importants.

 

 

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 à côté de son jeu
– Datapack par serveur, pour avoir des données par serveur et charger soit en fixe (pour les données les – dynamiques) soit à chaud (pour les données les + dynamiques). Important pour la concurrence et minimiser les données transmises et ne pas charger tout le temps les données dynamiques identiques (ratio read/write correcte pour la partie dynamique).
– Définir 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 on a acheté le jeu), de passer sous windows pour jouer (ou d’être privé du jeu si on a pas windows 😉 ).

– Visibilité correcte, faite en sorte que le joueur voit toujours une proportion correcte de l’écran (zoom adaptatif, …). Quitte à réduire la distance de visibilité si le nombre de joueur est trop grand. Et à ne rien afficher si les calcules à faire sont exagérés (le joueurs préfèrent ne rien voir, que de tout voir et que ça lag tellement qu’ils ne peuvent pas jouer). N’oubliez pas de mettre des hystérésis pour éviter de lag/prendre trop de bande passante près de la limite du serveur.

Pokecraft

Début du projet pokecraft, qui est à la fois un jeu et un mmorpg.

Déjà dés le debut il fait à certain endroit 10x à 100x plus rapide que les autres jeux, il as un protocol asyncrone qui lui permet de ne jamais être ralenti par les lentences (internet ou serveur). Il permet aussi de viré toutes les communications qui ce base sur l’aléatoire, et il as une très petite empreinte mémoire/cpu/réseau.

Il est basé sur Qt, et sur les events. Le serveur sépare chaque groupe de tache dans un thread pour ne pas faire ramer les autres groupe de taches (une lenteur du chat ne ralenti pas le calcule des maps et inversement)

Coté gameplay c’est un mix pokemon pour le RPG, tour par tour, lineage pour le mmorpg, X3 pour le commerce et la production de bien, et minecraft pour le crafting.

Le client temporaire est fait avec QGV, mais il vas étre refait en QML2. Le server vas être refait en Qt5.

J’en profite pour soufler un peu d’ultracopier, j’ai pas mal bosser dessus, et je reprendrai quand j’en aurai marre de pokecraft. Et ça me permettra de jouer/mapper/dessiner un peu quand le client marchera.