I have a habit of writing one of these every few years. In 2017 it was a 7DRL experiment merging a roguelike with an FPS, and in 2019 it was ascii characters embedded into a 3d map. This year’s entry is different: DET-33, the bullet-hell roguelike I built in JS and Phaser over the last few months, is feature-complete and plays great. So naturally I’m rewriting it from scratch in Godot 4 and C#. ...
I spent a good chunk of last year writing about compass, the map-generation library with all the fluvial generators and cellular caverns. The whole time I was building it as a standalone library, the real motive was to eventually drop it into a game. This month I finally did, and DET-33 now generates every one of its floors through compass. Pulling the library in Wiring it up was almost anticlimactic, which is the point of having spent the time on the composition layer. DET-33 pulls compass in as a git dependency and the level code just imports the scanning digger and the template data: ...
After getting the bullet behaviors in DET-33 into a good place, the next system to crack was skills: the active abilities a player picks up as they level. I’d built ability systems before and always regretted the same thing, so this time I restructured them to be stat-agnostic from the start. The mistake I keep making The tempting way to define a skill is to reach into player stats. “Healing scales with your wisdom, damage scales with your level.” It feels right and it ruins you later. Every skill becomes coupled to the stat model, balancing one thing ripples into everything, and you can’t reason about a skill in isolation. Years ago I wrote about balancing game mechanics by drawing the tree of which stats feed which. The lesson I took from doing that is that the fewer edges in that tree, the better, and skills reading stats directly add a lot of edges. ...
This fall I started building a new game: a bullet-hell roguelike called DET-33, built on Phaser 3 and Vue. It’s the kind of game where the whole appeal is hundreds of projectiles on screen doing wildly different things, which means the weapon code becomes the heart of the project very quickly. Mine started as one weapon.js file, and it did not stay manageable for long. The problem is the obvious one. A bullet that travels in a straight line, a bullet that spirals, a bullet that boomerangs back, a bullet that splits on impact, and a bullet that drops an acid pool are all “a bullet,” but the branching to support them in one file gets ugly fast. So I tore weapon.js apart and rebuilt the projectiles as composable behaviors using the strategy pattern. ...
Building games has become easier to do with the increase in quality of tooling and specialization software. The unfortunate side effect is the developer has to become more trained and specialized in a variety of facets in order to maintain competency in the field. Ergo building games is also harder. This year for the 7DRL competition I’ve been pretty lazy, which doesn’t help much to making deadlines. Setting aside playing games for making games I decided to finally venture into the competition whole heartedly. ...