Les péripéties de Pankee

Creating games since 1869 le blog de pankee.

[Castloid] Génération procédurale de donjon

Mercredi 23 janvier 2013 à 16:09

Image hosted by uppix.net

Génération procédurale de donjon

Des nouvelles du front !

Le projet avance bien. Le développement a commencé il y a peu, après plusieurs mois de conception. Nous sommes plus motivés que jamais, et bien décidés à faire un putain de bon jeu !
Attendez-vous à voir pas mal d’articles de développement à partir de maintenant, étant donné qu’on a bien envie de vous faire partager l’avancée du projet.

Au programme aujourd’hui, comment on génère nos donjons procéduralement, pour que les joueurs se perdent dedans.

Bonne lecture !

- - -

Tout d’abord, une explication de notre problématique.

Dans Castloid, le joueur explore un donjon en deux dimensions avec vue de profil. Le donjon se trouve donc sur les axes de hauteur et de largeur.

Nous souhaitions que le joueur entre par la salle la plus à gauche du donjon et ressorte par la salle la plus à droite. La hauteur donne une notion d’étages pour le joueur, un peu à la manière de Terraria.

Afin de générer un donjon cohérent et d’apporter au joueur une durée de jeu moyenne pour un donjon d’une même taille, nous avons dans un premier temps décidé de séparer la génération du donjon en 2 grosses étapes :

- La génération du chemin principal, allant de l’entrée où apparaissent les joueurs à la salle de fin où ils devront affronter un Boss avant de pouvoir ressortir.

- L’ajout de chemins secondaires afin de permettre aux joueurs de choisir différents chemins pour avancer dans le donjon.

Modèle de données utilisé

Dans un premier temps, il nous fallait déterminer comment stocker toutes les informations nécessaires. Nous sommes partis sur un modèle de données assez simple :

Chaque salle possible est un doublon d’entier <Int32, Int32>. Le premier entier contient diverses informations sur la salle (portes ouvertes vers haut bas gauche droite, est-ce l’entrée ? la sortie ? etc…). Le second indique l’identifiant du chemin sur lequel se trouve la salle.

Les salles sont stockées dans une map ce qui nous permet de voir directement les salles qui sont mitoyennes.

Le chemin principal

Pour obliger le joueur à traverser un certain nombre de salles afin de rejoindre la fin du donjon, nous avons déterminé une taille du chemin principal proportionnelle à la taille maximum du donjon (30% environ).

Pour la création du chemin, tout débute à la sortie, nous utilisons un système de poids assigné à chaque direction possible.

Le poids de chaque destination est déterminé par un certain nombre de facteurs. Plus une direction a été utilisée précédemment, plus le poids de cette direction est faible, les poids des directions gauche-droite sont plus forts par défaut que les poids des directions haut-bas.

Enfin, prévoyons que la dernière salle du chemin principale soit la plus à gauche avant d’être considérée comme l’entrée.

Voici un exemple de chemin principal (Taille du donjon : 100 salles, dont 30 dans le chemin principal) :

Les chemins secondaires

Pour l’instant, nous avons un chemin principal, on avance de salle en salle, sans aucun choix et on arrive à la fin. Pour augmenter le plaisir de jeu et la durée de vie du jeu,  on doit ajouter des chemins secondaires qui peuvent augmenter la taille du chemin total à parcourir ou la diminuer.

Dans un premier temps, nous avons découpé le chemin principal en multiples sections verticales de tailles fixes, puis nous enregistrons le nombre de salles que chaque section possède.


Ensuite, l’algorithme qui génère les chemins secondaires entre en jeu. Tout d’abord pour déterminer le point d’entrée, on se focalise sur la section qui possède actuellement le moins de salles du donjon. Dans cette section, on détermine aléatoirement la salle qui sera désignée comme le départ du nouveau chemin. Pour cela, on vérifie d’abord que cette salle possède au moins une porte libre (c’est-à-dire une porte qui mène sur une salle vide).

Après avoir déterminé la salle de départ, on crée le chemin secondaire de la même façon que le chemin principal avec des contraintes différentes qui sont la taille du chemin secondaire, les possibilités offertes par les salles proches et enfin si la salle de fin de chemin secondaire possède une salle proche qui satisfait certains critères, on lie ces deux salles.

On répète l’opération jusqu’à obtenir le nombre de salles voulues.

Maintenant, on possède enfin un donjon avec une entrée, une sortie et des chemins secondaires. Un nouveau problème se pose, les impasses.

Pour repérer les chemins qui se terminent sans rejoindre un chemin principal ou secondaire, il suffit de parcourir la map et de repérer les salles avec  un seul lien vers une autre salle (sans compter l’entrée et la sortie), puis, on remonte le chemin en supprimant les salles en trop jusqu’à rencontrer une salle avec 2 liens vers d’autres salles (sans compter la salle précédemment parcourue).

On remarque maintenant que le donjon qu’on a actuellement n’atteint pas le nombre de salles initialement passé en paramètre, il suffit de répéter les deux étapes précédentes jusqu’à obtenir le nombre de salles voulues et on obtient un donjon sans impasses et avec le nombre de salle souhaité.

La dernière étape est la différenciation des salles en plusieurs types. Les salles spéciales qui accueilleront les waypoints et les magasins, les salles de mini-boss et les salles de boss.

Pour cela, nous réutilisons la méthode de la division de la map en sections pour répartir les salles spéciales.

