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.
