Roguelike

Je voudrais archiver ici mes réflexions et apprentissages durant le développement de ce projet.

Description du projet

Faire un roguelike, un jeu d’exploration de donjon en TypeScript avec plusieurs moteurs de rendu. Le moteur de jeu étant commun à tous les moteurs de rendu.

Mes buts sont :

Apprendre plus TypeScript dont je ne connais que les bases
Apprendre à utiliser node pour faire des interfaces CLI
Apprendre à utiliser Phaser
M’amuser

Moteur de jeu

Actuellement les fonctionnalités planifiées sont :

Moteurs de rendu

Actuellement les moteurs de rendu planifiés sont :

ASCII comme le rogue classique
Vue 2D plate
Vue isométrique à la Diablo https://phaser.io/examples/v3.85.0/tilemap/isometric/view/create-isometric-manually
Vue 3D à la Lands of Lore: The Throne of Chaos
Vue 3D à la DOOM https://phaser.io/news/2026/04/twopointfive-pseudo-3d-phaser-3-plugin
Vue 3D https://enable3d.io/

Journal

2026/04/06

Début du projet.
Pour commencer je vais développer en parallèle le moteur de rendu ASCII et le moteur de jeu mais ensuite il faudra les séparer en module avec des dépendances séparées.

Packages

Pour utiliser un package dans TypeScript via import il faut aussi installer le package @types/[package] :

npm install --save readline-sync
npm install --save-dev @types/readline-sync

--save-dev car on n’en a besoin que pour le développement. En production on a directement du JavaScript donc on utilise le package directement.

Ce qui permet de faire

import * as readline from 'readline-sync';

Pour l’instant le moteur de rendu va utiliser node pour l’accès au terminal, readline-sync pour la gestion des touches, chalk pour la couleur de texte. Donc package.json ressemble à

{
	"dependencies": {
		"chalk": "^5.6.2",
		"readline-sync": "^1.4.10"
	},
	"devDependencies": {
		"@types/chalk": "^0.4.31",
		"@types/node": "^25.5.2",
		"@types/readline-sync": "^1.4.8"
	}
}

Edit: finalement readline-sync n’est pas utile. Je n’arrivais pas à faire fonctionner les flèches avec et readline, de base dans node, fonctionne bien.

Donc pour l’instant

les deux moteurs sont bien séparés, il n’y a que les définitions des interfaces qui sont communes mais on verra cela plus tard.
Le moteur de jeu créé un niveau vide, je regarderai la génération des salles plus tard mais il gère déjà les différentes tuiles et différentes entités
Le moteur de rendu affiche le niveau, les entités capture les appuis sur les flèches, transmet au moteur de jeu qui gère les déplacements et demande un nouveau rendu.

2026/04/08

Le mot “dungeon” est un faux ami qui signifie “cachot”. Je pensais qu’il y avait une confusion entre un niveau du donjon, appelé “dungeon” et le donjon tout entier mais le monde du jeu est un ensemble de cachots, au sens large, que le joueur explore. C’est aussi pour cela que le joueur descend, il va dans des cachots de plus en plus profonds et dangereux.

https://github.com/halftheopposite/bsp-dungeon-generator créé des donjons très avancés. Idées à retenir :

roomTemplate : les monstres et objets ne peuvent pas apparaitre dans n’importe quelle salle. Comme une plante au fond d’une cave ou un troll des caverne dans un chateau. ça permet de lister les possibilités d’une salle pour qu’elle reste logique.
seed: pour sauvegarder un monde il suffit d’enregistrer la seed qui a été utilisée pour le générer.

🐢 ShagshagUn pas après l'autre

Tags