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.
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.