Jeu duel de carte (enregistrement donnée)

[med5]

Bonjour,

Aprés prés de 5 ans sur un projet qui à fortement évolué, changé et qui était devenue une véritable usine à gaz, je me lance sur un nouveau projet depuis quelques semaines.

C'est un jeu de carte dans la lignée des Magic et Yu-gi-ho, je suis actuellement dans la phase réflexion et je souhaité vous exposé en gros le système que je souhaite mettre en place pour la transmission des donnée afin de savoir si il est viable.

Je pense donc utiliser du "Reverse Ajax" avec juggernaut afin d'obtenir du (quasi)temps-réel.

Du coté client une interface html5/javascript afin d'afficher le plateau de jeu.

Coté serveur étant le langage que je maitrise le mieux je souhaiterais utiliser php avec juggernaut

Sa se passerait donc comme sa:

-un tableau représentant le plateau est crée dans la base de donnée mySQL.

-Le joueur clique sur une carte dans sa main pour la posée, il envoi donc un ordre du genre "posée carte id 04".

-La page php serveur reçoit l'ordre:

1. Appel à la base de donné afin de récupéré le tableau et donc l'état du plateau.
   
2. Vérification si l'action est possible (un emplacement vide du coté du joueur et condition de pose remplie)
   
3. Modification des valeurs dans le tableau.
   
4. Update du tableau dans la base de donnée.(ré-enregistrement complet après un sérialze() )
   
5. Envoi aux 2 clients d'un ordre "Placer carte id 04 emplacement 2 joueur 1" traité par javascript afin de tenir à jour la vue.
   

Voila le système auquel je pensait mais je me pose quelques questions: il y aura donc 2 actions minimum sur la base de donnée à chaque action du joueur (pose de carte, attaque, pioche...) cela ne risque pas d’être un peu lourd ?
(bien sur un maximum de choses seront vérifiée avec javascript afin de retiré une charge au serveur mais si l'action est possible une vérification sera faite coté serveur pour évité la triche)

Au mieux pourriez vous me conseiller quelque chose qui reste plus ou moins simple et plus rapide/moins lourd que mySQL ?

Et bien sur je suis totalement ouvert pour toute critique ou idée pour mon système, j'aimerais vraiment partir du bon pied cette fois-ci et ne pas rencontrer tout les problèmes lier au mauvais choix de technologie et au manque de préparation de mon ancien projet.

[Xenos]

Si le soucis est une question de "MySQL manque de patate", et sous condition que la solution "changer de langage" ne te convienne pas, tu peux utiliser des tables MySQL de type "MEMORY" (HEAP), qui n'utilise pas le disque dur pour stocker les données, mais la RAM.
Si ta table ne contient que des combats qu'on peut présupposer "ponctuels" (ils ne durent pas des heures) et si ces combats ne sont pas considérés comme des données très sensibles (une table HEAP est une table volatile: panne de courant = fin de données) alors tu peux t'orienter sur cela.

Autre solution potentielle: stocker quedale sur le serveur. Là, je n'ai pas d'idée de "comment faire", mais je peux t'exposer le principe de l'idée que j'ai en tête: Tu as N joueurs, qui sont censés jouer à la même partie. Le serveur, au lancement de la partie, envoie les données aux joueurs, concernant la partie initialisée et leur jeu. A partir de là, les joueurs se démer*ent. Quand le serveur reçoit un ordre du joueur A, il le renvoie au joueur B. Le joueur B traite alors l'ordre, et renvoit le résultat au joueur A.
A ce moment là, soit le joueur A est d'accord (le résultat envoyé par B et répercuté via le serveur correspond à ce que le joueur A "pensait"), auquel cas le joueur A valide l'état du plateau et le serveur peut stocker un hash correspondant à l'état du plateau;
soit le joueur A n'est pas d'accord, et le serveur arbitre qui a raison à partir du hash qu'il a en mémoire.

Le hash est optionnel, mais l'idée est vraiment de ne se servir du serveur que comme d'un miroir pour faire dialoguer les 2 joueurs. C'est plus fin à mettre en place, mais à l'exécution, le serveur se tourne les pouces. Je ne garantie pas que c'est sans faille (coté triche). Si le serveur stocke un hash correspondant au dernier étant du plateau, alors les joueurs sauront qui a "triché" en changeant le plateau à tort. Mais sans hash, y'a pas d'arbitre, et si un joueur triche, pas de possibilité de savoir qui a triché.

Dans un tel cas, l'algorithme de jeu est donc exécuté coté client, en javascript par exemple. Donc, les algorithmes de jeu seront publiquement lisibles, à l'inverse d'un algorithme PHP par exemple.

[Sephi-Chan]

Je pense que tu ne devrais pas t'inquiéter des problèmes de performance de MySQL (ou que n'importe quel solution SQL) : ça peut aller très loin sans flancher. Bien plus loin que la grande majorité des jeux Web (et a fortiori des jeux amateurs développés convenablement).

