Map chunk et déplacement

Les maps modernes se charge par parties, cela permet d’éviter de charger des ressources en mémoire inutilement et donc de fluidifier le jeu pour en améliorer l’expérience. Chaque morceau de map (ou Map chunk en anglais) est en générale une section de taille fixe dans le cas de génération procédurale typiquement.

Cela ajoute des difficultés de gestion dans le code. Les détections de collision doivent être multi-map. Les éléments pouvant circuler d’une map a l’autre doivent être déchargé d’une map puis chargé dans l’autre.

En UDP des données de déplacement sont non continue, en TCP elle peuvent être continue ou non. Pour le client side prediction, donc que l’autre joueur continue sur sa lancée ou son mouvement en cour, il faut donc transformer cette chaine de point/direction typiquement en un movement, pour ne pas alourdir les calcules dans CatchChallenger je n’utilise pas de pathfinding a ce niveau (et donc je m’évite DDOS coté client et surcharge).

Voila comment un jeux moderne fonctionne, 2D ou 3D. Bye

Path finding du plus droits chemin

Bonjour,

Je viens de finir une version préliminaire du path finding pour le plus droits chemin.
Mais pourquoi le plus droits et non pas le plus court?
  • Car cela permet de minimiser le volume réseau
  • Minimiser le changement de contexte coté OS à cause de multiple trame réseau
  • Minimiser le changement de contexte coté application car il doit géré un client, puis un autre, puis revenir sur le 1er
C’est loin d’être optimal coté implémentation (ont ne peu pas changer de map, intérragir avec les objets, …), mais c’est fait. C’est assez complexe car il y as 4 informations par tile, au lieux de une dans un path finding avec le plus cour chemin.
Cela permettra de reduire les couts de fonctionnement du projet.
1er post fait avec blogilo car chrome bug pour les accents depuis quelques versions.
Bye,

 

Path finding coté serveur et split via plugin

Bonjour,

Le path finding est une technique pour résoudre un chemin entre 2 points, et savoir si ont peu aller de l’un à l’autre. Cette technique est assez lourde, et peu consommer énormément de ressources pour des maps assez grande.

Pourquoi ne pas le faire coté serveur? Car comme dit précédemment les ressources cotés serveur sont précieuse, et ceux même en limitant la taille du path finding. Mais alors comment faire? Vous devez normalement ne pas résoudre les collisions en temps réel (car plein d’exception à une simple couche collision), et donc avoir un tableau de true/false représentant les tiles où vous pouvez marcher. Maintenant vous transformez cela en entier (int ou autre type qui peu contenir le nombre de tile max de votre map sur 2), et vous résolvez par zone. C’est à dire que 2 tiles l’un à coté de l’autre où l’ont peu marché sont dans la même zone. Si le point A et B sont dans la même zone, c’est qu’il y as un chemain entre les 2. Un tile isolé n’est pas une zone où l’ont peu marcher: Si ont est dessus, le changement d’orientation ne change pas la position (donc pas de contrôle si c’est marchable).

Coté transmissions de données, vous faites aux choix:

  • vous transmettez aux clients le point de destination d’un joueur, et c’est lui qui fait la résolution
  • Ou chaque joueur transmet les vecteurs de déplacement décomposé

La petite difficulté c’est le passage de zone, je m’explique: les passages qui font que l’ont peu passer que d’une zone à l’autre et pas l’inverse (c’est pour ça que ce n’est pas une zone unique). Ou encore si votre map est continue mais découpé en chunk (comme ma map en extérieur), vous devez valider que les 2 zone marchable des 2 maps sont bien en contact (et plus généralement boucler pour voir si la zone source et la destination sont bien en contacte, qui à dit path finding?).

Voila qui vous donnera ont grosse optimisation de votre serveur.

Certain m’ont suggéré de mettre la partie commune entre mon client et mon serveur en plugin, et peu être aussi le serveur pour les fois ou il est intégré au client (pour la version solo). Et en regardant « Mega drivers » pour mesa, j’ai la même conclusion. Faire du dynamique c’est bien car ça permet d’externaliser les parties communes pour les maj et les corrections. Mais ça freine l’évolution, dans le sens qu’il ne faut pas changer tout le temps les symboles (fonctions/méthodes) exportées. Certain ont décidé de ne jamais mettre à jour (pour garder la retro compatibilité des vieux programmes), d’autre ont des cycles de mise à jour. Pour Ultracopier les interfaces sont stables (peu de changement, et mineur), et vu que peu (actuellement pas) de plugins fait par d’autre, alors les changements sont fait à chaque versions majeures. Mais pour CatchChallenger, vu que je ne sais pas vraiment la forme définitive, et que la lib commune change tout le temps (je rajoute/supprime tout le temps des fonctions). J’ai décidé de mettre tout en statique, cela ne freinera pas l’évolution, et permettra une meilleur optimisation LTO. Cela permet de mieux compresser par upx, et aussi de faire moins de contrôle (car les info/arguments ne viennes pas de l’extérieur).

En espérant vous avoir éclairé, bye.