Last night we decided to put our 3rd game, Scott Told Himself, on developmental hiatus as we continue with different projects.
This was not an easy decision. A major component of our project with mindful xp is creating game after game in rapid succession. We’ve been working on Scott Told Himself for 10 days now. Typically we had hope to spend about a week per project, but with Scott we pushed ahead after our deadline hoping that one last major push would finish things up. Yet even with these late nights the game is still incomplete, a bunch of systems lacking any connective tissue.
With most projects it would make sense to release a prototype and move on. Especially with rapid prototyping not every game idea will work out and there are valuable lessons to be learned from every experience. With Scott Told Himself, there are a few lessons from its short development that we feel are important going forward.
1). Maintaining momentum
Our previous projects R-evolution and Connections were both completed within 7 days. And in both of those cases getting to the crucial tipping point of having a playable system with feedback occurred within 3 days of work. Scott Told Himself was designed with very simple systems that required a lot of scripting work. This meant that even 6 or 7 days in we had a lot of small interactive moments that never connected into a larger game. Each day working on the game without having something truly playable at the end of the night sapped a little bit of enthusiasm out of us and over the course of 10 days really drained us mentally.
Not only was there a lot of scripting to be done with the game, but we hadn’t adequately planned out how to develop for a script-heavy game. Typically in a game like this you want to develop tools for scripting early on so other people can work on scripting in parallel with general game development. However on Scott Told Himself we didn’t even have a generalized scripting engine for the first 5 days of development. And even then objects had to be placed through a tedious process of slowly rewriting both XML and code files depending on new functionality. All-in-all it lead to a mess where I as the programmer was primarily working on the game while both Dan and Felix were left with few tasks to work on simultaneously. This uneven distribution of work led to an unhealthy dev environment where I felt anxious for the amount of work placed (by myself!) on my shoulders and both Felix and Dan felt anxious because they felt they weren’t actively contributing to the game.
2). Building systems vs. moments
During the course of our project we’ve been working with this basic dichotomy of creating meaning within games either through the systems versus specific moments. Basically should we create a working game and mechanics that eventually leads to moments of meaning (or as we define it moments of introspection, reflection, and/or realization) or do we work from specific moments and try to build the game to those? With Connections we decided to approach things from the systems end and focused on modeling relationships and personalities with the hope that meaningful moments would emerge. This had its advantages and disadvantages so for Scott Told Himself we decided to determine the pivotal “moment of realization” first and build the game backwards from there.
The danger there was by working backwards and crafting the system after determining the meaning we were waiting on a lot of different development aspects to coalesce at the last minute. And while we had determined a strong moment for the game, we never really defined a good system to place around that moment. So instead of developing toward a consistent end goal we were habitually changing our dev target, adding new mechanics and features on the fly as we grasped in the darkness for a fun system. We never really got there in our development so even now we don’t feel there’s a complete system to work around with Scott Told Himself.
3). Meaning takes time
Finding meaning within a game is different than defining a new mechanic in a game. One of the most basic differences we feel is that the barometer of success between the two is wildly different. Experimental by its nature merely needs to exist to prove a point. If you’re creating a game based around a new experimental mechanic you just need to show proof that a mechanic can work, not that it does work. Anything afterwards, the playability/fun of the mechanic is icing on top of the cupcake.
With meaning success isn’t determined by attempting to convey a specific meaning, but rather success (we believe) is determined by how well that meaning was conveyed to your audience. After all anyone can say “this game is about the guilt of losing a loved one”, but actually delivering on that concept is the true determinant on how meaningful your game is. And this means that it’s not good enough to deliver a concept, we need to deliver a fully-formed game with systems and interactions that work as well as they can to deliver meaning and expression. The execution is just as important as the conceptualization with our project. What this practically means is that our game development cycles tend to be longer and more focused on polish than what you would expect compared to experimental game prototyping. We need to take longer to ensure our games are complete upon release or that meaning may not be effective in its delivery.
Coming back again
These things being said, there’s no doubt in our minds that we want to return to Scott Told Himself in the near future and hopefully figure out the specific game issues that were hindering the game. We still believe there’s a great idea and a great moment of realization we want to express. It’s not that far away from completion, but we just need to know where to take it.
More importantly though is that Scott Told Himself is the first time we ran into these problems and had to express them cogently. These problems are not isolated to Scott Told Himself, but have been and will be issues we will constantly grapple with throughout the course of our project. So in a lot of ways having an obstacle like this early on is incredibly helpful to us. Now we are able to recognize these potential pitfalls going forward and hopefully inform our future game development.
For now though, we move on to our next project. We’re going to try a different pivot with our next project and hopefully regain some of the development momentum we lost here. We have a lot to say about things going forward and things that occurred in the past.