Long time no blag. Last time I wrote about a board game I’m working on. I actually let the project lay dormant for a few months, because I wasn’t completely happy with the design and was hoping to come up with new ideas after a pause. Which I did, but I’ll talk about those on some later date.
The idea for Lines of Fire started with Bomberman and the first prototype wasn’t much more than the multiplayer Bomberman formula turned into a turn based, physical game. Later I started adding a completely different theme, which might actually end up working quite well. I also experimented with other additions that had nothing to do with Bomberman. And I think I’m going to continue on that route, because maybe Bomberman isn’t such a well-designed game after all, or at least doesn’t directly translate into a well-designed turn-based game (or at the very least, my translation was poor). I think this might let down the players who already played it and liked its similarity to Bomberman, but if I manage to turn it into a better game than it was, then that’s fine. The core of the game will still retain some (or even a lot of) resemblance to the first prototype, though.
At the moment I have several new ideas that I think are really cool, and I wrote them down as a preliminary additional rules document. I stress “additional”, because I want to keep the game modular. It’s mostly because I have done so much experiments with variants that I’ve later reverted that I just don’t have a vision for a single set of rules that would be the one true embodiment of the game idea. Maybe the lack of such vision means that I shouldn’t be designing this game in the first place, or should just do my best with one variant, but at the moment I’m hoping I can in fact come up with some set of modules that players can combine to play the game the way they want to play it. This idea crystallized for me today, after listening to a recent 3MA episode about modding, modularity and house rules in board games.
Modularity and moddability make me think about software. I think we understand software modules pretty well, and why not try to actually create the game rule/component modules as software modules. Modelling a game as software should give it another desirable property: as long as I’m modelling the game systems well enough as type-safe code, I should be able to find problems in the rules that I won’t find if they are just paragraphs of text in a document. I should also be able to find corner cases, and verify properties about the software (although I’m not going quite as far as to use something like Coq for this, I’m probably sticking with Scala) which implicitly verifies the game rules as long as they are directly based on that software. It should also help me test changes to the rules by myself without having to do a lot of work and setup with physical game pieces.
As a result of such thinking, I have in mind a small project to start turning the current game rules into a set of software modules. I should have a tool that lets me play the game digitally, with just a crude visual representation and ability to control multiple players in turns. The game components and rules should be modular, so that for each play I can turn some modules on and off, or modify their parameters. When I have implemented the game in its current state, I can find problems with the rules and hopefully simplify them by refactoring or modifying the program.
What I want to achieve in the end is that the modules being represented in software actually enable me to find the best places for the module boundaries, and a way to get to a really small core module that can be learned and played quickly, with other modules that can be layered on top of that to make the game more interesting. I’m also hoping that I will then find a good way to lay out the modular rules in a linear rulebook so that the modules are easy to combine and the book itself easy to use for reference.
Mayhaps I will document this process somewhat on this blog, or on BGDF.