Comment créer un city builder ?

[Sephi-Chan]

Hello,

Je suis à la recherche de ressources sur la création de jeux de type city builder, à plutôt petit échelle (moins de 1000 habitants). J'ai joué à pas mal d'entre eux (Banished, Planetbase, Frostpunk…) et c'est un genre que j'aime bien. J'aimerai donc réfléchir à la façon d'en créer un.

Dans ces jeux, les habitants ont des besoins qui agissent comme des contraintes aux commandes que l'on passe à sa population (on ne microgère pas les individus).

En ce moment je bosse beaucoup avec Elixir (j'implémente des jeux de société avec) et les mécanismes de ce langage permettent assez bien d'imaginer un système orienté agent, où chaque habitant peut être représenté par un agent (ici un process Erlang) qui interagit avec les autres agents du système. Cependant, j'aimerai savoir comment font les jeux existants (Banished utilise un seul thread, par exemple).

Le cas d'utilisation serait un jeu multi où les villes peuvent interagir. Ça veut surtout dire que le ou les serveurs doivent faire tourner plusieurs simulations.


Bref, comment feriez-vous ?

[Thêta Tau Tau]

Bref, comment feriez-vous ?

Perso je ferrais un jeu solo et pas un jeu multi. Ça simplifie beaucoup les question techniques et donc permet de plus se concentrer sur le jeu lui même, ce qui est déjà une tâche assez énorme en soi. De plus je ne suis pas persuadé que le multi soit essentiel dans un city builder.



Dans un jeu solo, avec un moteur, je ne pense pas qu'il y ai de souci technique particulier pour gérer plusieurs centaines d'unités (voir plusieurs milliers). En tout cas avec unity (je parle de ce que je connais), il faut quand même bien bourriner pour atteindre les limites du cpu.


Dans un jeu multi, tu auras le même soucis que les STR, à savoir que quand tu as des centaines d'unités, synchroniser leurs positions à chaque frame est complétement infaisable niveau bande passante.

Du coup il faut utiliser un autre système, où tu ne communique que les ordres donnés par les joueurs, et où une simulation tournant sur chaque client et sur le serveur se charge de mettre à jour la position des unités en fonction de ces ordres.

Cela dit c'est quelque chose d'assez complexe à implémenter, puisque qu'il faut que la simulation soit déterministe à 100% sinon les simulations vont diverger. Du coup pas de float (gérés différemment selont les processeurs), et il faut gérer les ordres de façon à ce qu'ils soient pris en compte à la même frame et dans le même ordre par chaque simultation.

[Sephi-Chan]

Le multi se limiterait plutôt à du commerce, donc de très petits besoins de synchronisation.

Ma question tourne plutôt sur comment simuler un personnage qui sera affecté à une tâche, et comment simuler la nécessité de répondre à ses besoins au fil des "tours" de jeu. Comment prendre en compte les temps de déplacements, etc.

J'ai déjà plusieurs idées (surtout dans la version orientée agent), mais peut-être en aurez-vous de bonnes à partager.

[Xenos]

Je suis tout à fait d'accord avec Theta: le solo va te simplifier la tâche.

En revanche, attention, car le type de RTS cité, c'est du lour (200 personnes à plein temps pendant 2 ans et avec 50 millions d'€ de budget, pour schématiser).