On peut bien se poser des questions sur les peformances ou l'efficacité d'un système, mais on ne peut pas agir dessus avant d'avoir mesurer quoi que ce soit. Or, pour mesurer, il faut avoir une application qui tourne. C'est bien par là qu'il faut commencer.

La plupart des applications Web un minimum complexes font facilement 20 requêtes SQL par requête HTTP, d'autant que le seul nombre ne suffit pas tant il peut y avoir de disparités entre deux requêtes SQL (ou même la même requête exécuté à un moment ou un autre).


Ce sur quoi il faut t'interroger, c'est plus sur l'architecture : faire une application Web monolithique, faire une application Web qui effectue la plupart des tâches en background, ou bien des mini-applications qui communiquent ensemble, etc. C'est ça qui te permettra d'avoir une application rapide ou non.


Pour ce qui est du push, je t'encourage à trouver une alternative à Juggernaut puisqu'il n'est plus maintenu. Tu peux par exemple regarder du côté de Faye ou même opter pour un serveur de WebSocket pur. Le meilleur choix serait sans doute un serveur de Server Sent Events : ce n'est pas forcément le plus simple à implémenter, mais c'est une technologique qui ne sera pas bloquée par un firewall sur un réseau d'entreprise ou d'école (deux cibles de choix pour un webgame).

[med5]

tout d'abord merci pour vos réponses.

Ne pas passer par le serveur n'est pas envisageable je souhaite tout particulièrement évité la triche.
Les plus longues partie ne devant pas dépassée 1 heure une table Memory pourrait être une bonne idée les données pouvant disparaitre sans aucune incidence si ce n'est sur les parties en cour au moment de la panne. Mon plus gros dédié possédant 32Go de ram je pense que c'est largement jouable.

Me voilà rassuré à propos de mySQL, je voulais être certain que rien que l'idée de mon système ne ferait pas vomir d'autre codeur. x)
On verra pour une possible optimisation une fois en place.

Pour le push j'avais justement hésité entre Faye et Juggernaut, et décidément j'ai la mauvaise habitude de pas faire gaffe si un projet et toujours maintenu ou pas. (je suis le dernier mec qui se servait encore de XajaX il y a 3-4 mois -_- )
Cependant je n'avais pas prit en compte le problème des proxy et donc le Server Sent Events viens de passer en tête de liste, je vais donc me lancer dans mon habituel 'je bidouille le truc dans tout les sens" histoire de le prendre en main.

L'architecture reste encore une question à cette heure ci, je ne me suis pas encore renseigné sur ce qui se fait et les avantages des différentes techniques. Jusque aujourd'hui j'ai toujours utilisé un modèle MVC pour mon précédent projet.

[med5]

Aprés une nuit de test Server Sent Events ne me semble pas approprié pour un jeu de duel de carte.

A part si j'ai rater quelque chose mais sinon à ce que j'en ai compris la connexion est unilatérale, tout le monde pompe les infos du fichier sans aucune distinction entre les clients.
Là où sa pose problème c'est que j'ai quelques informations qui devront être envoyé à un joueur et pas l'autre (en tout cas la carte qui est tiré, je ne souhaite pas montrer la main du joueur adverse) et si je traite sa coté client en quelques modif sur le code de la page on y à facilement accès.
Il faudrait donc généré une page php pour chaque joueur lors du début du combat et cette page devrait contenir une boucle infinie qui vérifie si il y a de nouvelle donnée à envoyé au client.

Le système fonctionnerait mais même avec des sleep() les boucles infinie c'est pas vraiment ce que je préfère, ni la requête "count" fait à SQL toutes les 2-3 secondes pour voir si quelque chose à été inséré.

Je vais donc me tourner vers du websocket pur, en passant les sockets sur le port 80 on passe au travers de la plupart des proxy.
Sans oublier la compatibilité, en couplant avec flash à partie d'IE 6 sa fonctionne.

[Sephi-Chan]

Il faut que tu crée plusieurs event sources.

Les connexions SSE sont effectivement unilatérales. Tu peux utiliser Ajax pour faire de l'autre sens : c'est probablement ce que tu vas faire de toute façon puisque je suppose que tu ne mettras aucune logique dans le serveur de push.