[Résolu] Temps réel d'une action sur un jeu navigateur

[Sôbi]

Bonjour à tous et à toutes,

Cela fait un moment que je suis inscrit sur le forum. Je le trouve toujours aussi intéressant.
Cela fait également  un moment que je zieute le forum pour regarder des choses qui pourraient m'inspirer ou m'aider. 
Sauf que là je suis en panne sèche d'une solution à mon problème de temps...

Voici une petite explication non exhaustive de mon/mes problème/s :

Problème n°1 :
Mon jeu est une map en 2D, gestion en PHP / Ajax / jQuery / etc...
Des personnes créaient des personnages avec une classe ( exemple : Mage )

Le mage pourra effectuer un sort. Ce sort ne saurait actif qu'au bout de 30 secondes de rechargement, il sera donc grisé en attendant. Cela dit il pourra faire un autre sort qui peut être lui n'aura pas besoin de temps. Comme un MMO finalement.
Bref, comment pourrais-je gérer le temps finalement ?! 
a -> Ajax ? 
b -> Header de la page à chaque chargement ?

Et si je veux que le joueur puisse accéder à un combat, que le compteur fasse 3 ... 2 ... 1 ... 0 Plus grisé, possibilité d'utiliser le sort...
Comment faire ? car la solution b ne pourra pas être pris en vigueur ... et la a. si 50 joueurs connectés ( j'espère :p ) ça demande pas mal de connexion et SQL au pauvre serveur ...

Problème n°2 :

Si je veux qu'au bout de 100 secondes, le joueur ait 1 point d'actions en plus 
Méthode a ? b ? 

Voilà, je bloque beaucoup sur ces systèmes de temps ... Assez pénible...

Pouvez-vous m'aider ? :$  
Solutions / Idées ? Conseils ? Etc... ? 

Un grand merci en tout cas !

[Xenos]

Salut,

Sans se jeter dans des websockets, je dirai que:
• Si le serveur connait la date d'un évènement à venir et que l'évènement concerne le joueur (ie, "ton Mage peut lancer ce sort à partir de telle date"), alors cette donnée aura sa place dans les headers de la page (ou dans un appel Ajax fait dès l'affichage de la page, si on veut séparer ces données de la page elle-même).
• Il ne faut pas mélanger les checks serveur de sécurité et les esthétismes du client: le serveur va toujours vérifier que le mage a le droit de lancer son sort quand la page de lancement de sort est requêtée. Coté client, le mieux est de ne pas coder de fioriture esthétique (ie, de truc grisés) et de ne les rajouter qu'après, c'est à dire de les ajouter quand l'action fonctionne bien coté serveur.

Pour le problème 2, étant en PHP, c'est un système d'état qu'il faut, c'est à dire "à la date T, j'ai X points. Quand je demande combien j'ai de points, le serveur regarde la date courante, fait le calcul, met à jour la DB si besoin, et retourne le résultat".
Avec cette mécanique, tu auras un système fonctionnel où le serveur est le "chef" du jeu, et dit où ce jeu en est.
Ensuite, tu peux mettre une surcouche coté client qui fera automatiquement monter le compteur affiché d'1pt toutes les 100 secondes. Le compteur affiché par le client et le compteur réel du serveur seront donc indépendants, mais devraient évoluer à la même vitesse.

[Sôbi]

Bonjour Xenos,

J'ai un peu de mal à comprendre tes réponses. J'avouerais être pas mal fatigué ah ah ! x')

Déjà, question un peu H.S, difficile de faire un jeu 100% Ajax sans passer par des websockets ?

Pour le premier point, Disons que la date d'un événement à venir est finalement l'instant T, le serveur connait donc la date de fin par une requête sur le temps d'utilisation du sort. Genre je lance mon sort à 14h29, le chargement de ce sort est de 1min. Le serveur pourrai donc savoir que la date de fin est a 14h30 pour ce sort à ce joueur.
Pour ton second point, si je comprend bien, grosso modo, mieux vaut TOUJOURS avoir le truc gris ( par exemple ) jusqu'à ce quand le mec aura actualisé la page et que le serveur aura détecter qu'il pourra re-utiliser le sort ?

Pour le problème 2, je vois pas trop comment mettre en place ce principe...

[Xenos]

Déjà, question un peu H.S, difficile de faire un jeu 100% Ajax sans passer par des websockets ?
Non, Websocket n'est aucunement obligatoire. Si tu veux a besoin d'une communication duplex client-serveur en temps quasi-réel, alors c'est une bonne solution. Sinon, t'en n'a pas besoin et tu peux donc faire ton jeu sans.

Pour le 1, le client a fait une requête au serveur pour lui dire "je lance mon sort" (et le serveur sait qu'il est 14H29, attention, ce n'est pas au client de le dire dans une archi comme celle-là). Le serveur stocke l'information, et répond au client "Ok, ton sort est lancé, et le prochain, tu pourras le lancer à 14H30". Le client ne fait rien de l'info. Le joueur peut donc recliquer sur "lancer un sort". Là, le serveur doit répondre "va te faire voir, t'as pas finit de recharger, t'auras finis à 14H30". Ensuite, tu ajoutes un code qui, lorsque le client reçoit la réponse du serveur (la 1ere ou la 2nde), alors le bouton est grisé, et un timeout (ou autre) le dégrise plus tard.

Pour le 2, non, mieux vaut au contraire n'avoir JAMAIS le grisé, cliquer sur le bouton, voir le serveur réponde "va te faire voir, t'as pas encore le droit de lancer ce sort" (que ce soit en AJAX ou non), et ensuite coder ce qu'il faut pour le grisé, pour faciliter la vie du joueur.

[Sôbi]

Je comprend mieux, 

Merci pour la réponse du websocket. 
Comment faire pour que le serveur stocke la donnée ?
|-> Dans la bdd ? Si oui alors comment faire pour ne pas trop grossir celle-ci en données ?

Sinon pour le :

Pour le problème 2, je vois pas trop comment mettre en place ce principe...

Je parlais par rapport à ceci : 

Pour le problème 2, étant en PHP, c'est un système d'état qu'il faut, c'est à dire "à la date T, j'ai X points. Quand je demande combien j'ai de points, le serveur regarde la date courante, fait le calcul, met à jour la DB si besoin, et retourne le résultat".
Avec cette mécanique, tu auras un système fonctionnel où le serveur est le "chef" du jeu, et dit où ce jeu en est.
Ensuite, tu peux mettre une surcouche coté client qui fera automatiquement monter le compteur affiché d'1pt toutes les 100 secondes. Le compteur affiché par le client et le compteur réel du serveur seront donc indépendants, mais devraient évoluer à la même vitesse.

Je ne comprend pas trop comment mettre en place ce principe...

[Ter Rowan]

perso je préfère le pilotage du grisé côté client (ie dès que je clique une fois, ça grise ce que ça doit griser et ça attend le retour serveur pour dégriser)

pourquoi ?

si je veux faire la combo de la mort qui tue : 1 j'envoie de l'eau, 2 je gèle le mec (qui explose grace à l'eau que je lui ai envoyé en 1)

scenario grisé côté client :
- je clique sur le sort d'eau
- je suis obligé d'attendre que le serveur m'envoie un retour pour pouvoir cliquer sur glace (donc le serveur sait que la cible est mouillée)
- je peux lancer mon sort de froid intense, paf le serveur me dit que le mec est gelé

scenario grisé côté serveur :
- je clique sur le sort d'eau
- je clique sur le sort de froid intense
- le serveur traite ..... ben j'en sais rien en fait, ça peut très bien être froid intense en premier non ?
- du coup le mec en face se chope un rhume mois cool

le seul souci que je vois dans ma méthode, c'est le serveur qui ne répond pas, mais dans ce cas le grisé est tout aussi valable, inutile de s exciter à cliquer sur les boutons pour rien, un refresh de page et on voit que le serveur déconne

[Sôbi]

Ok ok, je comprends tout cela. 
Mais je vois toujours pas comment faire ! Ah ah  x')

[Sôbi]

Petit up ?!

[Xenos]

Je n'ai pas tellement de meilleure réponse que ce qui a été dit. Dans l'idée, je te dirai de développer ton site sans te poser de question sur le JS. Tu l'ajouteras après, quand tu te diras que tel ou tel élément n'est pas super-ergonomique.

[Sôbi]

Je n'ai pas tellement de meilleure réponse que ce qui a été dit. Dans l'idée, je te dirai de développer ton site sans te poser de question sur le JS. Tu l'ajouteras après, quand tu te diras que tel ou tel élément n'est pas super-ergonomique.

Ok ok je comprends.

Et n'est-il pas possible d'avoir un exemple concret ? Genre un bout de code pour voir un peu comment tu le ferais par exemple ? ( sans pensé côté IHM, juste les actions )