Puis nous plaçons une première salle spéciale sur une salle déjà existante. Pour les salles spéciales restantes, nous cherchons les sections possédant le plus grand nombre de salles existantes avec le moins de salles spéciales et nous plaçons à nouveau une salle spéciale.

Lorsque toutes les salles spéciales sont placées, on vérifie qu’elles sont éloignées les unes des autres en vérifiant qu’aucun lien direct ne les relie.

Les salles spéciales sont ici affichées en orange.

Ensuite, nous réitérons la même opération avec les salles contenant les Mini-Boss.

Les mini-boss sont affichés en violet.

Dernièrement, on place les salles contenant les Boss. Une première salle sera automatiquement placée devant la sortie. Ensuite, les salles restantes seront placées dans les sections centrales.

Et enfin, la map finale, avec les boss en rouge.

Une logique très simple donc. On a voulu conserver quelque chose d’assez simple, mais qui permettait d’obtenir assez rapidement des résultats très corrects. On est actuellement très heureux des maps que ça nous donne, et on pense que les joueurs apprécieront.

Vous pouvez avoir la même chose en anglais sur notre blog de développement : http://blog.dynamiteskunk.com

Et n’hésitez pas à nous suivre sur Twitter pour avoir les dernières news de développement !

Après quelques mois de travail sur le projet, j’ai jugé bon de commencer à parler du jeu sur lequel je travaille actuellement en tant que chef de projet.

Actuellement étudiant en école d’informatique, nous avons un projet libre à réaliser sur l’année. Désirant créer un vrai jeu depuis quelques années déjà, c’était l’occasion rêvée de s’y mettre. Me voilà donc aujourd’hui, travaillant sur le jeu de mes rêves avec l’aide de 5 autres développeurs et 2 graphistes. Le projet dure jusqu’à la mi-avril, et nous sommes actuellement en phase de conception, avec le gameplay du jeu bien défini et la majorité des étapes de programmation réfléchies.

Présentation

Project Castloid est le résultat du mélange malin entre jeux du genre Metroidvania et Roguelike, le tout en coopératif. Les joueurs se retrouvent ensemble et doivent tenter de coopérer pour survivre aux différentes épreuves qui les attendent dans des châteaux générés procéduralement. Le jeu emprunte le meilleur des deux genres précédemment cités : la séparation en salles et l’exploration des Metroidvania, le côté “Losing is fun” et la génération procédurale des Roguelike. Le rajout de la coopération, chose qui m’a toujours manqué dans les Roguelike (même si son absence est tout à fait compréhensible d’un point de vue gameplay), permet l’apparition de scènes assez tendues/comiques :

  • Vous avez une potion rouge dans les mains, mais ne connaissez pas son effet. La salle dans laquelle vous vous trouvez actuellement se trouve être plus compliquée que prévu et la difficulté se fait ressentir. Que faire avec cette potion ? L’utiliser sur vous-même, en espérant qu’il s’agisse d’une potion de soin ? Ou la lancer sur votre candide coéquipier pour tester ses effets ?
  • La salle est enfin débarassée de ses ennemis, mais voilà que la prochaine porte nécessite de l’argent pour être ouverte. Allez-vous prétendre ne plus en avoir et laisser vos coéquipiers sortir le porte-monnaie ? Une fois celle-ci ouverte, libre à vous de les laisser entrer dans la prochaine salle et de trouver un autre chemin. Ceux-ci ne pourront sortir tant qu’ils n’auront pas vaincu tous les ennemis, alors pourquoi ne pas attendre qu’ils se fassent poutrer pour prendre leur précieuse arme, sur laquelle vous avez tant bavé ?

Le jeu, comme vous l’avez peut-être compris, met en place une coopération “forcée”. Les joueurs sont obligés de s’entraider pour terminer le château à cause de la difficulté très élevée, mais toutes les occasions sont bonnes pour jouer un tour à son partenaire.

Features

  • Châteaux générés 100% procéduralement.
  • Armes générées procéduralement également, à la Borderlands.
  • Gameplay orienté multijoueurs.
  • Difficulté adaptative (voir ci-dessous)

Dans Project Castloid, la difficulté s’adaptera au niveau des joueurs. Inspiré du jeu God Hand sorti sur PS2, ce système permet de récompenser les meilleurs joueurs avec un challenge accru et de ne pas frustrer les débutants avec des épreuves impossibles. Par exemple, si les joueurs enchaînent plusieurs salles rapidement sans se faire toucher, la barre de difficulté augmentera, influençant la vie des ennemis ainsi que d’autres facteurs du gameplay. Néanmoins, le jeu étant principalement dédié aux “hardcore gamers”, celui-ci restera globalement dur, et plusieurs modes “Hardcore” seront présents.

Premières ébauches

Pas de vidéo, ou même de screenshot pour l’instant, le développement n’ayant même pas commencé. Quelques ébauches des graphistes cependant.

  • Ennemis

demonedevil_zora_copie

  • Boss

mammoth

  • Un des personnages jouables (avec des chapeaux §§)

chapeau01cuistopiraterasta

  • Animation de course du joueur (encore quelques modifications à faire)

run

Voilà qui devrait conclure cet article de présentation de Project Castloid ! Comme vous l’avez probablement deviné, le nom est temporaire, et nous sommes d’ailleurs à la recherche d’idées. Si l’envie vous prend !

Merci de votre attention, et je suis ouvert à toutes remarques, critiques, ou louanges ! Surtout louanges.

Si vous ne désirez, ou ne pouvez pas poster de commentaire, n’hésitez pas à m’envoyer un e-mail à l’adresse suivante : pan@dynamiteskunk.com