Une ile pour chaque joueur

[Kassak]

Je viens tout juste de penser à un truc, qui est en faites un point très important du "petit" projet que je suis en train de faire.

Donc pour rappel, c'est un jeu de survie, vous débarquez sur une ile et à vous de vous débrouiller ! (en passant j'ai trouvé LE truc qui fera la différence, et qui pourrait être un but du jeu à lui tout seul, pour ceux qui ont suivit un de mes post récemment...mais chuuuuut)

Il n'y aura pas pour l'instant de contact direct entre les joueurs, donc ces derniers auront l'ile pour eux seul, à la manière d'un jeu solo.


On en vient au problème suivant, j'utilise une table carte listant les différentes iles du jeu (pour le moment qu'une donc id=1), sur cette carte je place monstres, ressources etc.....tout va bien, mais si par exemple moi joueur 1 coupe un arbre, celui ci sera coupé pour tous les autres joueurs, idem pour les monstres, le joueur 2 en bute un, il sera mort aussi pour les autres.

Vous suivez? Le soucis vient de la BDD, se sont des tables "communes", et ayant repris le même principe que pour mon mmorpg, je n'avais pas pensé à ça.


Donc comme solution, j'ai pensé, lors de l'inscription, de générer l'ile du joueur, avec toutes les entrées qui vont avec, ça règlerait sec tous ce problème...mais avec disons 200 entrées différentes pour une ile, ça va vite faire surchauffer le petit serveur OVH... (100 joueurs => 20 000 entrées d'un coup...aïe aïe !)

Et euh, la pour se soir je dois dire que je n'ai pas tellement d'idée aussi radicale....

[Cartman34]

Je pense que tu vas devoir opter pour une de ces solutions:
- Une table contenant tous les objets(monstres, arbres etc...), avec le type d'objet, l'id de l'île (et celui du proprio), l'état de l'objet (mort, coupé...) etc... C'est la méthode préférée sur ce forum. Avec une utilisation de InnoDB c'est pas mal mais très lourd (en effet, tu accumules vite une masse de données)
- Un champs TEXT dans l'entrée de la table île correspondante contenant tes données. C'est ma méthode préférée car tu ne fais qu'une requête de sortie(qu'on est obligé de faire généralement) et une seule requête pour modifier. La gestion Côté PHP est légèrement plus complexe

[Arathor]

Salut,
mon jeu aussi traite d'île et j'ai aussi eu affaire à ce genre de problème. Pour le résoudre, j'ai un script qui s'exécute à chaque inscription pour générer aléatoirement une île (enfin,dans mon jeu ce n'est pas forcément une île mais ça ne change rien au problème) et qui l'enregistre dans un fichier texte. A l'intérieur j'ai donc chaque case de la map sous forme d'id du terrain.
Apres pour les manipulations ce n'est peut être pas ce qu'il y à de plus facile à gérer, mais on peut s'en sortir à grand coup de regex

[azmimik]

eye,

La première solution de IGstaff est sans doute la plus simple a mettre en oeuvre, mais c'est clair que sa fait un paquet de donnée à enregistrer.
Sa deuxième solution est interessante. J'y ai pensé pour mon jeux, à la différence que j'y aurait mis des données serializées comme ça il suffit de deserializé pour avoir toute les données bien ranger
Pour la méthodes de Arathor c'est pareil que pour la deuxième de IGstaff, j'y mettrais des données sérializées.

Sinon en terme de poids en octet je ne sais pas si les trois solutions proposées y change grand chose (peut-être un peu car dans les deux dernières il n'y a pas besoin d'enregistrer l'id du joueur pour chaque objets) mais sa doit pas être flagrant.

[Eluox]

Je pense que la première solution est la meilleure.

Pour un temps sensiblement égal a l'exécution ( même si j'ai pas fait de test faudrait le faire ), la première est bien plus simple a mettre en place, et de plus, et plus "lisible"

[Kassak]

Quand vous dites la 1ère, c'est la solution que j'ai proposé et celle d'Igstaff?

Je pense aussi faire ça, et tant pis pour le surnombre de données, je vais essayer de limiter au maximum les répétitions sur chaque ile (du style les cases inaccessible, on les rentre une fois et basta), et puis je vais surement descendre a moins de 100 entrées différentes par ile, en plusieurs tables, ce qui n'est en faites pas grand chose.

[Cartman34]

azmimik -> serializé ou non, c'est le principe qui compte...mais même si vous avez beaucoup de case, cette technique est très rapide en utilisant explode(). La linéarisation (le vrai nom de la sérialisation) est plus "rapide" mais beaucoup plus lourde, ce qui n'est pas mieux dans ce cas (précis).

Eluox -> En fait, non ma technique est aussi simple mais moins connu, j'ai déjà posté les script et ils sont les mêmes pratiquement pour tous(tout dépend des séparateurs). De plus, je t'ai démontré que cette technique était légèrement rapide et d'après ce que je sasi, avec InnoDB ce serait pire. Dans tous les cas, ces techniques permettent des gestion de masse.

Avec cette technique, vous pouvez créé une fonction de linéarisation qui encoderait comme ceci: {id1},{x1},{y1},{etat1};{id2},{x},{y2},{etat2};...
Avec une fonction de 4 lignes, ca passe très bien, j'en ai fait une pour IGame.

[Eluox]

Sa reste tout de même moche et illisible je trouve :/

[Kassak]

Sa reste tout de même moche et illisible je trouve :/

Moche, illisible, et difficile de manipulation comparé à la 1ère méthode.

[Harparine]

Salut, l'autre solution est d'utiliser XML et de créer un dossier sur le disque pour chaque île. Ensuite dans ce dossier, tu ajoutes un fichier pour la carte, un pour les monstres, etc. C'est la technique que j'utilise sur mon jeu et ça fonctionne très bien. SimpleXML est un module maintenant natif de PHP qui permet de gérer facilement des tas de trucs en XML.
L'intérêt c'est que tous les joueurs ont leur propre fichier, donc pas de surchage de la BDD.
Le défaut, c'est le poids sur le disque mais tu peux estimer à 50ko la taille d'un dossier joueur, ce qui ne fait que 5mo pour 100 joueurs en ligne, 500mo pour 10 000 joueurs, ce qui reste honnête.
@+