Exécuter les scripts "relativement lourd" sur le pc client ou serveur?

[Hideaki]

IDA* était un exemple, il y a aussi SMA* qui peut être bien, la lecture du pseudo code devrait être suffisant à sa compréhension donc pas besoin d'un anglais non informatique

[popayan]

Ce n'est qu'un calcul de chemin? Je ne vois pas ou serais la faille?

Imaginons que ton chemin soit une succession de case, si je "modifie" ton javascript pour retirer certaines cases de mon chemin, je raccourcis alors le temps de trajet... Enfin tout ca n'est que supposition

[Maz]

Effectivement sans vérification côté serveur... Enfin bon, je finis mon A* côté serveur. De sur j'en aurais besoin, ensuite je verrais pour le JS si je peut faire quelquechose d'agréable en plus pour le joueur.

[Sephi-Chan]

Tu dois de toute façon faire le calcul des 2 côtés. Côté client pour que ce soit sympa pour l'utilisateur, puis côté serveur pour vérifier que le déplacement est bien possible.

Après, tu peux mémoriser les chemins (généralement dans un système de stockage par clé/valeur en RAM genre Memcache ou Redis). Exemple :

paris = City.find_by_name("Paris")

nimes = City.find_by_name("Nîmes")



key   = [ "path", paris, nimes ]

path  = Rails.cache.fetch(key) { paris.path_to(nimes) }

Si la clé n'existe pas, on exécute le code fourni dans le block et on le range dans le cache.

Après, tu peux peut-être transmettre les chemins précalculés à Javascript en les passant sous forme d'un objet JSON. Ça lui évitera le calcul dans bien des cas et ça finira d'ailleurs par couvrir 100% des calculs si ta map ne change pas.

[Hideaki]

Le coût de déplacement ne peut pas être inférieur au meilleur coût estimé par ton heuristique, d'autre part ton joueur avançant 1 case (voir +) toutes les n minutes ( définit par cron ), celui-ci ne pourra pas se déplacer plus que le maximum que tu auras défini, il n'est donc pas possible, si tu ajoutes de tel vérification, il est impossible de tricher

[Maz]

Tu dois de toute façon faire le calcul des 2 côtés. Côté client pour que ce soit sympa pour l'utilisateur, puis côté serveur pour vérifier que le déplacement est bien possible.
[...]

Ui ui Sephi-Chan, j'avais lu ton message déjà. Mais on a fait des tir croisés et ton message était tellement plein de bon sens que ça méritais même pas que j'édite pour le mentionner ^^

[Hideaki]

@Sephi-chan: le stocker en RAM cela a un intérêt uniquement si il y a peu de joueur ou déplacement, sinon cela va devenir un gouffre à mémoire, si ton hébergement est mutualisé cela risque d'être funny

[Sephi-Chan]

@Sephi-chan: le stocker en RAM cela a un intérêt uniquement si il y a peu de joueur ou déplacement, sinon cela va devenir un gouffre à mémoire, si ton hébergement est mutualisé cela risque d'être funny

On parle de scalabilité : ça implique donc une certaine quantité d'utilisateurs. On n'est déjà plus dans le contexte d'un hébergement mutualisé.

Et au contraire, plus tu as de joueurs, plus l'économie d'échelle est conséquente en stockant les chemins en RAM puisque le plus court chemin pour rallier Paris et Nîmes est le même pour tous, donc ce chemin ne sera calculé qu'une fois et récupéré en RAM le reste du temps.

Cette économie d'échelle reste valable avec un un petit nombre de variantes (exemple : Paris - Nîmes en train, en avion ou en voiture). En revanche, l'astuce ne marcherait pas si le plus court chemin était variable ou soumis a trop de changements (exemple : on ne peut emprunter que les routes possédés par notre faction).

Je rajouterai 3 choses :

• La RAM, c'est fait pour être utilisé. Ça ne sert à rien d'avoir des MO de libre et ça ne consomme pas plus de courant d'y stocker des choses ;
  
• Le scripts (PHP, Ruby, peu importe) qui calcule a une durée de vie très limitée (quelques secondes, tout au plus). Il peut donc se permettre d'utiliser un peu de RAM.
  
• Idem pour le navigateur du client ;
  

[Hideaki]

Désolé je n'avais pas tout lu, quand il y a du php ou ruby j'ai une tendance à zapper la partie code.

Effectivement cela reste valable si le parcours est stable, que les règles sont identiques pour chaque joueur et que la taille de la grille de jeu ne soit pas trop importante, ni variable.
Il me semblait que la grille était extensible par rapport au nombre de joueur, j'ai du confondre avec un sujet traitant lui aussi de grille d'un auteur différent.

S'il s'agit de point fixe à l'instar d'une ville, pourquoi ne pas générer l'ensemble des possibilités au lancement du serveur avec une sérialisation de l'objet map.

[Maz]

Désolé je n'avais pas tout lu, quand il y a du php ou ruby j'ai une tendance à zapper la partie code.

Effectivement cela reste valable si le parcours est stable, que les règles sont identiques pour chaque joueur et que la taille de la grille de jeu ne soit pas trop importante, ni variable.
Il me semblait que la grille était extensible par rapport au nombre de joueur, j'ai du confondre avec un sujet traitant lui aussi de grille d'un auteur différent.

S'il s'agit de point fixe à l'instar d'une ville, pourquoi ne pas générer l'ensemble des possibilités au lancement du serveur avec une sérialisation de l'objet map.

Tu n'as pas confondu, c'est bien moi qui parlais de grille extensible (infini à vrai dire). Et dans mon cas, calculer l'ensemble des possibilités est impensable, car la carte n'est pas fini... par définition d'infini ^^'.

En fait les chemin que j'ai à géré ne sont pas entre deux point "fixe". Plus précisément ce script va permettre de calculer les chemins des "chasses". Le point de départ seras forcément la ville du joueur. Mais les autres point seront: défini par le joueur et je calcul tous les point intermédiaire. Par exemple:

Ville du joueur: 4,18
Case à visité: 5, 20
Case à visité²: 7,25

Je dois donc calculer le chemin le plus court pour aller du point 4,18 au point 5,20, puis du point 5,20 au point 7,25, et ensuite pour le retour du point 7,25 au point 4,18.

Je dois pouvoir récupéré le chemin "point par point", du genre pour 4,18 > 5,20: 4,18 > 4,19, 5,19 > 5,20
Ceci afin de déplacer le groupe de fourmis case par case sans avoir à recalculer à chaque fois le chemin le plus court à chaque exécution du crons.

Donc un stockage "à long terme" n'est pas envisageable, mais une mise en mémoire pour par exemple passer toute les chasse en cours au Javascript pour pouvoir montrer au joueur où sont "en théorie" ses fourmis dans ses différentes chasses actuellement. Mais pour parler plus spécifiquement.

Vaut-il mieux passer par une mise en cache mémoire ou beaucoup plus simplement en affichant les chemins dans des input hidden que je récupère via Javascript ou même passer pa JSON(que j'utilises très rarement...)?