Génération Procédurale de Carte (1)

La génération procédurale de carte, voire parfois de monde complet (comprenant par exemple son histoire, ses factions, etc.) s’est imposée comme une méthode privilégiée d’offrir de la re-jouabilité à de nombreux types de jeux, en particulier ceux de stratégie ainsi que la plupart des « rogue-likes ». Nous allons l’employer pour le jeu encore non nommé, dont je vais détailler le développement au fur et à mesure que je le réalise. Qui utilisera pour ses tirages aléatoires (et alléger beaucoup ses sauvegardes) les méthodes développées dans mon article précédent.

Les premiers jeux à utiliser de la génération procédurale

Rogue, en 1980, est généralement crédité comme le premier jeu vidéo connuJe doute un peu qu’il soit le premier tout court du fait des nombreux jeux amateurs de l’époque, qui pouvaient circuler sur disquettes de mains en mains, ou sur les ordinateurs d’universités dans les années 70, et dont on n’a hélas gardé aucune trace. à en employer pour la génération des niveaux de son donjon. Lui même s’inspirait d’une méthode développée pour les jeux de rôlesPrésentée entre autres dans le Dungeon Master Guide de la première version d’AD&D (1977), et ayant existé dès Chainmail, son ancêtre). Ces jeux s’inspirant eux mêmes de la génération de cartes pour certains wargames tactiques encore plus anciens. .

Personnellement le tout premier jeu que j’aie rencontré à en utiliser (et pas de la simple génération aléatoire – voir plus loin) s’appelait justement Advanced Dungeons & Dragons, s’il ne s’agissait pas du jeu de rôles sur table mais d’une de ses premières « adaptations »Enfin un jeu très vaguement inspiré de l'univers de D&D, où il y avait des souterrains et des monstres, mais très peu d'autres caractéristiques du JdR. en jeu-vidéo par Mattel (jouable sur sa console Intellivision) : AD&D The Cloudy Mountain.

Comme on le voit une carte différente est générée pour chaque partie, mais si elles varient elles conservent une structure commune, elles visent à proposer la même série d’épreuvesDevoir traverser un certain nombre de montagnes de différents types/couleurs, correspondant elles mêmes à des donjons procéduralement générés, et selon le chemin choisi d’autres obstacles, nécessitant pour les franchir de récupérer des objets dans certains donjons. au joueur mais pas toujours dans le même ordre, si la génération de carte veille à ce que son parcours quelque soit son résultat reste globalement aussi difficile.

Approche « ludiste » ou « simulationniste » de la génération de carte

C’est ce qu’on appelle une approche ludiste de la question : les critères pour générer la carte de The Cloudy Mountain sont avant tout basés sur la nécessité de fournir une certaine expérience à un joueur, dont on connait le point départ et l’objectif. Le monde n’est là que pour répondre à ses attentes.

D’autres jeux allaient bientôt développer une autre approche de la génération procédurale, elle simulationniste.  C’est notamment le cas de Civilization, dès le premier opus de la série, et de la plupart des autres 4x. Ici la génération de carte s’attache avant tout à créer un univers réaliste (cherchant par exemple à simuler une géographie pouvant découler logiquement des mêmes facteurs que la notre, mouvements de plaques tectoniques, activité volcanique, etc.) pour avant tout favoriser l’immersion d’un joueur, susceptible de commencer le développement de sa civilisation en divers endroits de cet univers.

Plutôt que du parcours qu’il aurait à accomplir dans le jeu, on va partir de la génération du monde, et seulement ensuite lui sélectionner une place dans celui ci, en ne prenant en compte qu’au moment du choix de celle ci des facteurs de jouabilitéDans les tous premiers jeux à utiliser ce type de génération, comme Civ I et autres du début des années 90, il arrivait d’ailleurs souvent que le joueur se retrouve dans des positions de départ très ardues, par exemple sur une petite ile avec tout juste l’espace pour sa première ville, s’il était malchanceux. Ce n’est qu’avec le temps que leurs développeurs apprendront à lui éviter ce genre de problèmes, en faisant plus de vérifications. seront considérés.

