09-09-2009, 09:21 PM
Quelqu'un pourrait m'expliquer l'intérêt de stocker ça autre part que dans la table qui contient les bâtiments ? Je ne comprends pas pourquoi vous vous emmerdez à vouloir mettre ça ailleurs.
Voilà ce que je ferais si je développais un Ogame-like :
Il suffit de stocker le prix de base dans la table, pour chaque modèle de bâtiment. Notre table building_models contient donc (au minimum) les champs suivant :
Ensuite, vous instanciez vos bâtiments pour chaque utilisateur grâce à la table de jointure qui contient au moins quatre champs :
À côté de ça, j'ai une classe Building et une table pour chaque type de bâtiment (cela servira si le bâtiment a des comportements différent de n'importe quel Building).
Cette classe Building dispose d'au moins deux méthodes :
Ainsi, si la caserne (la classe s'appellera Barracks) n'a pas la même courbe d'évolution que les autres, il suffira de surcharger la méthode de la classe Barracks.
Quand vous instancierez vos bâtiments, vous utiliserez une Factory (qui créera un objet Barracks si le champ type était Barracks, etc.).
Cette approche à un nom : Single Table Inheritance.
Ainsi, vous avez un système robuste, qui repose sur des design patterns (qui sont des solutions éprouvées dans l'industrie, donc généralement (toujours ?) meilleures que celles que vous pouvez imaginer) et qui est très souple.
Sephi-Chan
Voilà ce que je ferais si je développais un Ogame-like :
Il suffit de stocker le prix de base dans la table, pour chaque modèle de bâtiment. Notre table building_models contient donc (au minimum) les champs suivant :
- id - L'identifant du type de bâtiment ;
- type - Le nom de la classe qui sert à représenter ce genre de bâtiment (cf. plus bas) ;
- gold_cost - Le coût de base en or ;
- wood_cost - Le coût de base en bois ;
- duration - Durée de création du bâtiment;
Ensuite, vous instanciez vos bâtiments pour chaque utilisateur grâce à la table de jointure qui contient au moins quatre champs :
- id - L'identifiant cette instance ;
- building_model_id - L'identifiant du modèle de bâtiment (la table des modèles s'appelle building_models donc on le retrouve dans la clé étrangère, au singulier) ;
- user_id - L'identifiant de votre joueur ;
- level - Le niveau actuel du bâtiment ;
- upgrade_started_at - Le timestamp (champ de type DATETIME) du moment où l'amélioration a été lancée.
À côté de ça, j'ai une classe Building et une table pour chaque type de bâtiment (cela servira si le bâtiment a des comportements différent de n'importe quel Building).
Cette classe Building dispose d'au moins deux méthodes :
- Une méthode costForLevel(level) qui renvoie un tableau associatif qui associe la somme nécessaire pour chaque ressource pour évoluer vers le niveau indiqué.
- Une méthode costForLevel(level) qui renvoie la durée (en secondes) pour évoluer vers le niveau indiqué.
Ainsi, si la caserne (la classe s'appellera Barracks) n'a pas la même courbe d'évolution que les autres, il suffira de surcharger la méthode de la classe Barracks.
Quand vous instancierez vos bâtiments, vous utiliserez une Factory (qui créera un objet Barracks si le champ type était Barracks, etc.).
Cette approche à un nom : Single Table Inheritance.
Ainsi, vous avez un système robuste, qui repose sur des design patterns (qui sont des solutions éprouvées dans l'industrie, donc généralement (toujours ?) meilleures que celles que vous pouvez imaginer) et qui est très souple.
Sephi-Chan