Play Game (In a browser)
Note: Build Tomorrow is now working, albeit slightly differently from when it was first created. See the blog post about the fix for more details.
Thanks for playing!
Original design document
Game where the player provides instruction for events that transpire in real-time
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
To keep the scope small, these are features that, while nice to have, can be left out if necessary:
(This is kinda ambitious, but I am optimistic that I can deliver on quite a bit of it, in spite of the short timeframe.)
Original writeup- immediately after completing the project
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:
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:
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.