Pendant longtemps, l'une des meilleures façons d'utiliser des processeurs puissants pour le divertissement était
Dwarf Fortress - un jeu dans lequel le monde entier est composé de caractères ASCII, et qui mangera volontiers un gigaoctet de mémoire et une grande partie du temps processeur.
Mais contrairement à certains autres jeux, dans le cas de
DF, la joueuse sent qu'elle a vraiment besoin de tout ce dont elle a besoin. Ses calculs détaillés créent un monde entier avec des bâtiments, des villes, des marchands, des rivières, des volcans, des monstres et, bien sûr, des gnomes. Si une personne créait tout cela, ce serait une réussite formidable;
Dwarf Fortress est un programme qui crée tous ces objets par lui-même.
L'auteur du jeu, Tarn Adams, a accepté de répondre à nos questions sur sa création qui, malgré l'existence de nombreuses imitations, reste un jeu tout à fait unique.
Gamasutra: nous avons entendu que Dwarf Fortress sortait sur Steam et itch.io dans une version payante avec une interface simplifiée. Ils disent que cela est dû à vos prochains coûts de traitement. Est-il difficile pour un développeur indépendant de rester à flot?Adams: Oui, vous devez faire beaucoup d'efforts pour ne pas quitter l'entreprise, et presque tous les développeurs sont obligés d'inventer des moyens créatifs pour pouvoir payer le loyer et d'autres besoins primaires. Et parfois, vous rencontrez des problèmes que vous ne pouvez pas gérer. Nous avons eu de la chance jusqu'à présent, mais nous devons changer au fil du temps: quitter et obtenir un nouvel emploi, passer à Patreon, et maintenant sur Steam avec démangeaisons, ou dessiner des dessins au crayon, ce qui est très loin de créer des jeux vidéo.
À quoi ressemble votre travail de construction de code au quotidien pour Dwarf Fortress ? Quelles langues utilisez-vous? Quelles bibliothèques? Quels IDE si vous les utilisez? Sur quel ordinateur développez-vous le jeu?Je travaille sur un ordinateur portable Toshiba ordinaire et sans particularité avec Windows 10. J'écris du code sur un mélange C / C ++ terrible dans la communauté MSVC. Pour la version héritée j'utilise OpenGL, pour la version principale j'utilise SDL et pour le son j'utilise FMod. Je n'utilise rien d'autre sur Windows, à l'exception d'une partie des en-têtes de MSVC (et avant), que j'utilise depuis des décennies. Je ne suis pas complètement au courant de ce qui se passe dans les versions Linux / Mac car je ne les développe pas régulièrement.
Dwarf Fortress est en cours de développement depuis près de 17 ans et sa base de code doit avoir atteint des proportions gigantesques. Sur ma machine, la création d'un monde avec des paramètres standard nécessite plus de 1,2 gigaoctets de RAM. Le problème avec de tels mégaprojets est qu'ils deviennent trop grands et ne s'intègrent pas entièrement dans le cerveau. Quelles stratégies utilisez-vous pour garder le projet intelligible et compréhensible pour le travail?J'ai un système de nommage strict et je n'économise pas sur les noms longs de variables et de fonctions, de sorte que tout est lisible même après quelques années. En général, j'essaie de prendre soin de l'avenir moi-même. Tous mes commentaires dans le code visent à cela. J'utilise activement la fonction "trouver dans les fichiers". Mais il y a des situations où je dois à nouveau comprendre ce qui se passe, par exemple, lors de l'expansion de l'ancien système ou de la correction du bogue; dans ce cas, la recherche peut prendre une heure ou plus. Cela me permet de laisser des commentaires utiles supplémentaires auxquels je n'avais pas pensé au départ.
Je me souviens que Threetoe (partenaire de Tarn dans le développement de jeux) écrit des histoires, puis vous essayez de créer un moteur de jeu dans lequel elles peuvent se produire. Il me semble toujours que c'est une façon de travailler inspirante. Les histoires que vous avez rejetées étaient-elles trop compliquées à mettre en œuvre? Est-il déjà arrivé que l'intrigue de l'un d'eux se répète complètement dans le jeu?Ha, je pense, d'une certaine manière, ils sont trop compliqués. Motivations des personnages, fixation d'objectifs, etc. restez en retard sur la façon dont ils se produisent dans les histoires. Cependant, c'est toujours un processus utile, car il y a toujours des éléments plus légers pour générer l'histoire; de plus, nous pouvons aborder la mécanique de base des personnages, même si nous ne l'atteignons jamais.
Wikipédia dit que le numéro de version du jeu (maintenant .44) montre à quelle distance vous êtes de l'achèvement (c'est-à-dire 44%). Qu'attend la forteresse naine à l'avenir? Avez-vous des pressentiments sur ce qui va se passer? Quels aspects sérieux avez-vous à mettre en œuvre?Je termine la sortie avec les méchants, qui sortira dans les prochains mois. Il devrait être assez curieux. Ensuite, nous allons implémenter les graphismes et augmenter la convivialité du jeu pour les versions sur Steam / Itch. Ensuite, nous améliorerons le processus de siège et ferons un peu plus de travail, puis passerons à Big Wait. Il s'agit de la plus grande restructuration et expansion de l'histoire de
DF . Cela nous permettra de générer des mythes sur la création et de créer des systèmes de magie entièrement procéduraux, ainsi que d'ouvrir plusieurs fenêtres pour visualiser différentes parties du monde, etc. Ce sera un excellent ajout. Ensuite, il y aura une libération avec les biens / lois / coutumes. Après cela, la commande n'a pas encore été déterminée, mais nous travaillerons sur l'économie, les navires et d'autres composants importants qui ne sont pas encore disponibles. Il nous reste encore beaucoup à faire! Nous ne sommes même pas allés à mi-chemin de la version 1.0. Mais la version 1.0, le développement du jeu ne se terminera pas réellement ... peut-être, au moment de sa sortie, nous n'aurons tout simplement plus beaucoup de temps.
Oui, cela arrive tout le temps! Cela est dû en partie au fait que lorsque vous jouez, il est difficile de garder à l'esprit toutes les règles. Cependant, toutes mes histoires mémorables sont des bugs, car j'ai rarement l'occasion de jouer au jeu assez longtemps, donc du point de vue du gameplay indépendant, elles sont de peu d'intérêt (même si elles me surprennent). De bonnes histoires peuvent être trouvées sur les forums, les streamers, etc.
La frontière entre micro et macro: pourquoi l'avez-vous fait comme ça, entre ce que les gnomes peuvent faire eux-mêmes et ce que le joueur ordonne aux forteresses de faire?Il s'agit d'un équilibre difficile, et il n'est pas toujours facile à maintenir, mais pour le moment le concept est que le joueur est le «porte-parole officiel de la volonté de la forteresse», et les nains affichent une autonomie, qui devrait être présente en dehors de leurs fonctions officielles. Cela leur permet d'être des acteurs dans leurs propres histoires, qui sont la principale source du récit émergent (émergent). En même temps, le joueur devrait être capable de contrôler le flux principal de sa partie du jeu (en fait, ce n'est pas critique, mais souvent plus intéressant que d'observer la simulation).
Ces deux objectifs peuvent entrer en conflit, et cela est souvent dû au fait que le joueur continue de profiter du jeu - par exemple, si le levier d'urgence doit vraiment être abaissé, le système de priorité des tâches peut pratiquement faire en sorte que le gnome le fasse, de manière autonome ou non, en fonction de s'il doit «savoir» ou non. Dans le passé, nous avons eu des problèmes à ajouter trop de bureaucratie lorsque, par exemple, nous avons eu un quartier-maître nain impliqué dans la livraison de l'équipement. Mais ce système était trop lent, sujet aux bugs et aux joueurs confus. Il est très important de réfléchir à la façon dont chaque mécanisme de jeu individuel peut ajouter des histoires potentielles, et le quartier-maître n'a presque pas joué de rôle dans ce domaine.
Quelles mesures le programme prend-il pour construire le monde?Elle alloue de la mémoire à la carte. Ensuite, elle choisit le pôle qu'elle aura (par exemple, nord, sud) (ou tient compte des paramètres passés par le joueur). La graine du générateur de nombres aléatoires définit les valeurs de base des champs de la carte (altitude, précipitations, température, drainage, activité volcanique, faune) pour une grille de taille variable, en tenant compte de divers paramètres (océans, tailles d'îles, autre variabilité), puis le programme les remplit de manière fractale. Le changement de température dépend des pôles et le programme sélectionne des points pour les pics les plus élevés. Ici, elle fait la première passe pour voir comment le processus est effectué et essaie de changer les hauteurs afin que la carte s'adapte aux paramètres souhaités. A ce stade, si le monde ne peut pas être corrigé, il est jeté et tout recommence.
Ensuite, le premier champ dérivé est défini - la végétation - en fonction de la hauteur, de la quantité de précipitations, de la température, etc. Le programme vérifie si les biomes correspondent aux intervalles spécifiés dans les paramètres. À ce stade, les hauteurs du niveau intermédiaire sont lissées pour créer des zones plus plates et les volcans sont placés en fonction du champ d'activité volcanique.
Nous passons ensuite au stade de l'érosion et de la rivière. Les petits océans sont drainés, le programme trouve les bords des pentes des montagnes à partir desquelles il peut exécuter des rivières d'essai. De plus, elle a une caméra sur l'un d'eux afin que le joueur puisse suivre le processus. Beaucoup de fausses rivières coulent de ces points, cassant des canaux, si elles ne peuvent pas trouver un chemin vers la mer. Des hauteurs trop élevées sont parfois aplaties pour que toute la carte ne se transforme pas en canyons. Idéalement, il serait nécessaire d'utiliser des types de substances minérales pour cela, mais jusqu'à présent, nous ne les utilisons pas. Les lacs sont cultivés à plusieurs endroits dans les rivières.
Les hauteurs sont à nouveau lissées des montagnes jusqu'à la mer, et pour les pics et les volcans, des ajustements locaux sont effectués. Une fois la création des hauteurs terminée, le programme ajuste la quantité de précipitations en fonction des ombres pluviales et des précipitations dans les régions montagneuses. En fonction de la hauteur et des précipitations, ainsi que de l'effet restrictif des forêts, les températures sont rétablies, après quoi le programme utilise les nouvelles valeurs pour finalement définir le niveau de végétation. Des valeurs de salinité sont définies pour l'océan et ses tuiles voisines.
Après avoir décidé de tout cela, nous pouvons maintenant trouver les limites des zones finales des biomes pour leur donner des noms et une personnalité. Ici, nous ajoutons également des couches géologiques et souterraines, bien que, comme mentionné ci-dessus, des informations géologiques auraient dû être ajoutées plus tôt. Ensuite, le processus de vérification finale de la conformité aux paramètres est effectué pour s'assurer que nous ne sommes pas trop déviés de ce que le joueur veut. Après avoir terminé, le programme génère les populations initiales du monde animal pour chaque région et définit les variables météorologiques.
L'histoire elle-même commence à partir de ce moment. Ensuite, les civilisations et les grottes sont localisées. Il est plutôt difficile d'expliquer ce qui se passe ensuite, mais l'idée principale est qu'un énorme jeu stratégique est simulé avec zéro joueur avec des règles de mouvement plutôt arbitraires et une mauvaise IA (mais avec des milliers d'agents), sur la base de laquelle l'histoire est écrite. La génération procédurale d'histoires à l'aide de la journalisation par simulation est une approche complètement fonctionnelle, mais elle a aussi ses inconvénients. Il s'agit d'un travail important, il est nécessaire d'effectuer un post-traitement et d'étudier afin de trouver les bons points que vous souhaitez souligner, et si la dynamique et les mécanismes ne sont pas suffisants, le résultat peut être ennuyeux.
Ce que j'aime le plus dans DF, c'est que le jeu ne contient aucun système de points de vie explicite, tout ce qui concerne la force et les dégâts du personnage fait partie d'un modèle complexe de parties du corps. Quels sont les avantages d'un tel système? Si quelqu'un décide de créer quelque chose de similaire, à quels obstacles peut-il s'attendre?Ce modèle crée des moments de tracé plus détaillés, des conséquences à long terme et offre une meilleure connectivité du système. Il est facile d’aller trop loin, et nous sommes vraiment allés trop loin à certains endroits, du moins au stade actuel - certaines propriétés des matériaux ne sont utilisées nulle part ailleurs. De plus, il existe des moyens d'atténuer le système, dont des exemples peuvent être vus dans les jeux où, par exemple, il existe un pool commun de vitesse d'obturation / d'énergie / de points de vie, mais des blessures spécifiques surviennent soit à la suite de coups critiques, soit à la suite de l'atteinte de valeurs nulles ou proches de zéro dans la piscine. Le bon choix de système dépend du jeu. Nous nous efforçons d'utiliser le moins possible les chiffres, car les chiffres ne correspondent généralement pas bien aux histoires.
À quoi ressemble la boucle de jeu principale?Prenons par exemple le mode gnome. Il commence par vérifier les annonces et lire les enregistrements automatiques, etc. La majeure partie du reste du cycle ne se produit pas dans toutes les mesures. Par exemple, après chaque centaine d'horloges, le programme vérifie les tâches assignées et les «humeurs étranges». Les armées se déplacent sur la carte du monde. Après chaque centaine d'horloges, le programme traite les tâches confiées aux nains. Il s'agit d'une sorte d'enchère invisible utilisée pour gérer différentes priorités conflictuelles. Toutes les dix ticks, les saisons changent, ce qui affecte la météo et la carte (à la fois localement et dans le monde), ainsi que la vérification du développement des éléments de l'intrigue (diplomates, sièges, etc.) et la vérification de la vie du fort.
Ensuite, le programme reprend ce qui est fait dans chaque mesure. Les mouvements de liquides et d'autres informations sur les tuiles de carte changent (cependant, il existe diverses optimisations pour que chaque tuile ne soit pas nécessairement vérifiée à chaque mouvement; en outre, il y a des drapeaux qui vous permettent de sauter des zones entières de la carte si rien ne s'y passe.) Le mouvement des prédateurs est mis à jour et traité d'autres «événements» de la carte, par exemple des incendies actifs.
Si le drapeau est mis, les gnomes blessés / assoiffés / affamés qui ne peuvent pas prendre soin d'eux-mêmes reçoivent une mise à jour. Les gnomes morts «pensent» à leurs rituels funéraires afin que ces tâches puissent être attribuées à d'autres. Les êtres enfermés dans des cellules et des chaînes mettent périodiquement à jour leurs pensées et leurs situations.
Ensuite, si les créatures ont traversé les bords de la carte, elles en sont retirées.
Toutes les cinquante mesures, les informations de toutes les tavernes, temples, bibliothèques, etc., en fonction d'autres mesures, sont mises à jour. Les fournitures, qui dépendent également d'autres mesures, fonctionnent de la même manière. De même, la création de tâches de stockage. Malgré le fait que ce processus est complété par diverses optimisations, il est encore assez lent et à un certain point, plus de 50 000 pierres peuvent causer des problèmes.
Toutes les mille mesures, les objets marqués pour suppression du jeu sont réellement supprimés et la mémoire qui leur est allouée est libérée. Cela se produit plus souvent avec des objets, une fois toutes les cinquante mesures, ainsi que la vérification de l'utilisation des bâtiments (ce sont essentiellement des mises à jour pour les puits et certains autres drapeaux qui doivent être vérifiés souvent.)
Ensuite, nous effectuons une autre mise à jour qui fonctionne dans toutes les mesures. Les obus tirés de l'arme sont supprimés. Les actions (de la formation en danse et en arts martiaux à la narration) sont mises à jour au besoin. Les nains et autres créatures prennent des décisions et effectuent leurs actions instantanées (se déplacer vers une tuile voisine, travailler dans un atelier, etc.) - l'essentiel de leur IA (sauf pour choisir des tâches) est effectué ici.
Chaque centaine de mesures gâchent des objets. Chaque mesure de croissance de la végétation est effectuée (même s'il existe de nombreuses dépendances et drapeaux.) Si nécessaire, l'état des bâtiments est mis à jour dans chaque mesure et les chariots sont déplacés. Avance sur les itinéraires de transport. La température est mise à jour (il existe de nombreux indicateurs d'optimisation ici, mais jusqu'à présent, c'est encore un processus assez lent.)
Enfin, la caméra est mise à jour en fonction de la créature que le joueur regarde.
Dwarf Fortress utilise une carte de tuiles basée sur une grille pour représenter le monde, un moyen simple et efficace de le représenter. J'ai remarqué qu'il y a plusieurs façons de dessiner des tuiles, et cela dépend de ce que fait la créature ou de ce qu'elle ressent, du nombre d'éléments sur la tuile, s'il y a quelque chose au-dessus, si la tuile coule de l'eau ou est enterrée sous une pierre. Lorsque DF décide comment afficher la tuile, que fait-il? Comment avez-vous optimisé ce processus?Ce n'est qu'un symbole (octet) avec quelques octets de couleur supplémentaires, donc le système n'est pas cher du tout et nous pouvons simplement remplacer la solution sélectionnée avant de l'afficher à l'écran, et ne pas essayer de tout résoudre en même temps, et pour la plupart des carreaux, un seul symbole terre / mur suffit. Le programme se déroule de bas en haut, dans un sens, en utilisant la «hauteur» (les créatures sont au-dessus des objets, les objets sont au-dessus de la terre), changeant de temps en temps la décision. Néanmoins, malgré la présence de divers drapeaux et tableaux auxiliaires, beaucoup plus peut être fait. Il y a un petit tableau d'unités possibles qui peuvent être affichées dans chaque tuile, de sorte que le programme peut implémenter une animation image par image qui vous permet de voir chaque élément sur la tuile, même lorsque le jeu est en pause.