Par la suite des jeux apprendront à marier ces deux approches, en adaptant leurs mondes générés pour offrir des régions de départ au(x) joueur(s), prévues pour qu’ils ne rencontrent pas trop rapidement de grandes difficultés, tout en ayant une approche simulationniste de la génération globale de leurs cartes, ou du déroulement du jeu une fois lancé.

Pour en prendre un exemple, un jeu comme Factorio va offrir comme option de création de cette carte de fixer la taille de cette zone de départ, où n’apparaitront pas de ruches de déchiqueteursLes ennemis insectoïdes du joueur. , tandis qu’y seront automatiquement placées des ressources nécessaires au développement initial du joueur. Par contre plus une fois qu’on s’en éloigne, la génération devient simulationniste, utilisant avant tout un système de biomesDifférentes régions qui vont favoriser l’apparition de tel ou tel terrains, ressources ou ennemis. dont l’apparition n’est pas reliée à la position du joueur. Et par ailleurs, une fois le jeu lancé, des déchiqueteurs sont susceptibles d’aller s’installer dans sa zone de départ, comme ils le feraient dans d’autres régions.

La génération aléatoire à l’échelle des cases

La forme la plus basique de génération procédurale de carte est ce qu’on appelle plus communément une génération aléatoire de carte. S’il y a bien une procédure, elle consiste juste, pour chaque case/élément de celle ci d’effectuer un tirage, qui va déterminer son contenu / le terrain correspondant en fonction d’une table unique de résultats possibles. Cela ne signifie qu’on ne puisse pas jouer sur les fréquences des différents résultats auxquels peut aboutir un tirage pour en favoriser un global, mais ce type de méthode ne peut aboutir qu’à des résultats assez chaotique.

Pour un exemple, voir le générateur de carte que j’utilise pour mon Portfolio*Oui j'ai parfois des idées assez bizarres. 😉 (qui visait à l’origine juste à tester un moteur de carte à hexagones, donc je ne m’étais pas vraiment foulé). Dont le code est tout simple :

S’il permet d’influer sur la fréquence des terrains, il va produire par exemple des montagnes isolées plutôt que des chaines de montagnes, et serait complètement inadapté à représenter un monde avec des rivières ou routes par exemple, qui nécessiteraient de prendre en compte d’où elles viennent et où elles vont.

Par contre combiné à la méthode de tirages pseudo-aléatoires développée précédemment qu’on va utiliser, cette approche a un grand avantage : il suffit de faire correspondre le numéro d’une case et son numéro de tirage pour facilement pouvoir en retrouver le terrain. Cela peut nous permettre par exemple de lancer une partie sans avoir à déterminer ceux de toutes les cases, juste de celles pour lesquelles cette information est utile (car on représente cette partie de la carte sur l’écran par exemple).

Revenons en donc à notre projet de jeu

Ce qu’on va donc faire c’est garder cette approche pour la plupart des cases (numéro de case = numéro de tirage qui va déterminer son contenu), mais tout en ajoutant une phase préalable à notre générateur, qui va permettre de faire tout ce qu’on ne pourrait pas faire dans une génération purement au niveau des cases :

• Définir les côtes de notre continent et autres bords de carte
• Générer des chaines de montagnes
• Générer des rivières ou des routes
• Et surtout définir des régions où les probabilités de tirer tel ou tel terrain seront différentes

Enfin déjà réfléchissons y…

Mais je vais un peu vite à parler déjà de continent, de montagnes, etc. Évidemment il y a une étape qui vient naturellement avant celle ci, se demander quel type de jeu on veut créer et quel type de carte lui conviendrait le mieux. Si on voulait faire un jeu se déroulant en intérieurs par exemple il n’y aurait aucune raison de se soucier de chaines de montagnes (mais par contre on le devrait de s’assurer que toutes les pièces sont accessibles plutôt qu’entourées de murs sans portes par exemple).

Et même une fois un type de carte décidé, le type de jeu peut beaucoup influer sur ce qu’il est nécessaire d’y représenter ou comment (dans un jeu axé sur l’économie, on veillera surtout à avoir des terrains associés aux différentes ressources exploitables, et une manière d’associer en plus des terrains des ressources particulières à des cases ; dans un wargame à représenter avant tout les terrains pouvant avoir une influence sur les combats ou mouvements de troupes, etc.).

