[Résolu] Ajax limité ou bug ?

[Ter Rowan]

perso, je peux comprendre qu'on ne veuille pas afficher le moindre "id" d'une position pour des raisons de gameplay

avoir un id c'est permettre aux joueurs de l'utiliser, de géolocaliser surement une position

vaut il mieux
"rendez vous en ag35fdf3535 demain on s'y retrouvera pour la suite du plan"
ou
"rendez vous au sud de la forêt de tsointsoin, près du lac où on s'est déjà croisé"

alors pour certains jeux c'est un plus, un game play plus "rapide", "efficace", pour certains types de joueurs

dans d'autres c'est un moins, car très vite on se retrouve avec une ambiance pas forcément voulu, parler d'id au lieu de "rp"

à mon sens, il n'y a pas de vérité absolue sur l'identification (qu'elle soit logique ou aléatoire) d'un lieu, si ce n'est que, si id il y a, alors l'id sera utilisé (car plus facile, plus rapide, plus sûr)

si on veut un jeu où se sont les joueurs qui définissent leur cartographie, leurs points de repère, alors il vaut mieux ne pas mettre d'id

voili voilou

[Argorate]

Sephi-Chan: Je ne comprends pas ^^ c'est simple, bien que je ne les écrit nul part réellement, considère que c'est dans mon cahier des charges: pas de coordonnées.

naholyr: pour comprendre le pourquoi, il y a plusieurs raisons. Ter Rowan en donne une: il ne faut de quelque maniere qu'il soit que les joueurs puissent se donner rdv a une case (de toute façon au moyen âge on n’a pas la technologie pour être assez précis pour parler en "case"), mais plutôt a un lieu!

Ensuite, la map dans sa totalité n'étant pas connue, et la position géographique du continent de départ sur la surface de la planète n'étant également pas révélé - de manière volontaire - travailler avec les coordonnées fournirait beaucoup trop de renseignement, donc c'est exclut.

[guile]

Ce que Sephi-Chan proposait est un gestion des identifiants des destinations avec un pseudo cryptage tout bête :
- on ne voit pas un id, mais un hash (uniqid?). Déjà, c'est humainement compliqué à utiliser. Pour la machine, c'est quasi transparent (un tableau associatif hash => destination).
- à chaque fois qu'un perso se déplace, ses destinations sont recryptées.
- le cryptage (uniqid) est unique d'un perso à l'autre, d'une position à l'autre. Echanger son "a4fe3214d2" avec son voisin reviendrait à lui donner ... un code incompréhensible.
- l'implication dans le RP est quasi nulle : je n'imagine même pas des joueurs fouiller dans les sources pour s'y retrouver.
- la triche (car pour moi, c'est l'unique problème) est avec cette solution quasi impossible. Un contrôle du hash présent dans le tableau est léger côté serveur (un tout petit contrôle qui permet d'éviter tout soucis). La possibilité de "décrypter" les hash possible de direction est quasi nulle également (ou alors il faut déployer des efforts technique et humains bien plus important que l'enjeu ..."ouai! Je triche à badaboum on-line, je suis trop trop bon en hacker ohohoh! Et ça seulement en 15 jours!).

Tout ça pour dire qu'il faut se poser les bonnes questions et les bons objectifs : pourquoi ne pas donner les coordonnées aux joueurs?
- pour éviter la triche, les contrôles côté serveurs sont indispensables
- pour éviter l'abus HRP de ces informations : ne pas les afficher dans la page est déjà un bon filtre (coordonnées seulement dans les sources), et en plus en les hashant ça devient rédhibitoire pour le hardcore gamer.
- pour le défi technique? Bah avec les deux trucs au dessus, le défi technique est atteint.
- parce que! Ah bin alors là, rien à dire... :-D

[Argorate]

Oui, j'avais bien comprit^^

Je pense qu'il faut arrêter de tourner en rond.
J'avais ce système, mais ce n'est plus celui qui me correspond a présent, cela sert a rien d'y revenir dessus, c'est parler pour rien dire.

La véritable raison est donc celle que j'ai dite précédemment. Je ne veux pas qu'on est une idée de la taille réel de la map ni la position relative du perso sur celle-ci, point.

[Anthor]

C'est pas un problème d'ajax, ça marcherait bien mieux, si tu appelais la fonction suivante à la fin de ton appel ajax, et pas 3 fonctions les unes à la suite des autres.

Tu fait cela :

Code PHP :

<?php 

function alert1()

{

    setTimeout(function(){

        alert('alert1');

    }, 500);

}



function alert2()

{

    alert('alert2');

}



alert1();

alert2(); 

[guile]

Pour revenir sur une chose qui m'avait personnellement choqué.

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.

http://net.tutsplus.com/tutorials/php/30...beginners/
Loi 16 : Never, Ever Trust Your Users.

Et je vous invite à lire tout le reste... ça en aidera pas mal à appréhender un travail dans une perspective "qualité" et non plus "autosatisfaction solitaire"

[naholyr]

guile++

Je ne reviendrai même pas sur la notion de "bon programmeur" comme étant celui qui laisse volontairement des failles côté serveur... Si tu dois ne faire que des choses utiles, alors oublie l'Ajax et les vérifs côté client. Par contre celles côté serveur sont indispensables.

Mais ça n'était certes pas le sujet initial.

[Argorate]

Ne déformer pas mes propos, je suis totalement d'accord qu'il faut constament vérifier les données coté serveur, mais il faut le faire de manière inteligente.
Si on peut faire autrement (sans perdre l'aspect securité), on gagne en temps d'execution, ce qui n'est pas rien, c'est ce qu'on appel optimiser son code

[Allwise]

Penser un truc optimisé c'est bien, vouloir faire un truc sur-optimisé c'est mal. Ton jeu n'est pas fini que tu te poses déjà des questions qui n'ont lieu d'être... Gagner en temps d'exécution c'est cool, mais c'est pas sur 3 conditions côté serveur qui se courent après que vas en gagner. C'est davantage sur la tournure de gros algorithmes, le stockage / la mise en cache de tes données, tes requêtes SQL...
De plus, la sécurité devrait toujours prévaloir sur l'optimisation... Sinon, comment veux-tu vérifier les données côté serveur autrement qu'en les vérifiant côté serveur ?

L'Ajax a son domaine d'application, dans ton cas ça me paraît adapté. Cependant, il faut l'utiliser comme il faut, dans les règles. La gestion de traitements asynchrones implique systématiquement la notion de callback. Un vieux débat me laisse à penser que tu n'es pas familiarisé avec cette notion, qui est la clé de ton problème. Si des traitements doivent s'exécuter les uns à la suite des autres et qu'il y a de l'Ajax dans l'un d'eux, ceux qui suivent devront être appelés après que le serveur ait répondu à la requête Ajax.

Quelqu'un a aussi parlé de flags et de file d'attente, qui sont aussi de très bonnes solutions à ton problème ( et qui font toutes deux appel à des callback ).

Petit conseil, si tu penses utiliser massivement javascript dans ton jeu, l'ajax, et tout le tsoin tsoin, je te conseille d'utiliser une librairie Javascript : JQuery, Mootools ou n'importe laquelle ( y en a tellement ). Ça t'apportera beaucoup plus de souplesse et de possibilités que des fonctions codées main, tu iras beaucoup plus vite.

Un bon programmeur c'est aussi quelqu'un qui sait se remettre en question. Dans ce topic beaucoup t'ont proposé des solutions et t'ont expliqué le problème de base, je pense que tu pourrais dire "merci les gars !" et le marquer "résolu".

[Argorate]

Je ne pense effectivement pas pareil. Je suis perfectionniste et je trouve que quelqu'un qui met des if ou il ne faut pas ce n’est pas malin ni optimisé.
Alors c'est sur que ça fera pas gagner beaucoup de temps, mais au final 1 + 1 +1 +1+1... Ça fait toujours quelque chose.

Ensuite je pense qu'il est normal de se poser les bonnes questions au bon moment -je ne vois pas qu'es ce qui te permet de dire "que ça n'a lieu d'être"
Faire un model quand on sait que dans quelques mois faudra passer a un autre est une perte de temps. C'est pour ça que je voulais voir avec Ajax et que je trouve ma démarche légitime et bienvenue.

Mais au final l'avantage d'Ajax ne compense pas les pertes dans mon cas. Donc faudra que je revoie le tout plus tard si je veux vraiment de l'Ajax (ce qui n'est pas obligatoire).

Quand aux solutions, j'ai bien pris note ne t'inquiète pas, j'y recourrais le cas échéant. ^^

PS: je ne dis pas merci ni ne "ferme" le topic en mettant résolu tant qu'il semble y avoir un dialogue en cours