[Résolu] Ajax limité ou bug ?

[guile]

Ah! Bravo naholyr!
Tu as mis le doigt sur quelque chose d'intéressant.
On a d'un côté un cahier des charges particulier, de l'autre de contraintes technique.
Au bout du compte, on se retrouve avec un problème technique, auquel on veut ajouter des machins, des bidules, tout en accusant les contraintes techniques.
Mais en fait, c'est la conception technique de base qui n'était pas adaptée aux contraintes.
On avait alors comme solution de contraindre l'utilisateur, parce que conceptuellement on ne faisait pas le bon choix.

[Ter Rowan]

moi ce qui me gène, c'est qu on parle d'abord de contraintes techniques


on parle d'ajax là... d' asynchrone

si c'est asynchrone c'est que ce n'est pas synchrone, c'est qu on ne sait pas le temps que ca va mettre

alors on peut espérer que ce soit tellement rapide que cela ressemble à du "temps réel" mais ce n'est pas le cas

c'est un choix technologique qui dans un deuxième temps a des contraintes

"suffit" de changer de choix ou de s'adapter aux contraintes

on a vu diverses solutions, y en a encore une autre qui me vient à l'esprit :

avoir en "mémoire" deux ou trois coups d'avance, ainsi si je clique deux fois très vite sur gauche, la gestion est javascript, la carte se déplace deux fois à gauche avec une demande ajax qui demandera les infos pour des zones encore non visibles du personnage (et donc qui pourront arriver un peu plus tard, (d'où l'intérêt de l'asynchrone, charger quand on n en a pas encore besoin). maintenant à voir, c'est aussi favoriser celui qui a firebug que de charger les zones non visibles ^^

bref je reojoins guile, c'est plus un problème de conception qu'autre chose

[Argorate]

En même temps, si tu passais la destination en paramètre, et pas une direction, le double clic n'aurait aucun impact...

C'est tout simplement impossible puisque les coordonnées sont cachées volontairement aux joueurs et ne doivent pas leur etre revelé!

De plus ça me fait une vérif en moins coté serveur a faire...

[guile]

Tout d'abord, rien n'est impossible, il suffit de s'en donner les moyens.

Ensuite, vouloir enlever une vérification côté serveur c'est exactement à l'inverse de ma vision des choses (qui est "Ne jamais faire confiance à ce qu'on reçoit de l'utilisateur").

Il reste que ta conception initiale n'est pas compatible avec le mode "asynchrone" de l'Ajax, et doit être revue, ou bien tu vas mettre en place une usine à gaz désagréable à l'utilisateur, en prétextant un problème technique que tu t'es toi-même imposé sans raison valable.

Pour lancer un petit troll par ici, je peux même dire que ta méthode est typiquement française : on fait un truc qui "marchouille", qui est inutilement compliqué, et en plus on en trouve des justifications.

Bref, tout ça pour dire qu'il ne faut pas s'enfermer dans des situations où il suffit, pour s'en sortir, de repenser le problème à la base.

[Sephi-Chan]

C'est vrai que tu te mets dans la merde tout seul. :heuuu:

En même temps, si tu passais la destination en paramètre, et pas une direction, le double clic n'aurait aucun impact...

C'est tout simplement impossible puisque les coordonnées sont cachées volontairement aux joueurs et ne doivent pas leur etre revelé!

De plus ça me fait une vérif en moins coté serveur a faire...

Le serveur est là pour ça. Il contrôle si ce qu'on lui dit de faire est valide ou non.

Ensuite, si les coordonnées doivent être cachées, ça n'est pas un problème. Tu n'as qu'à associer à chaque case une chaîne arbitraire (avec uniqid ou avec un hash de l'ID de ta case (avec salt secret et constant), par exemple). Ainsi, dans ton Javascript, tu auras une instruction genre goTo('Aezetgt38754323Fzerjzoeazeercqwjn'); plutôt que goTo(14, 18);

Voilà, voilà, good luck !


Sephi-Chan

[Argorate]

Guile : Un bon programmeur c'est celui qui ne fait pas des choses inutile

Contrôler pour contrôler est sans intérêt pour moi. Et je pense que tu parles de mon projets/codes sans savoir, donc ton jugement étant privé d'élément solide (ou non puisque tu ne sais rien), je ne les retiendrais pas si tu ne m'en veux pas

