Lines of Fire: Thinking about modular board game design

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.

Lines of Fire — Evolution of a Prototype

During my vacation this summer, I somehow ended up designing a board game. The idea came to me strangely — I had seen a board game in a dream, but all I could remember when waking up was an image of what the board looked like. I thought it looked a bit like Bomberman, and that’s when I had the idea — why not take the gameplay from Bomberman and put it into a board game.

Creating the first prototype took only a few hours, and I thought I had a somewhat fun game. I called it Bombarena.

A lot of testing followed, first by myself and then with others. I’ve put tens of hours into it since then and made tens of smaller and larger improvements. Version 0.2 got only a couple of play tests, but I took some suggestions from the players and it was soon replaced with version 0.3, which added cards to spice up the game.

Version 0.4 is in progress and for now I’m mostly focused on simplifying, clarifying, balancing and polishing. I gave the game a new name “Lines of Fire”, rewrote the rules (PDF), which should be pretty solid for the main game variant now. I imagine that the basic rules will not change too much any more — what remains is mostly balancing; further play testing will tell if I’m right. I also created new tokens and improved the look of the board (making set-up related elements stand out less).

The next version will probably focus on balancing the ability cards and I hope to make it available for wider play testing soon, in a Print & Play form. I’m finding that open source/free software (such as Inkscape, Scribus, Foxit Reader) has all kinds of issues with printing, though, so making good printable documents available is a bit of a challenge.

Ziggy Returns, Rewritten in Scala

For about three years already I’ve been working on and off on a server/bot that runs Interactive Fiction games on web forums, effectively turning the single-player text adventure games into cooperative. The beta version launched at Idle Thumbs more than a year ago, but unfortunately it had some problems that made it crash regularly, and I didn’t find the time to fix them.

We’ll, a couple of weeks ago I decided to take the time and rewrote the main server code in Scala. That took only about a week and a half, the bot is now live again and running Hitchhiker’s Guide to the Galaxy. There are still several Java libraries in use of course: Z-Machine from Zinc, Bulletin Board API and ECF, Velocity, HTTPClient etc. But the main server code is now written in Scala.

My main goal for this rewrite, besides switching to Scala, was to simplify the architecture (back to the roots, I guess): the previous architecture was becoming too enterprisey for such a small project. It had too many layers of abstraction, some multi-threading issues made the code hard to debug, and using an OSGi runtime proved to be not that useful in my context. I still think OSGi is great, but sometimes simplicity is even better :)

Thankfully, ECF still works outside of OSGi and only requires two libraries from Equinox. By dropping OSGi, I could simplify the build process (or at least move it to what I’m more comfortable with – Maven). On the server I’m simply launching a Scala object with a main method instead of an OSGi runtime and that is good enough for this project.

The management console application was dropped as well, but I’m exposing some MXBeans on the server so VisualVM or JConsole can be used for management. Web-based management is planned for the future.

Another simplification was dropping some layers of abstraction and removing code that was there only to support hypothetical future features (such as games on IRC and IM, many Interactive Fiction VM implementations etc.). I may be adding some of those layers back in the future, but for now the code should focus on making the core functionality (running a Z-machine game in a vBulletin or phpBB forum thread) as good as it can be.

Perhaps the most improvement that came from this rewrite was that Scala code tends to be about two times shorter than equivalent Java code, as I aslo experienced with my Scala port of Box2D, which I mentioned in a previous post.

But I would say that using Actors for communication between different threads has also gained me some simplicity and I was now better able to understand and fix some of the concurrency issues that used to make the server hang. However, I wasn’t able to move to a completely Actor-based communication model yet, as some of aspects of the messaging between the Z-machine and the forum bot still seemed easier done using other methods, such as blocking queues. Maybe I just don’t know enough about actors yet.

Overall, I’m happy with the result so far and since I find programming in Scala to be more enjoyable than Java, I think I will be more motivated to further develop Ziggy and keep it running smoothly from now on.

Modelling Game Entities Using Traits

