Comment gérer une carte de 500*500 cases dans une bdd ?

[php_addict]

J'ai déjà rencontré le problème d'une map trop grande

quand tu dis "trop grande": quelles dimensions ?

car 500x500 avec des index cela doit passer...

ton système mixe c'est pas un peu trop lourd pour php ? combien d'octet en JSON pour un seul de tes fichier map?

[barst]

Une map de 750x1500.

Chaque fichier contenant une zone de 75x75 de quelques Ko :
- pour des données du type [X][Y]="Z", ton fichier fera 1-2 Ko.
- pour des données du type [X][Y] = array(....,...,...), j'ai atteint la taille max de 150 Ko sans compression, sinon je tournais entre 30-40 Ko.

[PommeCassis]

Hum... un truc m'intrigue, vous n'êtes pas trop bavard a propos des framework MVC. Est-ce déconseillé pour les jeux webs ?

Pour JSON je ne connaissais que de nom mais ça risque de compliquer la manipulation des données avec un framework. Je sais, j'ai que ce mot la a la bouche, mais ça serait dommage d'avoir appris à utiliser le MVC et à se servir d'un framework pour ensuite ne pas m'en resservir dans un projet.

Encore merci pour vos conseils

[Sephi-Chan]

Les frameworks MVC (et même les autres) sont adaptés aux jeux car ils t'aident à te concentrer sur le développement de ton jeu au lieu de perdre du temps sur des choses inutiles.

