12-02-2010, 02:38 PM
y a des choses que je trouve incohérentes dans le fil de discussion
quelle est la différence entre un batiment et une ressource ?
les ressources ça sert à [traitement informatique] des bâtiments
les bâtiments ça sert à [traitement informatique] des cités
il n'y a aucune raison pour qu'on fasse une différence de modélisation sur les termes "batiments" et "ressources"
Pour moi le sujet est plutôt variation/nombre de type/utilisation
Si il n'y a que trois types de [bâtiments/ressources] dans le jeu et que cela n'évoluera pas et que la seule utilisation est le comptage de [bâtiments/ressources] => je pense que le mieux est trois colonnes
Si il y a 50 types de [bâtiments/ressources] dans le jeu ou que les types évoluent ou qu'on utilise de plusieurs manières ==> je pense que le mieux est une nouvelle table
Exemple : un jeu où il n'y comme ressource que "blé" "fer" "or" "cristal"
on peut se dire ce sont des colonnes
maintenant si dans le jeu les ressources peuvent s'auto détruire (le blé qui pourrit si il reste trop longtemps non consommé, le fer qui s'oxyde, etc... donc il faut compter avec le "vieillissement" de la ressource, etc...), il sera plus pertinent de passer à un modèle à deux tables, même si il n'y a que quatre ressources
ce n'est pas le terme ressource ou bâtiment qui justifie d'être en colonne ou en ligne, c'est l'utilisation/gameplay du terme. Dans tel jeu telle notion pourrait être plus pertinente en colonne, dans telle autre non.
Maintenant je suis aussi partagé sur le côté tout en table rien en fichier (pauvre Sephi, je reprends tous tes arguments, mais je n'ai rien contre toi :p )
- est ce que tout le monde met les fichiers de traduction en table ? après tout les traductions, ce n'est rien d'autre que de la donnée
- est ce que les fichiers xml ou les fichiers de configuration devraient être tous en bdd, après tout ce sont des données
- est ce que développer des classes avec des comportements, voire des données initialisées en dur dans les classes c'est mal ? Imaginons la classe grenier qui hérite de la classe batiment (bon pas sûr que l'exemple soit terrible ^^).
- en quoi un tableau est plus coûteux qu'une requête (qui rappelons le, donne un résultat sous forme de tableau) ?
je pense que là encore tout dépend du contexte. Si les coûts évoluent autant qu'une configuration, je ne vois rien de choquant à les conserver sous forme de tableau
Quant à l'aspect interrogation des données par une application tiers, ma vision du découpage en couches fait que, finalement, peu importe les applications tiers, l'accès aux données ne doit être développé qu'une fois donc si pour le jeu on sait gérer les coûts via tableau, alors on sait les restituer à une autre application
maintenant je ne suis pas architecte, jamais vraiment été formé sur ce sujet, et suis prêt à entendre les critiques la dessus
A noter, dans MA représentation d'un jeu, ma démarche non réfléchie serait de tout mettre sur le modèle trois tables (que ce soit ressources et bâtiments) parce que j'imagine un jeu à interaction importante sur ces éléments, maintenant si l'un de ses éléments est prétexte et donc simple (genre y a de l'or et des pierres et puis c'est tout) je prendrais plut^to l'option colonne mais ce n'est pas MA représentation "innée" d'un jeu
quelle est la différence entre un batiment et une ressource ?
Citation :En l'occurrence, tu as tout intérêt à avoir tes 5 colonnes (metal_count, crystal_count, etc.)
les ressources ça sert à [traitement informatique] des bâtiments
les bâtiments ça sert à [traitement informatique] des cités
il n'y a aucune raison pour qu'on fasse une différence de modélisation sur les termes "batiments" et "ressources"
Pour moi le sujet est plutôt variation/nombre de type/utilisation
Si il n'y a que trois types de [bâtiments/ressources] dans le jeu et que cela n'évoluera pas et que la seule utilisation est le comptage de [bâtiments/ressources] => je pense que le mieux est trois colonnes
Si il y a 50 types de [bâtiments/ressources] dans le jeu ou que les types évoluent ou qu'on utilise de plusieurs manières ==> je pense que le mieux est une nouvelle table
Exemple : un jeu où il n'y comme ressource que "blé" "fer" "or" "cristal"
on peut se dire ce sont des colonnes
maintenant si dans le jeu les ressources peuvent s'auto détruire (le blé qui pourrit si il reste trop longtemps non consommé, le fer qui s'oxyde, etc... donc il faut compter avec le "vieillissement" de la ressource, etc...), il sera plus pertinent de passer à un modèle à deux tables, même si il n'y a que quatre ressources
ce n'est pas le terme ressource ou bâtiment qui justifie d'être en colonne ou en ligne, c'est l'utilisation/gameplay du terme. Dans tel jeu telle notion pourrait être plus pertinente en colonne, dans telle autre non.
Maintenant je suis aussi partagé sur le côté tout en table rien en fichier (pauvre Sephi, je reprends tous tes arguments, mais je n'ai rien contre toi :p )
- est ce que tout le monde met les fichiers de traduction en table ? après tout les traductions, ce n'est rien d'autre que de la donnée
- est ce que les fichiers xml ou les fichiers de configuration devraient être tous en bdd, après tout ce sont des données
- est ce que développer des classes avec des comportements, voire des données initialisées en dur dans les classes c'est mal ? Imaginons la classe grenier qui hérite de la classe batiment (bon pas sûr que l'exemple soit terrible ^^).
- en quoi un tableau est plus coûteux qu'une requête (qui rappelons le, donne un résultat sous forme de tableau) ?
je pense que là encore tout dépend du contexte. Si les coûts évoluent autant qu'une configuration, je ne vois rien de choquant à les conserver sous forme de tableau
Quant à l'aspect interrogation des données par une application tiers, ma vision du découpage en couches fait que, finalement, peu importe les applications tiers, l'accès aux données ne doit être développé qu'une fois donc si pour le jeu on sait gérer les coûts via tableau, alors on sait les restituer à une autre application
maintenant je ne suis pas architecte, jamais vraiment été formé sur ce sujet, et suis prêt à entendre les critiques la dessus
A noter, dans MA représentation d'un jeu, ma démarche non réfléchie serait de tout mettre sur le modèle trois tables (que ce soit ressources et bâtiments) parce que j'imagine un jeu à interaction importante sur ces éléments, maintenant si l'un de ses éléments est prétexte et donc simple (genre y a de l'or et des pierres et puis c'est tout) je prendrais plut^to l'option colonne mais ce n'est pas MA représentation "innée" d'un jeu