De plus, pour l'avoir plus ou moins expérimenté avec Eclerd et avec le gamebook de Dracca, il est parfois très compliqué de "travailler" son jeu au niveau des agents (ou travailler son gamebook au niveau des paragraphes pour Dracca) et espérer pouvoir contrôler l'ensemble des agents de manière fiable (ou le scénario général pour le gamebook). En d'autres mots, si tu travailles sur des agents, alors le joueur joue au niveau des agents (et pas au niveau macroscopique de sa "ville", qui peut partir en c*uilles à tout instant et qui sera vite impossible à piloter passé les 3-4 paramètres). Donc, si toi (en tant que créateur) tu "pilotes" ton jeu au niveau des agents, alors il vaut mieux que le joueur puisse jouer au niveau de ces agents (et leur donner des ordres spécifiques à chacun par exemple). Sinon, en tant que créateurs, tu auras des commandes de pilotage qui porte sur un truc (paramètres des agents), alors que le joueur aura une expérience de jeu qui porte sur un autre truc (la ville dans sa globalité).
Donc perso, si le jeu est un "city builder" qui se focalise sur la ville dans sa globalité, je pense qu'il vaut mieux faire une implé qui traite de la ville dans sa globalité.

Ce qui me fait peur en fait, ce n'est pas tant "comment vous feriez pour implémenter un personnage, blabla", mais sur la maîtrise du résultat ainsi simulé et la possibilité de lui faire prendre la "bonne" direction pour un gameplay sympa. ECLERD, c'était piloté au niveau des "agents" au niveau de la population, groupée suivant quelques caractéristiques. En gros, 1 agent = 1 tranche d'age de la population + 1 corps de métier + 1 région dans laquelle elle se trouve. Bilan: piloter le gameplay dans son ensemble pour arriver à un équilibre entre ressources produites et consommées est très très compliqué et très instable.
Si tu veux utiliser des agents, mieux vaut faire un gameplay où on pilote 3-4 personnages plutôt qu'une ville entière.

Enfin, attention car "j'ai joué à des jeux, j'ai bien aimé" n'implique pas que t'aimeras tout autant créer un de ces jeux, et n'implique pas non plus que t'aimeras y jouer. Le risque, c'est d'attendre de ton jeu (consciemment ou pas) un résultat similaire à celui d'une boite pro (que ce soit Ubisoft ou un groupe de 5 copains en indé), alors que tu as 50x moins de moyens (sauf si je me gourre, mais je ne crois pas que t'ai re-changé de métier pour te lancer dans l'industrie du jeu avec des finances derrière?!). Bref, un mod ou une contribution sur des jeux existants de ce type (dans la techno en question ou pas), cela sera peut-être plus stimulant, efficace et agréable au final (c'est une suggestion, t'as le droit de la jeter).

Voilà mes 2cents

[Sephi-Chan]

Admettons que ce soit solo, en fait peu importe puisque c'est juste pour y réfléchir. Je compte pas créer de tel jeu dans un futur proche.

Comment feriez-vous pour que de temps en temps, le péon se dise : il faut que j'aille boire/manger/dormir/autre.
Comment feriez-vous que quand vous choisissez d'affecter un des péons inutilisés, il aille à l'endroit voulu, pour y travailler (= y passer du temps) ?
Etc.

[niahoo]

J'ai exactement ce projet dans les cartons, notamment le multi basé sur le commerce !

Par contre, je ne pense pas que coder un système orienté objet avec un process = un objet (ou agent) soit une bonne idée. À mon avis ça complique pas mal et ça bouffe de la ressource.

Je vois plutôt un process par ville (en théorie, ensuite s'il faut séparer la partie défense militaire, la partie climatique ou la partie connectée au marchés/transports intercités, c'est à un autre niveau du problème).

Ensuite tu auras un truc genre Entity/Component/Systems, en gros ta ville c'est ton state (ou, bien sûr, une sous-partie du state pour pouvroir stocker des timestamp ou autre joyeusetés en dehors), ou un ensemble modulaire de states. Ce state contient des entités, les agents (du coup des Struct !), que sont les villageois, bâtiments, et d'autres propriétés comme les ressources, etc.

Enfin, ton système c'est le code du process : il a une task queue, et il est capable d'ajouter lui-même des tâches dans sa queue. Par exemple, toutes les X secondes tu rajoutes le "system" (au sens ECS) qui consiste à calculer la population courante, calculer combien de bouffe il leur faut pour la période, tenter de consommer cette bouffe depuis les inventaires de la cité et buter du villageois en proportion si y a pas assez.