Et des facteurs comme les cases même qu’on va utiliser aussi peuvent en dépendre :

• Pour un wargame où bien représenter les mouvements des troupes est essentiel, on utilisera généralement une carte à hexagones pour rendre les distances entre celles ci uniformes, ce qui évite d’avoir à complexifier le système de points de mouvement utilisé (sachant qu’avec des cases carrées, un mouvement diagonal fait se déplacer d’une plus grande distance qu’un horizontal ou vertical). Mais c’est nettement moins important pour des jeux où une telle précision ne serait pas importante, ou même des wargames qui souhaiteraient insister sur d’autres aspects.
• La série Field of Glory, par exemple, a montré que pour un souhaitant surtout faire plutôt de l’orientation de troupes peu manœuvrables le facteur essentiel  des cases carrées peuvent être plus appropriées.
• Quant à des jeux à plus grande échelle, celle qu’on appelle grand-stratégique typiquement, ils utiliseront plutôt des cartes divisées en provinces qu’en cases

Ce serait donc absurde de considérer la génération de carte sans avoir un minimum réfléchi au jeu…

Mes objectifs

A défaut d’avoir une idée très précise du jeu que je souhaite réaliser, j’en ai une de mes objectifs ce faisant :

• Un jeu qui soit un bon prétexte pour aborder le plus d’éléments de Game Design et systèmes de jeux que possible
• Qui tout en restant relativement classique ne vise pas à être le clone de tel ou tel autre jeu particulier
• Un jeu dont le code reste néanmoins assez simple que je puisse le poster et expliquer ici
• Ce qui implique aussi forcement, plutôt un style de jeu que je connais bien dans un environnement que je connais bien
• Sachant que j’aurai déjà du temps à consacrer à ces deux choses, un jeu dont l’univers ne soit pas particulièrement complexe à développer et expliquer
• Un jeu dont on puisse poursuivre longtemps le développement mais qui ne prenne pas des années à aboutir à quelque chose de jouable (surtout compte tenu que je n’ai qu’un temps limité à y consacrer)
• Il exploitera autant que possible les possibilités du générateur développé dans l’épisode précédent.

Ce qui m’a permis de trancher certains points :

• Déjà ce sera un jeu en tour par tour (vu que j’ai bien moins d’expérience du temps réel), et simplement réalisé en html/javascript que je n’aie pas à détailler les particularités du framework ou moteur utilisé en plus du jeu lui même.
• Les graphismes seront très old-school en 2d, sans trop de fioritures (il sera toujours temps de les améliorer à un stade tardif du développement). Par contre je vais apporter un certain soin à l’interface (car c’est un bon sujet).
• Le jeu empruntera beaucoup aux RPG, ce qui me permettra d’aborder des sujets comme la progression de personnages, les classes et/ou compétences, le scalingAdaptation à la force des personnages du joueur. ou pas des adversaires, le jeu à plusieurs échelles (passer d’une carte du monde à une carte de donjon ou autres combats tactiques par exemple – si un système de résolution plus abstrait sera sans doute développé en premier), les systèmes de combat en petit groupe, de magie, etc. Ce ne sera néanmoins pas un RPG à proprement parler, centré sur un seul personnage ou groupe de (à part peut être dans une première version destinée à tester cette partie du gameplay si on commence par là), je pense plutôt placer le joueur à la tête d’une organisation qui en gérera plusieurs et aura à aller recruter d’autres aventuriers pour se développer et remplir ses objectifs, et aura aussi une base sur la carteOu plusieurs, un des points non encore tranché., ce qui me permettra d’aborder d’autres systèmes que j’ai en tête, sur la gestion des PNJs, les constructions, avoir un système de recherches, etc.
• L’univers se devant d’être classique et facile à appréhender ce sera du bon vieux médiéval fantastique plus ou moins classique (ce qui m’arrange aussi pour les graphismes de la carte, ayant déjà une palette pour des terrains adaptés me venant de projets précédents), il sera toujours temps de donner plus de personnalité à cet univers ultérieurement.
• Pour ce qui est de l’organisation qu’y dirigera le joueur j’avais d’abord songé à une guilde d’aventuriers mercenaires, mais à la réflexion cela forcerait à aborder trop rapidement certains éléments (missions, relations avec des commanditaires, économie) que je garderais plus volontiers pour tard dans le développement du jeu. Un ordreQui pourrait être militaire, de chevaliers, religieux ou de mages, ou lui même dirigé par des entités surnaturelles ça reste à trancher ou à développer comme options peut-être. se donnant pour mission de protéger les royaumes alentours de menaces surnaturelles, thème revenant souvent dans la fantasyPoint commun entre le Conseil Blanc de Tolkien, la Garde de Nuit de GRR Martin et les Witchers de Sapkowski pour prendre quelques références littéraires. a par contre pour avantage d’avoir un but en lui même justifiant qu’il envoie des groupes d’aventuriers les affronter, sans exclure d’y ajouter à un certain stade un système de quêtes faites à la demande de PNJs et de relations avec diverses factions. Au niveau du jeu vidéo, ça rapprocherait aussi ce projet de jeux comme les UFO/XCom si le cadre sera évidemment très différent. Et également d’un de mes anciens projetsTrigger warning : le lien qui va suivre est vers une page extrêmement moche., White Council, si je ne compte pas nécessairement en garder beaucoup d’idées.
• Le jeu sera donc JcE plutôt que JcJ, et asymétrique (l’IA du jeu ne jouera pas d’entité équivalente à celle du joueur mais simulera les actions de divers PNJ et adversaires). Le multijoueur n’est pas totalement exclu (un bon sujet de développement tardif), mais le jeu sera plutôt fait pour du solo en premier lieu.
• L’objectif pour le monde, sera qu’il soit le plus vivant possible, avec divers groupes de PNJ qui s’y déplacent également, y vivant leurs propres vies, diverses factions avec lesquelles l’organisation du joueur peut développer des relations, etc. ce qui devrait compenser qu’il ne soit pas très original ni avec beaucoup de narratif.