Je te conseille plutôt Symfony que CakePHP (j'ai bossé avec quelques mois), dont la mauvaise implémentation du lazy loading risque de rendre l'application trop lourde. Peut-être se sont-ils améliorés sur ce point, mais Symfony semble plus mûr.

Concernant la serialisation de colonnes, je suis persuadé que Symfony peut le faire de manière transparente. Et si ce n'est pas le cas, ça doit pouvoir se coder très simplement puisqu'il suffit de serialiser la valeur à l'enregistrement et de la déserialiser à la récupération.

Content de voir que tu es volontaire pour utiliser de vrais outils. Ça change un peu des réinventeurs de roues. iffle:


Sephi-Chan

[PommeCassis]

J'essaye de mettre en application ce que j'ai appris pendant les cours. Et puis je trouve la programmation avec framework beaucoup plus agréable. Ça m'aide aussi à ne pas partir dans tout les sens avec mes idées farfelues :ange:

J'ai vue sur le net que la release de Symfony 2 sortirait cette année et offrirait de très bonne performances, du coup je vais peut être attendre pour commencer.

En attendant je peux m'éclater sur le cahier des charges, la bdd, commencer à apprendre Symfony et essayer de l'utiliser avec JSON avec une carte test (CakePHP étant un framework simple d'après mon prof, je risque de souffrir avec Symfony et doctrine) Enfin bref y a de quoi faire :O

[Zamentur]

Moi votre serialisation de colonne je suis pas pour, même si je l'ai utilisé. On a une base de donnée faut s'en servir.
Que se passe t'il si on veux mettre en couleur toutes les cases maudites parce que le gars à la nouvelles compétences qui voit tout...

En l'occurrence je conseille:
tile_map(#id, x ,y ,id_map, id_terrain,id_building=>building) en supposant qu'il n'y a qu'un terrain par case et un éventuel bâtiment

tile_malediction(#id, id_tile_map=>tile_map, id_malediction) on peux virer l'id si on est sur qu'il ne peux y avoir 2 malédictions identiques sur une case et faire porter la clef primaire sur les 2 champs

on peux faire une table à coté pour faire des malédictions de zones.

Enfin bref à toi de voir ce qu'il convient le mieux, moi je choisis toujours les solutions les plus évaluable si les ressources limites pas, afin d'éviter d'avoir à tout changer après.

[Sephi-Chan]

J'essaye de mettre en application ce que j'ai appris pendant les cours. Et puis je trouve la programmation avec framework beaucoup plus agréable. Ça m'aide aussi à ne pas partir dans tout les sens avec mes idées farfelues :ange:

J'ai vue sur le net que la release de Symfony 2 sortirait cette année et offrirait de très bonne performances, du coup je vais peut être attendre pour commencer.

En attendant je peux m'éclater sur le cahier des charges, la bdd, commencer à apprendre Symfony et essayer de l'utiliser avec JSON avec une carte test (CakePHP étant un framework simple d'après mon prof, je risque de souffrir avec Symfony et doctrine) Enfin bref y a de quoi faire :O

La pre-release de Symfony 2 est déjà sortie : Symfony Reloaded.

CakePHP est assez simple oui. Quand je l'ai utilisé, il y a 2 ans, j'ai trouvé ça sympa : beaucoup de choses sont devinées par le frameworks, grâce à des conventions de nommage (principe "Conventions over configuration"), etc. Et puis j'ai découvert Ruby on Rails, qui a (parfois fortement) inspiré CakePHP et Symfony. Et là je me suis rendu compte que CakePHP ne jouait pas dans la même cour que Symfony et Rails.

Symfony a l'air d'avoir une courbe d'apprentissage plutôt lente. Il ne faut pas avoir peur de la quantité de configuration et autres trucs à écrire/générer. Il paraît que, dans Symfony 2 tout doit être explicite. Au vu de la masse de code des projets Symfony 1.x, j'ai du mal à imaginer qu'il ai pu en être autrement…

Après, le choix n'appartient qu'à toi. Et selon ton expérience et ta capacité d'apprentissage, tu peux peut-être regarder du côté des frameworks pour d'autres langages.

Moi votre serialisation de colonne je suis pas pour, même si je l'ai utilisé. On a une base de donnée faut s'en servir.
Que se passe t'il si on veux mettre en couleur toutes les cases maudites parce que le gars à la nouvelles compétences qui voit tout...

En l'occurrence je conseille:
tile_map(#id, x ,y ,id_map, id_terrain,id_building=>building) en supposant qu'il n'y a qu'un terrain par case et un éventuel bâtiment

tile_malediction(#id, id_tile_map=>tile_map, id_malediction) on peux virer l'id si on est sur qu'il ne peux y avoir 2 malédictions identiques sur une case et faire porter la clef primaire sur les 2 champs

on peux faire une table à coté pour faire des malédictions de zones.

Enfin bref à toi de voir ce qu'il convient le mieux, moi je choisis toujours les solutions les plus évaluable si les ressources limites pas, afin d'éviter d'avoir à tout changer après.

Ça dépend… Au début, je me disais systématiquement que faire des relations n, n était plus propre.
Mais en fait, à partir du moment où tu n'as pas à interroger ta base selon les critères des tables jointes, ça ne sert pas forcément.
Comme d'habitude : il faut choisir une solution adaptée aux besoins.


Sephi-Chan

[PommeCassis]

Symfony 2 me tente bien donc j'apprendrai sur la pre-release en attendant.

Concernant JSON, pourquoi utiliser JSON plutôt que XML ? (j'ai lu quelques sujets comme celui ci mais je suis pas encore au point).

Par exemple dans un de nos projet on voudrait stocker des classements sous forme de fichiers. Ces classements pouvant contenir plusieurs milliers d'entrées. A votre avis il vaut mieux JSON ou XML ?

Je pense que dans ce cas XML est plus adapté car les fichiers sont assez volumineux. Mais j'en suis pas vraiment sur :heuu:

[php_addict]

Concernant JSON, pourquoi utiliser JSON plutôt que XML ?

- le json est moins verbeux, donc moins lourd (moins de texte si tu veux...)

- le json est native de Javascript, donc directement utilisable. En JavaScript, il est simple d'évaluer une expression JSON pour la transformer en objet natif :

var donnees = eval('('+donnees_json+')');

bien qu'il faille utiliser un parseur pour d'eventuelles failles (json.org propose plusieurs parseurs...)

en php il y a des fonctions pour traiter le JSON

json = simple, facilement utilisable, et surtout très léger en terme de taille...

voili voilou...

[QuentinC]

Côté javascript, le XML a l'avantage de pouvoir s'intégrer facilement au DOM existant...
Côté php par contre, il faut sortir l'artillerie lourde..... il y a plein de parseurs XML différents mais ils sont tous relativement lourds je trouve. Là tu as le choix : SimpleXML, XMLReader/Writer, DOM/DOMXML, SAX... tous ont leurs particularités, ils ne répondent pas tous aux mêmes besoins. Avis personnel : DOM/DOMXML est le plus complet mais aussi le plus compliqué et le plus lourd, SAX est pratique pour une lecture linéaire du fichier, et SimpleXML est un bon compromis. Je ne me prononcerai pas sur XMLReader/Writer que je ne connais pour ainsi dire pas.