For this week in User Experience and Prototyping, we once again got a dedicated subject:

Write about a possible digital prototyping path you might take for your project. In other words, what tools might you use, what might your plan be.

For this, one tool popped into my mind almost instantly: Processing.

Why?
If we ignore the obvious fact that I have used the tool before (see “Urban Jungle”, mentioned in the portfolio) and got plenty of programming experience, there are many good reasons as to why it would be a good choice. However, I have chosen to narrow it down to three primary reasons.

1. Easy to make quick things happen: With the nice setup and tons of easy-to-use commands, it becomes very quick and easy to do simple mock-ups.
2. Easy getting inputs: In the same way, there are quite a few good ways to get input from the mouse and keyboard, making it easy to make it interactive.
3. Quick to share: By being a Java-based, Processing-results are easy to share, by being viewable in browsers or simply as a standard executable file.

Combining all those really speaks for itself. It does require some coding, but that is to be expected either way, but seeing as it is basically a higher level of Java, it is hardly something you would see as anything negative.

So, what is the plan?
Given the advantages of the project, I plan to start out by testing the mechanics in the digital version. Each iteration should improve or add something new and would not require the muse to be actively (physically) present in-between tweaks. Naturally, ironing out major bugs is something that would not need the presence of the muse either – unless it is an odd bug that turns out to be usable as fun mechanic.

On the other hand, tweaking stuff on the fly is an approach that would be fun to consider. The idea is to have a very early (functional) game, where some parts are still uncertain. Naturally, this can be rather difficult to plan, but is incredibly great when happens.

In terms of aesthetics, style and likewise, this can be added and tweaked on the side and should already have some feedback dating back from the paper prototype. As such, this should minimize the tweaking, and bring the focus back on the game itself, rather than polishing.

Seeing as I am in the fortunate situation of knowing the subject for next week as well – and that the very subject is more or less the same as this week – I will be taking a look at various alternatives there.