Posted On: 2016-10-09
Build Tomorrow is now working! The new version has some minor deviations from the original, but the core game is the same.
I have mixed feelings about the critical mistake I made in the original (developing for a server without properly investing in it). On the one hand, it should have been obvious that I would need to invest in a proper server if I wanted to have the game code running on a separate server. On the other hand, I know myself well enough to know that if I had spent time researching all that would be required for deployment, I would have given up and abandoned the project out of frustration. I am, however, much happier now that I have made the code exclusively run client-side. As I mentioned in my reflections, the multiplayer aspect was not adding value, and the fact that the game ran in real time conflicted significantly with its other design elements. While removing the leaderboard and granting the user control over time caused the prototype to deviate a bit from the original, I think these deviations were both improvements, and in scope based on the work I had to do either way (getting the core logic into the client-side code).
A game's design often says things about itself, but it also often says things about reality. The trappings we give our games (castles, populations, taxes, etc) that we use to help the player with understanding the game have the side effect of (potentially) influencing how the player thinks about those things outside the game. When I first set out to create Build Tomorrow, I wanted the lesson that players could take away from it to be the interconnectedness and complexity of things that might seem superficially simple (for example, simply lowering taxes is not enough to create growth, if the demand isn't there.) While working on it recently, I noticed that there are some unplanned lessons a player might pick up on (consciously or not). One example is that having just the one goal (growing or maintaining population) encourages players to think of everything else in the game (health, happiness, money, etc) as merely means to that end. While my game is certainly not unique in that regard, it is something that I should have anticipated so that I could use it to inform my design. Hopefully as I become a better designer, I will become better at planning and detecting these (although, in fairness, the same project under less time pressure might have better afforded me opportunities to think more about the design and its consequences.)