blog.lukenoonan.com

[this post originally appeared over on the RUST LTD. blog]

In the previous post I talked about the initial development of 1887 as part of my MFA thesis. Like many of the games from that period of my life, I had shelved 1887 to make way for other projects. As anyone who has done a graduate degree will tell you, once you are able to finally stop working on a previously all consuming thesis/dissertation project, it can be difficult to go back. This was worse for me because I had mostly left the academic life. Most games I had worked on during my MFA were interesting from an academic perspective but not all that compelling otherwise.

So last year I found myself chatting with my friend Marc ( @destem ) about working on a project together. I was pitching a couple of projects I had been mulling over but didn’t have time to work on. Among other ideas I pitched doing a digital version of 1887. It wasn’t a project I had thought much about.  It did have a couple of things going for it:

• It wouldn’t take a ton of art assets to get rolling. This was  good because neither of us are game art people.
• I thought it might be fun to work on the AI with Marc. Besides being a game designer he also studies stuff like Cognitive Science, Psychology and Computer Science. (Working on designing AI with someone like that sounded like my kind of good time.)

Multiple Pieces

Later that day Marc came back to me with a working prototype. That prototype had a little surprise. Instead of one piece per player there were two. I don’t remember exactly what Marc said when I pointed that out but it was something like “it seemed like there should be two”. As I played the prototype, I realized that having options for which piece to move dramatically increased the strategic depth. It gave the player approximately double the available moves and allowed for new tactics. I was a little embarrassed that the initial version of 1887 didn’t feature multiple pieces per player. That is the nice thing about working with other designers, sometimes it takes a fresh set of eyes to see the obvious.

The way Marc designed the system allowed for an arbitrary number of players on either side. Throughout the process of development and re-development that design pattern has persisted. Over the course of development I would test boards with more or less pieces.  I would also try asymmetric setups in which one player has more than the other. So far, the only time that these other setups have proven useful has been for tutorial maps.

Tree mechanic

A few days after the initial prototype I was thinking about the tactical possibilities that having multiple pieces afforded. One idea bubbled to the surface of a situation where one of a players pieces would get stuck and the other could come and free it. The forest tile mechanic is what I came up with. Here is how they work:

1. A player can not land on a forest tile.
2. When a player settles a tile which is next to a forest, it causes the forest to become a field.

This mechanic succeed in creating the rescue situations I had imagined. It also created some other cool ones. For example, sometimes you can manage to trap an opponent against a row of forests only to realize that if you move one of your pieces you will clear some of those forests and free them. Those are the type of interesting situations I am interested in creating for my players.

Development

Over the next couple of weeks development continued. I started thinking about what would be necessary to get this project from prototype to complete salable game. The prospect of writing the AI for the game sounded like fun so my plan was to have a “campaign mode”.  In this mode you would play against bots on a pre-determined sequence of maps. Local multiplayer was already working so that was an obvious choice. Online multiplayer was also something we were considering.

One of my major concerns when it came to this sort of scoping was the issues that multiplayer indie games run into. For example, I bought my copy of Nidhogg at launch but have only gotten to play it a couple of times for lack of willing friends. (wow that sounded sad … ). Even online multiplayer can be difficult to manage because you need a critical mass of players to maintain a community, and that can be difficult to create without a big marketing budget. Toward that end I was nervous to launch a game without enough content to entertain our friendless players. I wanted to make sure the game would still work with a small user base. Also, network multiplayer can be an intimidating prospect development wise.

It was with all these thoughts rolling around in my head that I came up with the idea of Puzzle mode. Puzzle mode would be a single player mode where the player attempts to cover as much of the board as possible before she gets stuck. Given the way we had architected things it was easy to put together a single player map. The first batch of playtesters seemed to love that mode. You know you are onto something when they wouldn’t give me back the tablet. Adding in the puzzle mode seemed to round out the game modes nicely.

In the next section I will talk about what inspired the Railhead redesign and what has happened since. If you want to keep up to date on Railhead news and development you should head over to the Railheadgame.com and sign up for the mailing list and follow the Railhead twitter account.