Sephi: j'avais exactement ce système de chaine "coder" avant.
Personnellement c'est plus du "bidouillage" qu'une réelle solution pour moi ^^
En plus c'est risqué car cela peut être décodé par l'utilisateur.
Sans compter la perte de temps de traitement du au codage/décodage, j'ai donc optimisé depuis longtemps déjà ce système, je ne vais pas revenir en arrière sur ce point.

Après comme je l'ai dit, la direction a un gros avantage sur la destination:
-une vérif. en moins à faire <=> optimisation du traitement car gain de temps sans perdre la sécurité.
-puis une raison propre a mon jeu qui est (je radote, je sais) l'absence des coordonnées de manière global.

[Sephi-Chan]

Je ne vois pas comment tu peux ne pas avoir de coordonnées alors que tu arrives à identifier des directions. Si tu peux dire que A est au nord de B, c'est bien que tu as des coordonnées (de quelque forme que ce soit).

Tu dois bien te rendre compte que tu es emmerdé par ton propre système ? Les gens t'ont expliqué en quoi ton approche n'était pas bonne, que tu n'allais faire qu'une bidouille pour éviter ton problème plutôt que de le régler de manière saine.

Ça n'est pas Ajax qui est limité ou qui bug, c'est soit ton système qui est mal pensé, soit le choix technologique d'Ajax qui n'est pas le bon.

Ce que je te propose n'est pas une chaîne codée. J'ai pourtant bien précisé arbitraire. Aucun souci de fiabilité/sécurité, donc. Puisque tu peux (et doit) toujours vérifier côté serveur que la case demandée est bien accessible au personnage.

Il s'agit juste d'associer une chaîne à une case, et ainsi, la personne — même en lisant le code ou autre — ne saura pas où il va. Et donc, au lieu de demander à MySQL la case qui a telle valeur pour X et telle valeur pour Y, tu demandes la case qui a telle chaîne comme chaîne arbitraire.

Dans ton cas, après l'appel au serveur, tu dois récupérer la position actuelle du joueur puis déterminer la case qui est dans la direction demandée.

Avec ma proposition, tu dois récupérer la position actuelle du joueur et la position demandée et vérifier que la position demandée est bien accessible. Il y a peut-être un peu plus de travail algorithmique (encore que… Il faudrait voir comment tu fais actuellement) mais la requête se fait sur une colonne indexé (la chaîne arbitraire).
Et avec cette solution, pas besoin de développer une béquille anti-ergonomique pour Ajax.

Penses-tu vraiment y perdre ?


Sephi-Chan

[Argorate]

J'ai un systeme de coordonée évidament, mais il ne doit pas etre possible au joueur de les connaitres. Donc je ne passe nul part des données relative aux coordonnées.

J'avais exactement le système que tu décris, avant. Mais je ne pense pas que ce soit le mieux.
Pour ce qui est d'AJAX, pour l'instant je suis revenue sur un système classique plus stable concernant la map.
Je pense qu'il faut que j'arrete de vouloir tout améliorer alors que l code "de base" pourait encore évolué par la suite.
Je vais finir une version 1.0 et je pourait envisager apres de passer a l'ajax en m'y prennant avec d'avantages de reflection.

[Sephi-Chan]

J'ai un systeme de coordonée évidament, mais il ne doit pas etre possible au joueur de les connaitres. Donc je ne passe nul part des données relative aux coordonnées.

Et qu'est-ce qui ne va pas avec un identifiant arbitraire ?

J'avais exactement le système que tu décris, avant. Mais je ne pense pas que ce soit le mieux.

Pourquoi ?

Désolé mais ton entêtement (ça n'est pas méchant, hein) à ne faire que contourner ton problème m'intrigue vraiment.


Sephi-Chan

[naholyr]

Par contre j'ai une interrogation : pourquoi vouloir à tous prix rendre cette information totalement invisible ? Après tout les coordonnées on en utilise depuis la nuit des temps, ce n'est pas quelque chose de "technologique" ou de "moderne" qui n'aurait pas sa place dans un jeu méd-fan (si c'est ta motivation).

Mais soit, ça ne se discute pas !

En revanche effectivement ton système n'est pas compatible avec un mode asynchrone. Tu as donc deux choix :
- Travailler en mode synchrone
- Changer ton système

Ajouter un flag et autres choses compliques ne servira qu'à simuler le mode synchrone, donc pourquoi ne pas tout simplement désactiver le mode asynchrone de XmlHttpRequest... Cela simplifie grandement les traitements, et dans ton cas à mon avis tu n'as tout simplement pas le choix si tu ne souhaites pas travailler par ciblage absolu.