I think it is time to say goodbye to my first major prototype.  It’s hard.  I want to keep pushing through the hurdles, extending it to the point where it is a fully playable game, even if highly simplistic.  I’ve been told that forcing myself to complete projects is important for gaining valuable experience, and I definitely still believe that.  But perhaps I was applying that advice incorrectly.  For a project that is meant to be shippable, it’s probably great advice.  For a project that is meant to be a prototype, it’s important to be able to drop it when the time is right.

Up until now I’ve been ambiguous with myself about what I’ve been working on for the past two months.  Was it the beginnings of a shippable game, or was it an early prototype that would inform a future project?  I wanted it to be both, but I think now it is valuable to make a clear distinction:  I’ve been working on a prototype, and it has now served its purpose and is beginning to outlive its usefulness.

I’ve been re-reading sections of Jesse Schell’s The Art of Game Design, (I hear the 2nd edition will soon be available) and I’ve noticed that I failed to follow quite a large chunk of advice that I originally intended to follow.  In chapter 7, “The Game Improves Through Iteration”, Jesse provides eight prototyping tips, and I tripped up beginning with tip #1:  “Answer a Question”.  I did not begin this prototype with a clear set of questions that needed answering.  I did have a loose notion of the risks that I wanted to evaluate and mitigate, but nothing precise or formal.  Nonetheless, the prototype has indeed answered numerous questions, so it’s not all a loss.  I intend to retroactively formulate the questions that the prototype has managed to answer, but from now on I should of course do it in the proper order.

Tip #3 is “Don’t Get Attached”.  I’m clearly working on that one now, but I’m curious if there are ways to make that easier beginning from day one of a prototype.  Perhaps if I also focus more on tip #2, “Forget Quality”, I’ll be more than happy to drop a prototype full of ugliness that I absolutely would not want to carry forward into a shippable product.

As an engineer with a penchant for perfection, I fully expect to forever struggle with tip #2.  It is further complicated by a certain degree of subjectivity.  For example, one of the questions I had was whether or not various simulation details would be scalable to large cities on standard consumer hardware.  In order to evaluate that question, I needed to spend a fair amount of time attempting to devise decent algorithms.  If I simply used brute force algorithms in order to implement a particular model of simulation, saw that the game play behavior was acceptable, and just assumed that I could optimize the algorithms later, I might end up spending a lot of time and effort building out a complex simulation model that ultimately cannot be scaled up to large cities well.  I want to reject unscalable models as early as possible, since support for large cities is a core objective.  And in order to identify unscalable models, I have to focus at least somewhat on quality.  Perhaps this is a special case, though, acceptable as long as I am clearly aware of the justification for quality from the beginning, and focus my prototype specifically on answering this question.

Another case in which I’m willing to spend time on quality while building a prototype is when I’m attempting to learn or practice new coding techniques or software architecture.  During this most recent prototype, I spent a lot of time refactoring my data layout and processing functions in order to better understand data oriented design, and to learn how to quickly and effectively choose my data layouts and processing accordingly in the future.  But perhaps that wasn’t really part of the prototype; the prototype merely served as a convenient testbed.  Such research, learning, and self improvement will inevitably spend time, and it is time worth spending, but I might benefit from conceptually perceiving it as independent from prototyping.

Those are a few thoughts I’ve had as I try to learn how to get into the prototyping mindset.  I’m not quite there yet.  I’ve felt rather discouraged this past week, and I’m sure that negative tone has seeped into this post.  But as noted, my recent prototype has nonetheless been a valuable project, and in my next post I’ll go over some of the concrete successes and benefits I’ve obtained from it.  I’m feeling a lot more optimistic now than twenty-four hours ago.  I’ve read that independent game development, and entrepreneurship in general, is full of emotional ups and downs.  Well, I’m living that roller coaster right now.  :-)

1 Comment

Leave a comment