Si on prend l'implémentation de Banished, le nombre de woodcutters est fixe, déterminé par le joueur. On peut donc lancer X tâches de woodcutter qui vont checker l'inventaire, voir s'il faut du firewood, pécho des logs, les amener, les couper, etc.
Et puis se remettre sur la liste des tâches dès qu'on a fini 1 simple batch. ça fait beaucoup de boucles donc il vaut mieux favoriser les batchs plus longs avec un meilleur rendement.

Comme ça, tu peux faire tourner ce process à l'infini, tout en lui envoyant des messages pour le mettre à jour de la part du joueur. Et tu as un objet unique sur lequel poser tes listeners pour mettre à jour les clients.

Si le code est pas trop compliqué, et que tu sais que ta ville est occupée (tous les villageois sont occupés, ou bien il n'y a pas encore de ressources nécessaire avant X secondes pour les autres tâches), ton process va être gentiment idle, tu peux donc l'éteindre après l'avoir sauvegardé. Comme ça tu peux en faire tourner pas mal. Avec de faibles ressources, tu peux même avoir plein plein de villes sur le même serveur si par exemple tu as un moyen depuis la base de données de prioriser équitablement les villes à mettre à jour, et que tu les charge/update/save puis les éteint de force tour à tour. Bon, ça fait beaucoup d'IO avec la base.

Enfin, ça te permet de recoder la logique du jeu en Rust ou en C quand tu veux de la perf, via une NIF erlang, ou en Lua ou en JS, sans devoir toucher au code qui gère la relation avec HTTP, puisque tu gardera le process, il se contentera juste de faire le passe-plat à une implémentation externe : envoyer les tasks, récupérer des events et le nouveau state (entier, ou juste des updates).

--------------

Voilà, après effectivement sur un jeu pas multi, ou alors si tu as peu de villageois mais qu'ils sont particulièrement détaillés : skills avec niveaux, relations, état de santé, stuff/gemmage/enchant/talents/glyphes ou autre, l'idée des Agents n'est pas mauvaise en soi, mais c'est plus compliqué. Partir directement sur du multi me semble audacieux.

Je peux aussi développer là dessus si tu le souhaites, mais pour un city builder, bof.

[Ter Rowan]

je dirais au niveau unitaire :

chaque agent a une mission (couper du bois, miner, construire ....)
chaque agent a des besoins (faim, soif, sommeil, ...) qui sont scorés
chaque agent a un niveau d'anticipation (lié à la culture, l'éducation, l'intelligence, autre)

A chaque besoin, une action de couverture existe (durée, point de récup)

a partir de là :
si un score de besoin de l'agent est inférieur à son niveau d'anticipation alors il arrête sa mission pour réaliser son action de couverture


l'agent peut être un individu aka 1000 citoyens = 1000 agents
l'agent peut être une "cohorte" de n individus:
exemple dans l'usine de toto, qui fonctionne en "3/8" j'ai trois cohortes une par horaire

[Sephi-Chan]

Niahoo, dans ton exemple, le jeu "avance" comment ? Un sleep (ou send_after) dans le process principal ?

[niahoo]

Chaque tache en cours à une date de début et une date de fin, donc à chaque fois que tu démarre une tâche, tu recalcule la prochaine à finir, et à quel moment elle finit. Il te suffit de réveiller ton process à ce moment là.

Mais en l'abscence d'interaction multijoueurs avec le marché ou avec l'utilisateur, tu peux aussi tout simplement ne pas faire avancer le jeu avant qu'un élément extérieur aie besoin du state courant. Moi j'aime pas car je voudrais que la production destinée à la vente se retrouve en temps réel sur le marché.

[niahoo]

Et du coup on pourrait voir une implémentation de jeu de société ? ça me serait utile perso !