As a follow up to my last post I thought I'd talk a bit about the technical side of 7 Day Roguelike for me.

Rehackable Codebase

So if you look at my last 3 years of 7 Day Roguelikes together you'll probably notice some similarities. Yes, unsurprisingly these are all built on the same core tech.

Calling it a "Game Engine" is definitely a bit grandiose for what it is, but essentially each year I have taken the same codebase, stripped out all the stuff that is specific to the last game I made and kept all the reusable bits. My intent with this is not to create a pristine perfectly abstracted framework that never needs to be modified, but rather to create a codebase that can be modified and hacked quickly during a jam to achieve whatever I want to achieve.

I'm sure I've seen this idea expressed by someone else before but I can't remember where, but there's definitely a difference between a codebase that's designed to meet every need be perfect and unchanging, and one that's designed to be hackable. Often the latter is better for getting things done quickly. During a jam my general policy is to focus as much as possible on getting stuff done and not get bogged down refactoring or worry about architecture. The result is that often it's a mess at the end, but anything I learn coming out of that can be applied during the "strip out and refactor" phase between years.

The Joys of Web Development

Philosophising about architecture aside, the actual codebase is written in Typescript is really built more like a web page than a traditional game. My idea was that in a traditional turn-based roguelike you wait for the player's action, update the game state and then redraw the UI. You don't really need to be doing "stuff", rerendering at 60fps like a game between button presses. Making it like an interactive web page works for this interaction model.

Having a good web build is, in my opinion, essentially for small spare time projects and jam games like this. It just lowers the bar for getting people to play your game by so much, and generally reduces weird technical headaches and "it runs on my machine" problems. Everyone's PC has a working web browser on it, and people won't need to install the MSVC++ Redistributable to play your game without a weird error, or worry that they are downloading a virus. Most game engines can do web builds fairly well now (with a notable exception) and Emscripten + SDL also works for non-engine games, but making it a web page first offers a nice experience with a small final compiled build size.

I use React as the UI framework for the project. Actually, that's a lie: I use Preact which is a reimplementation of React which is supposedly smaller and faster. I made this decision ages ago and it has just worked without me really thinking about it since. Aside from that my set of runtime dependencies is fairly small, with a few UI utilities like icons and a library for Perlin noise which I have used for a few odd bits of procedural generation. I quite like (P)React in general, I find it quite nice for making dynamic UI pretty easily. There is sometimes some friction around use of state and other React "hooks" but it's widely used enough that someone has solved your problem already and put the answer on stack overflow.

The Roguelike Bit

The core game logic is really a classic "big blob of mutable state" style game, with a general framework that has now been refined through a few iterations. I have some essential roguelike algorithms like pathfinding and FOV calculation built in and ready to go (but also ready to be hacked to the specific needs of a project). 

Some of the architecture was inspired by this talk by Bob Nystrom - rather than anything resembling an "ECS" I have game objects like items and entities that have optional "capability" subobjects that describe what they can do. Actually this hasn't always worked super well for me and I am thinking about changing it up a bit. I also have some messy code that manages the set of entities within a level and keeping track of their positions to do reverse lookups ("where is this entity" vs "what entity (if any) is at this position") that is inconsistent in sometimes handling entities by their index in a master "turn order" list and sometimes just passing around a reference to the actual object. So really this part of the code needs an overhaul.

In terms of procedural generation, so far I have ended up doing something quite different each year. KROK had traditional dungeon floors using a "prefab rooms stuck together to build outwards" style algorithm, MineRL had an "infinite" generated-on-demand asteroid, and most recently Rogue's Bounty has a complicated system of placing island that have their terrain generated by a Cellular Automata. I have kept around the "prefab rooms" code throughout though as that's been my favourite approach to generating dungeons and is quite versatile if you are clever about setting up the prefabs.

What's next?

I have actually been thinking about trying to build out Rogue's Bounty into a bigger game between 7DRLs. There are a few architectural issues I would like to improve:

• Core data model - as touched on above, how I handle entity data needs an overhaul. Supporting serialisation (saving and loading the game) would be a big bonus here, to include in any redesign, as it would be a little painful to bolt on to the existing system.
• Switch over to using hashing to generate random numbers instead of Math.random() - my use of randomness for procedural generation has been slapdash and is not at all repeatable since you can't seed Javascript's builtin Math.random(). Getting stable world generation by using hashes would be very nice.
• Change the enemy AI from being completely hand written to some kind of better structured system - probably behaviour trees

I think I would try and make these big changes while keeping the game working exactly as it is now, and then once those are in start building out more content/improving the gameplay. Big dreams, I'll see how far I get.