(Quick) Game Design Document for the July 27th game

High Level:

Game where the player provides instruction for events that transpire in real-time

(some) Details

Player controls a castle and (1 or more) nearby towns

Player navigates menus to provide instructions to an "AI" Steward, about how the town(s) and castle should be managed

As real-time progresses, the instructions impact the development of town(s) and castle

Nice-to-have features (in order of priority)

To keep the scope small, these are features that, while nice to have, can be left out if necessary:

• Persistent world
  • The world should exist, even when the player is not actively playing
• Multiple Towns and Castles
  • There should be other towns and castles, each with their own management
  • These should have some (basic) development instructions
  • Some developments (i.e. trade) should vary in effectiveness based on the town/castle it is connected to
• Multiple Players
  • All players should play in the same persistent world
  • Ability to name leader, castle, town, etc
  • Players can interact with other players in the same way they interact with AI
• Notification system
  • Players should get a summary of what has happened since they last logged in
  • The summary should include important things (such as new players that they can trade with)

(This is kinda ambitious, but I am optimistic that I can deliver on quite a bit of it, in spite of the short timeframe.)

Reflections

Before I can get into my reflections, there's a lot of background to know about how it all came together:

I have wanted to do multiplayer for a while, and when I heard about Firebase it seemed like just the right technology to get my feet wet. I worked on some of the design that supports (honestly) an average of less than 1 concurrent user in a multiplayer game, and decided a persistent world living in Firebase would be my best bet. Once I dug into the technical side, it quickly became clear that I would not have an easy time getting Flash to play nice with Firebase. I decided to skip that battle, and instead do a browser-based web game. I have some experience with web development, so I thought it would be more manageable.

I looked at some of my options for browser-based Model+View frameworks (my experience has taught me that reasonably sized projects with agressive timelines really should be using one) and decided to use AngularJS, as Firebase provided some nice hooks for "3-way-binding" (basically extends the framework so it becomes Firebase+Model+View, and it keeps them all in sync for me). I figured that the ~10 hours of AngularJS experience I had would be better than trying to write my own 3-way-binding for KnockoutJS (which I am substantially more familiar with.)

I also quickly realized that I would need to have some server-side component updating the persistent world, as there may be as few as 0 users on at one time. I decided to use Cloud9 (which I had some familiarity with from my attempt to use Phaser with last game) and use NodeJS (which Cloud9 and Firebase both support nicely).

If you're keeping track, at this point I am using 4 unfamiliar technologies on my project (2 of which I have a small amount of prior experience with). As you may expect, the majority of my time spent working on this game was spent tackling the technical challenges that come from using unfamiliar technology. I spent at least a (part-time) day on each of these (normally simple) tasks:

• Setting up the page to write and read from Firebase
• Setting up my server to write and read from Firebase
• Get a textbox to write and read from Firebase (noticing a trend?)

I spent the first week just setting up the plumbing, and doing some sketches of the design I wanted. It wasn't until Sunday that I could finally tackle the server-side logic, where basically all the game design lives. Unfortunately, it was only then that I realized I needed to spend a lot more time on the design: one day of design (and coding) is simply not enough to get a smooth difficulty progression. Additionally, complexity-based systems are not my strength (I am more comfortable designing reflex-based systems), so the game being 100% complexity-based meant that it would take me additional time to sort through it all. Unfortunately, although the plumbing was in place, I didn't actually have any of the UI done either, so I had to decide between making a game that had good progression, but couldn't be played, or one which had choppy progression (and probably game-breaking bugs) but could actually be played. The decision was clear: I promised a playable game, so that is what I would deliver.

My Model+View framework did, however, deliver on the time savings it was supposed to, and, Thursday night, finally, the UI was complete. I got to actually do my first playtest of the game. The remaining time was spent getting to know this game that I'd spent more than a week with, but still only knew its name. I was able to help it out, and squashed some serious bugs (one was that the equation for jobs was broken, and always provided more jobs.) The more I played it, however, the more I realized it wanted to be something else, but, at this point, I did not have the time to change it.

Here is what (it seems) the game really wants:

1. The difficulty of the game is extremely front-loaded, making it feel more like a brutal rogue-like than a casual, online, play-in-your-spare-time game. (This has its own appeal, for sure, but it is pretty radically different from what I thought the original engagement would be: joy/wonder from exploring the relationships of complex mechanics - like a "grow something")
2. The real-time component actually hurts the game a lot. Since each decision matters, but the time to make that decision is usually very short, the game moves a little too slowly to be actively played, but you can literally lose overnight (that is, you could be doing fine now, but as the world changes, your current decisions are non-sustainable, and the population all dies out before you log on the next day.)
3. The game is engaging, but not in an active way. This point is difficult to describe (maybe I simply lack the vocabulary), but this game does not seem to be immediately engaging, in the way a game you choose to play should be, but it is compelling. I think these mechanics would work well as a sub-system or mini-game in a game with a more immediately engaging core mechanic. (Similar to town-building in Actraiser.)
4. The lack of (meaningful) multiplayer doesn't seem to be a bad thing. Although I could only implement a leaderboard, there is so much going on with just the single-player portion, that I don't think the additional complexity or uncertainty from multiplayer participation would bring anything new to the game (since the core draw is, I think, spading the game, the uncertainty may conflict with that).

Athough it may be clear from my (lengthy) background section, I will reiterate that I think the challenges of using new technology seriously impaired the development lifecycle of this game. The process was extremely stressful, and I was unable to follow the "fail early, fail often" mantra that is key for quality games. I think this game is actually really promising, and would like to revisit it in a larger project, but I think the lack of polish, particularly around the new-player engagement and difficulty curve, severely limits the game's current potential.