Posted On: 2019-05-20
In my previous post I briefly mentioned that I intend to architect my long-term project in a way that makes it simple to spin off prototypes. Today, I will write a bit about why that is important for my project specifically, as well as why it is valuable to prototype on any project.
I've used the term prototype frequently throughout this site, but never taken the time to explain what it is. In general, a software prototype is a functioning piece of software that is designed to be a tool for answering one or more questions. Prototypes work best when their scope is small (ideally, a single question) but the cost of developing supporting systems can incentivize aiming to answer multiple questions with a single prototype.
As an example, in the Retrospective of A Notebook Prototype I described the goals of the prototype: initially it started with verifying whether or not I needed Natural Language Processing in the notebook. In a question form, this would be Does the notebook work without Natural Language Processing (NLP)? Of course, this also entails the question What does it mean for the Notebook to "work"? Identifying how players use the notebook then became inextricably linked with the project as a whole: what it meant for the notebook to "work" from a player perspective would likely be different from what it meant for the notebook to "work" from my perspective. Learning how players use the notebook would help me understand whether or not the notebook was achieving my goals, while measuring levels of player frustration would help me understand whether the lack of NLP was interfering with players achieving their own goals. Over time, the scope of the project continued to increase, including an increase in the number of goals (that is: questions the prototype was trying to answer.)
Each of my many other prototypes had questions/goals associated with them, from Can I make a game in one week? (answer: not one I'm proud of) to Can I make an asynchronous multiplayer game? (answer: yes, but that game is actually better single player.) Even my latest prototype (Magic Training Prototype) has questions that it aimed to answer (I won't go into them now, as I have plans to do a postmortem for the game in the near future.) Even work that I've done outside of making games involved creating prototypes to verify some kind of question (can I achieve X by doing Y?)
Specifically with regard to the larger project I am working on, I have need of more prototypes in the immediate future. While the Notebook and Magic Training prototypes have provided a great deal of valuable information, I still have more unanswered questions about the larger project. Some of these questions are related to lessons learned from past prototypes (for example: Since the Notebook doesn't communicate player intention, how then will I determine intention through gameplay?) Other questions are simply things that have not yet come into scope for creating either of those prototypes. Essentially, at the point I am currently, I know that I need to learn more in order to keep moving forward on my project.
Regarding why I am architecting specifically to support prototypes that spin off of the final project - this is related to the intersection of scope and the many roles of an independent developer. Generally, I use version control: this allows me to create micro-prototypes as I work, as I can safely try something and then revert the changes so that I can apply whatever I learned in the attempt. Sometimes, however, the scope of the prototype is too large to attempt all at once. Completely separating the project (such as by copy-pasting the code or making a whole new project) can work, but doing so means that any further work performed in the base project cannot be easily included into the project. This can be a blessing when working with a team (other teammates may introduce unrelated conflicts that don't add value to the prototype) but when developing alone it can be a disadvantage, as it increases the cost of implementing something in both the base project and the prototype. Working independently, I have found that I often split up my week working through a number of different roles, from architect to composer, so a lot of unrelated work may be accomplished alongside a long-term prototype. By keeping the prototype as a fork, I have adequately isolated the prototype while still making it possible to merge features or assets from the base game into the prototype.
Prototypes are a powerful tool for learning. They can be used for simple exploration (what happens if I do X?) or for more rigorous endeavors, like testing hypotheses (If I do X, then I expect Y. Is that what happens?) In software engineering, like any other craft, it is important to be continually learning, and prototyping is an excellent way to push the limits of what you know. In particular, a prototype that disproves something you believe to be true is the best tool for expanding your knowledge. (After all, the only way to be right is to find out you are wrong and then change your mind.)
Regarding learning as a separate activity from working on a project: it is important to isolate risk so that making mistakes and being wrong can occur safely - without consequences on the project's health. Relatedly, it's also important for the learner: by working in a space that is isolated from risk, the learner is in a much better position to expand their knowledge (compared to an environment where mistakes adversely affect them.) Both of these factors tie into project planning and timelines as well. Budgeting time to learn or planning to prototype is certainly better than assuming everything with work on the first try, but if a prototype's failure introduces risk into the project timeline, this may interfere with the learner's ability to make the most of the prototyping experience.
Hopefully this exploration of prototypes and the value they provide has proved helpful. As always, if you have any thoughts or feedback, please let me know.