Mettre à jour un modèle backbone suite à une action dans un jeu

[niahoo]

Bon y a un truc qui n'est pas clair pour moi avec backbone.

Je dis backbone parce que c'est ce que je compte utiliser mais toute la partie théorique de ce post se suit avec une autre lib équivalente.

J'ai mon personnage dans un model.

Mettons que je veuille me soigner. La méthode la plus simple est qu'après l'action de soin, mettons un soin +10 PV, j'augmente mes points de vie de 10, et je .save() mon model.
Le save est envoyé au serveur, celui-ci vérifie que tout est ok, et me renvoie le modèle à l'identique, confirmant ainsi que mon heal s'est bien déroulé.
Du coup, ma vue se met à jour (ça a pu être fait en prédiction).

Bon, ça c'est facile, sauf qu'en console je peux me mettre des centaines de PV, ce n'est donc pas viable.
Mais ça correspond à tous les tutos rapides genre todolist.

Dans une todolist, tu veux changer le nom d'un item, il n'y a pas vraiment de contrôle, tu mets ce que tu veux en nom. Tu l'envoies au serveur, le contrôleur est tout happy et voilà.

Appelons ça "Model update" pour se la péter un peu.

Sauf que pour un heal, je ne peux pas utiliser Model Update.

- d'abord parce que on pourrait tricher
- ensuite parce que la quantité de heal va dépendre d'un jet de dés sur le serveur.

Je dois simplement envoyer un commande : 'heal'. Je peux mettre un attribut commande dans mon modèle qui sera interprété par le serveur.
Ainsi le serveur lit la commande et me renvoie le modèle en JSON avec les nouveaux PV.
ok.
Mais maintenant je suis face à un boss, je prends cher, je vais donc spammer ma commande de heal.

mon model :

Code :

{id:1,pv:80}

je m'envoie 2 heals en spammant, le premier me rend 10PV, le second 5PV.

Lors du premier clic, le serveur me renvoie

Code :

{id:1,pv:90}

, et lors du second heal, je reçois

Code :

{id:1,pv:85}

puisque mes deux heals ont été lancés alors que je n'avais que 80 PV.
Donc c'est foutu pour le spam, je peux au mieux mettre un cooldown, mais ça ne solutionne pas correctement ces race conditions.

Y a donc un truc à faire côté serveur pour résoudre ce problème. ça doit pas être si chaud mais c'est contraignant et ça fera pas du code limpide.

Bon, mais maintenant c'est Bobby qui me lance un lapin de feu. ça me descend ma vie de 15 PV. Là, j'ai rien envoyé au serveur, je n'attend pas de réponse. Je vais donc passer par du push. Du coup, je me dis, quitte à passer par du push pour tout ce qui est "commande" et pas "Model Update"*, on va mettre les heal avec.

Donc les deux questions :

- Est-ce que je raconte pas des conneries, ai-je loupé un truc ?
- Comment proprement mettre à jour mes modèles backbone depuis un push ? Comment faites vous ?

Question subsidiaire :

- Y a-t'il un truc plus adapté que Backbone pour ça ?


*Je garde Model Update pour changer un nom de perso, changer l'équipement du joueur, en somme tout ce qui se traduit vraiment par un état à valider plutôt qu'à une quantité ou autre : je valide facilement si on m'envoie un modèle de joueur avec comme nom "qzd_çèç))à'" mais je ne sais rien valider si on m'envoie "action:Soins rapides IV".

PS: si vous trouvez un nom plus approprié au topic, dites.

[Sephi-Chan]

Tout d'abord, il faut savoir ce qu'est ton jeu : un jeu solo en temps réel avec validation server-side (c'est la partie avec le boss qui me laisse penser ça) ? Car ça change totalement l'approche.

Quoi que tu fasses, on pourra pourras toujours tricher d'un point de vue UI. Si le gars s'amuse à se donner des tonnes d'or c'est tant pis pour lui : ça va lui dégriser les boutons pour acheter sa super arme mais quand il cliquera dessus, le serveur lui balancera une erreur (qu'il n'aurait pas eu en temps normal, puisque le bouton aurait été inactif).


Ensuite, l'approche qui consiste à recevoir objet JSON en réponse aux requêtes n'est pas adaptée, selon moi. Ça marche pour des applications à la con (type todo list), pas quand l'objet devient assez complexe pour ne pas être complet à chaque fois.

Dans ton cas, je verrais bien une méthode heal du modèle (qui envoie une requête POST à /characters/:character_id/heal?target_id=target_character_id). On se fiche un peu de ce qu'elle renvoie (éventuellement des erreurs de traitement). L'effet client-side de ton heal est immédiat.

D'ailleurs, on pourrait même imaginer un modèle Action avec un attribut type (attack, heal, etc.). Effectuer une action reviendrait à sauvegarder cet objet, et donc envoyer une requête POST à l'URL characters/:character_id/actions).


