I tweeted about a month ago about an “interactive storyboard” that I was working on for my city builder design. But I only made it halfway through my intended development before I got distracted with my planet generation and turn based strategy shenanigans. The result was that I never got it to the point where I was planning to blog about it. Since it is apparently delayed indefinitely, maybe I should at least show what I do have available.
You can try it out yourself here, though be warned that the UI and overall user experience is far from perfect. This was in part an experiment to get a feel for how the interface would function (or not) after all!
As for what I mean by “interactive storyboard”, the idea is that it is halfway between a storyboard for a movie, and a playable prototype for a game. Movie storyboards can be a great way to get an early sense of how the various scenes and the various shots within each scene will flow, without having to pay the cost of actually filming those scenes. Game prototypes are intended to fill a similar role, but sometimes they can still take a lot of time to implement. An interactive storyboard is intended to look like a playable prototype, but only allows a very limited set of actions that more or less follow a predefined “script”. This can significantly cut down on the amount of game logic and UI logic necessary to get something visual, that can be evaluated. Then again, I’m not sure I succeeded in this regard. I still spent far more time on this than I should have, over-engineering plenty of elements. I’m still learning. At least my failures give me some pretty pictures these days!
The aspects of the game design I wanted to test with this prototype had to do with implementing available projects. Projects would be sort of like cards in a collectible card game. They would usually be randomly drawn, they would do nothing until played by the player, and they would often have costs or other prerequisites. Further, once played, some of them would have an immediate effect and be “discarded” or “removed from play”. Others would persist as objects within city, or modifiers on existing objects.
I had been struggling for a while trying to figure out how the game mechanics would play out regarding the opening state. Many city builders have either scenarios with prebuilt cities, or a wide open playing field with no city at all, and people and businesses just magically move in as soon at the player places the appropriate structures or zones. That didn’t sit well with me, but I eventually came up with a scheme that would give each city its initial raison d’être. This scheme could allow for both predefined scenarios by providing non-random projects at the beginning, or could allow for a more random exploratory experience by randomizing the projects drawn even at the beginning of the game. The player wouldn’t have a completely wide open sandbox to fiddle with, but would instead have a limited but diverse set of options. As the player chooses from amongst these available projects, the story of the city begins to unfold; they player and the game would be working collaboratively to create this story.
This interactive storyboard prototype was intended to get a feel for what this opening sequence might feel like. The player begins with a few available projects that are intentionally designed as part of a unified scenario. In a more realistic gameplay experience, there might be some similar options with different nuances, or perhaps even some radically different options, but I kept the scope narrow for this prototype. When the player accepts a project for design, it is added to the Projects Under Design list, and the player can then begin to design the details. No money is taken out of the budget yet; these projects are in a blueprint-like stage. In some cases, as is represented in this prototype, multiple projects will need to be designed together before all design prerequisites are satisfied, at which point the whole collection of dependent projects can be approved.
The prototype abstracts away the details of laying out individual elements, such as roads, zones, and power grid structures. Anywhere that the prototype says “Click here to auto-design”, this indicates that in a full gameplay experience, the player would actually be doing the ordinary activities performed in a city builder. But all of the UI complexities of those tasks were not my focus, so this was my way of skipping all of that development completely.
Once all projects are fully designed, the player can approve the group of projects, at which point the game could relevantly be unpaused. Construction and other implementation details of the projects would begin, and once complete, people and businesses would begin moving in according to the mechanics of the simulation. But this is where I got distracted by my planet generator, and so this is where my prototype currently ends.
Fortunately, even from this incomplete prototype, I have learned some things. I realized that projects and sub-projects would need to have clearly defined behaviors, with various kinds of dependencies and other interactions. Some of those were worked out while making the prototype. I also had to think about the visual representation of projects under design, especially regarding the one currently being worked on, versus other projects that were merely sitting on the back burner, or versus the parent project of the active sub-project. I had to clarify notions of prerequisites for design versus prerequisites for final approval. And there are probably plenty of others that have seeped into my subconscious that I can’t think of off-hand. (I hope they’re in there somewhere, and haven’t simply evaporated!)
Of course, some of this could have been figured out simply through thinking, writing, and drawing. But as a programmer, I’ve certainly found value in having to actually program out the logic. When writing and drawing out an idea, it’s so easy to subconsciously plug in a necessary detail without even realizing it. But when programming, the computer is utterly unforgiving. If there is a detail that’s necessary but not supplied, the program will not be able to perform the full desired action. By going through this process of programming, I am thus forced to confront each and every one of these necessary details. What I need to figure out now is how to focus my programming efforts on specifically the details that are tricky to get right, and not waste time on all of the mundane details that aren’t likely to get missed. I spent way too much time on the graphics and on the math behind the skewed grid perspective, for example. And even though I tried to keep the UI simple, I think I wasted a lot of time there too, though perhaps it was necessary, as I did become aware of certain important aspects of the UI that I probably would have overlooked otherwise.
Maybe someday I’ll get back around to working on the city builder again. I’m definitely still excited (in a passive sort of way) about the ideas I’ve been putting together, and am optimistic that they can provide an engaging and relatively unique gameplay experience. For now, though, I do believe that my turn based strategy focus provides me with a smaller scoped project, one that could lead to a playable game in a shorter time frame. An important consideration when slowly burning through one’s savings without any active income!