For a while now I’ve thought that Scala would be a good language to write games in. Well, I’m putting those thoughts into practice: I resurrected a couple of old game ideas and am now working on a 2D game or two as hobby projects. I decided that it would be a good idea to try my hand on simpler games before I embark on a longer project (which will likely be a platformer), so the one I’m working on now is something of a mix between Breakout and Peggle.

As part of writing those games, I’m also designing a generic game entity system, which will be integrated with Slick2D (for graphics, sound, input and other stuff) and a Scala port of Box2D (for collision detection and physics) that I’m also working on. So far I am very pleased that I chose Scala for this project — the code is generally more concise than Java (requiring roughly 2 times less lines), but what I like most is that traits, pattern matching plus some other features make Scala a great language for building components.

With the entity system I’m trying to take full advantage of that, implementing the building blocks for entities as traits that deal with different concerns. Some of these traits only define an interface for some type of behavior, but some also implement it, reducing the amount of code needed in concrete entities. Here are some of the most basic traits I’ve got implemented so far and descriptions of what they do:

Entity – the base trait for all my game entities, which extends Updateable, making it able to act on updates (or “ticks”) from the game engine during each frame.

PhysicalEntity – can be mixed into an entity class to add a physical body to an Entity, which takes part in the physics simulation and collision detection.

GraphicalEntity – adds a render method, which the entity can implement to render itself.

WithStates – for more complex entities that behave differently depending on their current state. For example a camera in a sneaking game may have states “Off” and “On”. In the Off state, the camera might not do anything, but in the On state it might be listening to some game events to react to seeing the player. To do this, a specific state (which are implemented as internal classes of the Entities) could mix in the Updateable and/or EventListener traits to react to events differently when that state is active. Additionally, defining state transitions can limit how the entity moves from one state to the other and allows to run some code when the state changes.

EventListener – an entity (or one of its states) with this trait will receive notifications of events it is interested in. This can be used in other objects besides entities and states, but only the latter two are automatically registered as listeners in the event queue.

Environment – this is the container for entities, the physics world and the event queue.

This is not all, but these are the most basic building blocks. Here is the code for a simple entity that makes use of some of these:

class Paddle
    extends PhysicalEntity with GraphicalEntity
    with EventListener with GameStateAware[InGame] {

  // we define the physical body for the PhysicalEntity
  val bodyDef = new BodyDef
  bodyDef.pos = (0,-10)
  bodyDef.fixedRotation = true
  bodyDef.allowSleep = false

  // the radius at which the paddle moves around world center
  val radius = 10
  // keeps track of the number of balls shot from the paddle and currently in play.
  var ballsInPlay: Int = 0
  def noBallsInPlay = ballsInPlay == 0

  // we call a convenience method of the EventListener to listen to some specific kinds of events
  listenTo {
    case ce @ ContactResultEventBetween(body1, body2) =>
      val other = 
        if (body1 == body) body2
        else if (body2 == body) body1
        else null
      if (other != null) {
        gameState.scorer.hitPaddle(this, other.userData.asInstanceOf[PlayerBall])

  // we override the function that is called when a PhysicalEntity is inserted into the world
  override def enterWorld(w: World) {
    val shape =, 0.1f)
    shape.density = 0f

  // define the render method to render the paddle (currently just rendering the physical body as a placeholder)
  def render(g: Graphics) = {
    import org.newdawn.slick.Color
    rendering.RenderUtils.renderBody(g, body)

I am already pleased that I was able to separate the different basic concerns using Scala’s traits and making them easily composable as seen above, but I hope that the real benefits should become apparent in a larger game with lots of different entities. Mick West talks about creating game entities as components in his blog post “Evolve Your Hierarchy” – I think he is right and that Scala’s language support for this (especially in the form of traits) is better than in C++ or Java, where you could do something similar with inheritance, interfaces and object composition. Note: I’ve never been a professional game developer or even got to the point of releasing a hobby project to the wider audience so I’m not speaking from reliable personal experience exactly, but I’ve worked with a few entity systems and this just seems right to me.

I will post more about this in the future, hopefully after having released a simple game :) and I’m considering releasing the code for the entity system under an open source license.