Pour le push, tu peux par exemple lancer tes listeners dans la méthode initialize de tes modèles, et avoir un callback spécifique aux différents canaux. Il n'y a plein de façon de faire (comme toujours avec Backbone).

[niahoo]

Tout d'abord, il faut savoir ce qu'est ton jeu : un jeu solo en temps réel avec validation server-side (c'est la partie avec le boss qui me laisse penser ça) ? Car ça change totalement l'approche.

Quoi que tu fasses, on pourra pourras toujours tricher d'un point de vue UI. Si le gars s'amuse à se donner des tonnes d'or c'est tant pis pour lui : ça va lui dégriser les boutons pour acheter sa super arme mais quand il cliquera dessus, le serveur lui balancera une erreur (qu'il n'aurait pas eu en temps normal, puisque le bouton aurait été inactif).

Non c'est un jeu multi. Mais dans une approche très naive de backbone, s'il se met une tonne d'or et que le modèle est sauvegardé, ça update sur le serveur, donc il pourrait acheter sa grosse épée. Bon, ce n'était qu'une introduction au problème.

Ensuite, l'approche qui consiste à recevoir objet JSON en réponse aux requêtes n'est pas adaptée, selon moi. Ça marche pour des applications à la con (type todo list), pas quand l'objet devient assez complexe pour ne pas être complet à chaque fois.

Voilà, d'où mon interrogation.

Dans ton cas, je verrais bien une méthode heal du modèle (qui envoie une requête POST à /characters/:character_id/heal?target_id=target_character_id). On se fiche un peu de ce qu'elle renvoie (éventuellement des erreurs de traitement). L'effet client-side de ton heal est immédiat.

D'ailleurs, on pourrait même imaginer un modèle Action avec un attribut type (attack, heal, etc.). Effectuer une action reviendrait à sauvegarder cet objet, et donc envoyer une requête POST à l'URL characters/:character_id/actions).

Donc ok j'envoie une simple commande, c'est ce que je compte faire. Ensuite utiliser un modèle Action c'est sexy, on peut ajouter des validations clients-side pour soulager le serveur par exemple. Tiens je me dis même que pour implémenter une barre d'action à la WoW on crée des modèles Action avec comme vue les boutons, et le clic est directement mappé sur .save(). ça me plaît bien comme approche.

Pour le push, tu peux par exemple lancer tes listeners dans la méthode initialize de tes modèles, et avoir un callback spécifique aux différents canaux. Il n'y a plein de façon de faire (comme toujours avec Backbone).

C'est bien le problème ! Tu me donnes ça comme exemple et ça me paraît simple et efficace. Est-ce la solution que tu emploierais ? Les autres ?

[Sephi-Chan]

Non c'est un jeu multi. Mais dans une approche très naive de backbone, s'il se met une tonne d'or et que le modèle est sauvegardé, ça update sur le serveur, donc il pourrait acheter sa grosse épée. Bon, ce n'était qu'une introduction au problème.

Tant mieux alors, c'est plus pratique.

Donc ok j'envoie une simple commande, c'est ce que je compte faire. Ensuite utiliser un modèle Action c'est sexy, on peut ajouter des validations clients-side pour soulager le serveur par exemple. Tiens je me dis même que pour implémenter une barre d'action à la WoW on crée des modèles Action avec comme vue les boutons, et le clic est directement mappé sur .save(). ça me plaît bien comme approche.

C'est une approche que j'emploie souvent : je suis plutôt pragmatique et me fiche d'être strictement RESTful, mais je trouve que la majorité des interactions peuvent être modélisées sous forme de simples ressources REST.

Pour le push, tu peux par exemple lancer tes listeners dans la méthode initialize de tes modèles, et avoir un callback spécifique aux différents canaux. Il n'y a plein de façon de faire (comme toujours avec Backbone).

C'est bien le problème ! Tu me donnes ça comme exemple et ça me paraît simple et efficace. Est-ce la solution que tu emploierais ? Les autres ?

Si cette méthode marche bien pour toi, utilise-la. Tu n'es pas obligé de recourir toujours à la même méthode, tu peux déclarer des listeners en dehors de tes modèles (après tout, on peut interagir avec un objet depuis l'extérieur), ou dans l'initialize d'une collection (par exemple pour un système de notification), selon tes besoins.

C'est ce sur quoi je suis parti dans mon activité pro (l'application est bien complexe, et j'en profite pour refaire un coup de pub aux plugins Marionette et Relational, indispensables pour de vraies applications Backbone) et ça a donné des résultats convenables.

[niahoo]

Ok merci pour tes réponses, ça me fait une base complète pour faire des tests.

Les gens, si vous avez d'autres expériences avec ou sans backbone ça me servirait aussi.