Pour la carte ça va avoir les conséquences suivantes

• Des hexagones ou autre ne s’imposant pas absolument, on va faire simple et utiliser des cases carrées
• Le jeu insistant surtout sur un aspect aventure on va plutôt privilégier une grande variété de terrains. Mais ils n’auront pas à être liés à des ressources, l’économie n’étant pas un point central.
• La carte ne va pas représenter toute une planète mais plutôt un continent (pas de projet actuellement d’y inclure du voyage maritime, et si ça pourrait être considéré ce serait plutôt de la navigation côtière qui irait le mieux à un univers non technologiquement avancé de toutes manières). Le centre de la carte sera terrestre, et ses bords des barrières naturelles sur les 4 cotés ( soit océan, soit montagnes infranchissables ou désert de sable ou de glace)
• Dans la tradition med-fan aux univers typiquement inspirés de l’Europe, on va se considérer dans l’hémisphère nord pour les différentes zones climatiques de notre carte (des régions froides seront au nord, des chaudes au sud, à l’est il y aura plus de steppes à l’ouest une région plus tempérée).
• Il devra y avoir un mélange de régions civilisées (où interagir avec les factions / recruter des aventuriers) et de plus sauvages à explorer (où on trouvera le plus de repaires de monstres / donjons et des terrains plus accidentés). Le point de départ du joueur sera dans l’une des régions civilisées.
• Avoir des obstacles naturels comme chaines de montagnes, fleuves, etc est très souhaitable dans ce genre d’univers, de même que des régions centrées sur un type de terrain qui pourront être nommées (forêt de truc, marais de machin…). Par contre nommer toutes les cases serait superflu (ce ne sont pas des provinces).
• Les lieux de population n’étant pas énormes ils ne vont pas prendre de cases entières (sauf exception d’un petit nombre de cités), on les représentera plutôt avec un second calque par dessus un terrain existant (de même pour des ruines, donjons, tanières de monstres etc. qu’on pourrait vouloir ajouter).
• La génération de carte se fera donc en trois parties, détermination des régions, carte physique puis ajout des constructions/lieux spéciaux

C’est maintenant qu’on sait tout ça qu’on va pouvoir commencer à réaliser son algorithme de génération (qui sera abordé dans un prochain chapitre, il faut encore que je finisse de le coder et réalise les graphismes des cases).