ajustement comportement des nœuds
calcul satisfaction et migration de la population
Afin d’éviter que le système ne se bloque, oscille ou dérive il a fallu procéder à quelques ajustements.
Arrêt de la production
Les exploitations arrêtent et reprennent l’approvisionnement du marché en fonction de l’état de celui-ci.
Plusieurs possibilités :
en fonction du prix : arrêt lorsque passe en dessous d’un seuil, reprise lorsque passe au dessus d’un seuil. Question : même seuil ou 2 seuils différents ?
en fonction de la quantité en vente sur le marché
A noter que la quantité en vente a un impact sur le prix, la différence va être “l’inertie” : réaction plus rapide si seuil sur la quantité alors que le prix évolue plus lentement mais également en continue pour une même quantité.
Conclusion : à creuser...
Saturation de la demande
La demande générée pas les besoins de la population est limitée par le nombre d’habitants. Par exemple, si il y a une population de 5 alors il ne peut pas y avoir plus de 5 ordres d’achat pour une ressource sur le marché. Une fois la limite atteinte et tant que la demande n’est pas satisfaite, le prix augmente et la satisfaction de la population baisse.
Offre et pas de demande : prix diminue
Demande et pas d’offre : prix augmente
Ni offre ni demande : retour progressif vers le prix de base <=> prix diminue si au dessus du prix de base, prix augment si en dessous du prix de base
Satisfaction et migration de la population
La satisfaction de la population est un indicateur important car il va entraîner l’arrivée ou le départ d’habitants.
Dans l’idée, plus il y a d’offre pour les ressources demandées par la population et plus les prix sont bas, plus la population est satisfaite.
Comme quantité et prix sont liés, on pourrait en théorie ne se baser que sur une de ces deux métriques mais dans la pratique elles apportent des dimensions différentes (vitesse de variation, temps de prise en compte,...). Une belle phrase pour dire que c’est la galère et que je ne sais pas trop comment faire ce calcul....
J’ai testé plusieurs méthodes :
sur l’ensemble des ressources, on calcul la moyenne de la variation des prix et on en découle directement la satisfaction.
on calcul le ratio de satisfaction en fonction du prix et de la demande de chaque ressource : la demande pour une ressource est satisfaite si le prix est inférieur au prix de base et il n’y a pas de demande en cours.
on donne une valeur arbitraire de satisfaction pour chaque ressource en fonction de l’offre, de la demande et du prix, puis on fait la moyenne.
prix bas et offre => 100%
prix bas et demande => 25%
prix bas et ni offre ni demande => 50%
prix haut et offre => 25%
prix haut et demande => 0%
prix haut et ni offre ni demande => 25%
Dur de trouver la bonne méthode et les bons seuils et valeurs, encore plus dur de faire des conclusions pour le moment. Je peux au mieux tenter de lister les conditions que doit remplir le calcul de satisfaction :
dépendant du marché et des ressources demandées
pas de grosse fluctuation ni d’oscillation
puisse rester un certains temps au min ou au max
impacté assez rapidement par l’arrivé ou le départ de population
Une fois la satisfaction calculée il faut en déduire l’impacte sur l’arrivée et le départ de population. Ma méthode basique :
arrivée si satisfaction au dessus d’un seuil pendant certain temps
ex : si > 90% pendant 50 tours => +1 pop
départ si satisfaction en dessous d’un seuil pendant un certain temps
ex : si < 10% pendant 50 tours => -1 pop
Tout ça nous amène à comment équilibrer le système pour qu’il soit cohérent, stable et, tant qu’à faire, intéressant à manipuler (je ne vais pas m’avancer à parler de fun...).
[spoiler] j’ai pas encore trouvé...
En gros on a définit une structure avec différents éléments qui interagissent et que l’on peut manipuler, il faut maintenant configurer leurs comportements et paramètres internes. C’est peut être ce qu’on appel du System Design (c’est un long post alors je balance des trucs à étudier plus tard) ou dans notre cas du Game Design.
En vrac, les paramètres sur lesquels on peut jouer :
calcul de l’évolution des prix sur le marché, borne min et max
calcul de la demande en fonction des besoins de la population
Seuils d’arrêt et de reprise de la production
calcul de la satisfaction et mouvement de population
taille de la zone d’influence des marchés
quantité de ressource pouvant être transportées par les marchands
liste des ressources du jeu, prix de base et temps de production
ressources dispos et quantité présente sur la carte au début du jeu
besoins de la population (ressources et poids)
évolution des besoins avec le temps
quantité d’argent du joueur
prix : construction, embauche
évolution des prix (ex: plus on embauche de marchand plus l’embauche coûte chère).
Et sûrement d’autres que j’oublie ou qui vont apparaître. A faire : un document complet avec une liste exhaustive.
J’ai organisé en deux parties mais je ne suis pas bien sûr de la pertinence :
Système : fonctionnement interne, paramètres qui définissent le système et qui sont fixés une bonne fois pour toute.
Game design : paramètres qui peuvent varier pour faire des “instances” différentes et plus ou moins difficiles.
Bon, le but était de faire un post après chaque jour de boulot, j’ai merdé. Je suis en retard de plusieurs jours, je vais essayer d’en comprendre les raisons :
une journée de travail n’est pas aussi clairement définie que prévu : un jour complet, deux demi-journée étalées sur 2 jours, un jour plus quelques heures le jour suivant pour finir. Ce qui casse le rythme.
tendance à vouloir faire un post une fois qu’une tâche est terminée, ce qui peut prendre plusieurs jours. Sans compter le classique problème qu’une tâche n’est jamais vraiment considérée comme terminée...
je préfère avancer dans le développement plutôt qu’écrire.
plus j’avance plus je veux faire des explications claires à destination de potentiels lecteurs, donc je me prends la tête et ce qui est censé être un petit post de mise à jour se transforme en la construction d’un article sur un sujet vaste, que du coup, je n’écris pas.
procrastination, fourre-tout pour le reste.
Conclusion
Bien différencier :
les posts journaliers, succincts et qui ne servent qu’à tenir le journal d’avancée. Un peu comme un daily meeting en scrum.
les posts sur un sujet précis, plus détaillés. Qui d’ailleurs ne doivent peut être pas mis sous la forme de post...
Bon il est temps de s’arrêter.
