Algorithme de calcul des coûts par niveau

[ThErOr]

Bonjour,
je n'ai pas trouvé de discussion semblable à la problématique que je viens évoquer.
Celle-ci consiste à trouver un système d'augmentation des coûts (bâtiments, technologies...) en fonction d'un niveau particulier.

Je m'explique, pour le moment nous avons gérés cela en donnant un coût au niveau 1 avec un algorithme commun à tous les élément d'un même type (bâtiment, techno...).

Par exemple nous avons un bâtiment "Quartier général" dont les coûts au niveau 1 sont les suivants: Fer: 200 | Bois: 500 | Pierre: 100

Disons que notre algorithme pour connaitre le coût du niveau supérieur est le suivant :
coût niv n+1 = (coût niv n) * 1.5

Nous avons donc les coûts suivants pour le niveau 2:
Fer: 200 * 1.5 = 300 | Bois: 500 * 1.5 = 750| Pierre: 100 * 1.5 = 150

On pourrait stocker toutes les valeurs de chaque élément (bâtiment, techno...) pour chaque niveau dans une table mais je trouve qu'il s'agit d'une mauvaise idée pour équilibrer le jeu par la suite. Nous préférons utiliser la méthode de calcul décrite pour ne pas avoir à recalculer tous les couts à chaque modification de l'équilibre.

J'ai plusieurs questions sur une telle gestion que nous voudrions valider ou faire évoluer avec vos remarques et expériences :
- Est-elle viable pour gérer l'équilibre du jeu ? (Le seul paramètre consiste à modifier l'algo de façon globale ou bien les couts de base de façon local à chaque élément.)
- N'est-il pas mieux de gérer un algo par bâtiment ?

Merci d'avance pour vos retours d'expérience

[Hideaki]

Je te conseillerais de gérer le tout par algo, le jour où tu crées un bâtiment de réduction de coût ou lors d'un rééquilibrage, tu risquerais d'être vraiment embêté recalculer toutes les valeurs de la base de donnée est fastidieux par rapport à la simple modification d'un algorithme, qui est à mon sens plus simple.

Ainsi ton algo "niv n+1 = (coût niv n) * 1.5" devra utiliser une boucle ou récursion.
Le plus simple mais aussi plus rapide, c'est d'utiliser un algo de ce style niv n+1 = coût niv 1 * n * 1.5, la courbe décrivant cette fonction sera linéaire ( dans cette exemple ).

Gérer un algo par bâtiment n'est pas forcement nécessaire, surtout au début, si tu souhaites ajouter de la finesse malgré tout, tu peux faire un algo par type de bâtiment, jouer sur les coûts de départ et/ou coefficient ce qui te facilitera la gestion et la correction d'anomalie.

[Shidame]

A mon avis, il vaut mieux avoir une fonction pour chaque bâtiment, en l'occurrence un coefficient pour ton exemple. Tu peux le stocker en base (avec un bon système de cache, puisque par la suite il ne changera pas tout les jours) ou bien le coder en dur, ou encore un système de fichier config.

[php_addict]

rien ne t'empêche de générer tes données avec ton algo et de mettre le tout dans ta base...c'est quand même vachement pratique une base de donnée, et le jour ou tu aura besoin de faire des jointures LEFT JOIN alors si tes données ne sont pas dans ta base il y aura comme un hic...

[ThErOr]

Gérer un algo par bâtiment n'est pas forcement nécessaire, surtout au début, si tu souhaites ajouter de la finesse malgré tout, tu peux faire un algo par type de bâtiment, jouer sur les coûts de départ et/ou coefficient ce qui te facilitera la gestion et la correction d'anomalie.

En effet la gestion d'un algo par type ou par bâtiment est comme même beaucoup plus précise. Je vais pour le moment utiliser le même pour tous mais faire en sorte de pouvoir le modifier individuellement.
Après ca peut aussi compliquer l'équilibrage dans le sens où on peut difficilement rééquilibrer de façon globale tous les coût du même endroit.
C'est donnant / donnant on peut pas tout avoir

rien ne t'empêche de générer tes données avec ton algo et de mettre le tout dans ta base...c'est quand même vachement pratique une base de donnée, et le jour ou tu aura besoin de faire des jointures LEFT JOIN alors si tes données ne sont pas dans ta base il y aura comme un hic...

En effet on peut utiliser les deux techniques en même temps (algo + stockage en base) mais ca oblige à calculer les couts pour un nombre fini de niveau par bâtiment.
Il n'y aura par contre aucune raison d'avoir besoin d'effectuer des jointures sur les coûts d'un bâtiments vu qu'on peut le recalculer au besoin...

Les 2 solutions sont bonnes je pense, mais je pencherai plus pour la gestion par algo (globalement ou par type d'élément)