Paper prototyping is one of those sensible, low cost, low-risk activities that I rarely (if ever) do. It’s funny really, as in thinking about the content of this post, I can think of more than a few examples from the Serial Link project I am working on, where a simple paper prototype may have cleared up communication issues between team mates and possibly identified other less obvious issues.
I seem to have itchy fingers when it comes to implementing ideas. I get some thought and think ‘yeah, that would only take this and that and then a little tweaking and it would be there…’ Four hours later, having usually had some fun, I find out that I have designed (I use that term loosely) and implemented things in a way that makes the next obvious improvement to the idea difficult or impossible without structural changes to the implementation I have already done. I have learned to think more thoroughly about the possible extensions to whatever idea I am having and I have on occasion, mapped out the logic that I intend to use. I know that software development is iterative, but I know that I have had times where another ten minutes with paper and pencil would have saved me two hours in Unreal undoing and redoing logic to facilitate something that I really could have seen coming. I am getting better at this though.
Gameplay prototyping
I suppose that my first thought about how to apply paper prototyping to the Mobsters Vs. Barbers concept comes more in the form of a storyboard but maybe I’m missing the point. I’ve just had a shower instead of sitting here overthinking this (I tend to do that). A couple of things occurred to me. The first is that it’s obvious that paper prototyping is worth doing and the second is the reason I have been slow to catch on to it. I’m immature. As a developer I mean. I am only now having experiences that seasoned coders would call ‘fundamental’ (probably). I’m talking about Edge Case Thinking. I totally just made that up but I think it sounds pretty cool so I want a pound every time someone says it. Its that part of you that has spent three hours on the edge cases of a simple task like ‘play a clattering sound when the weapon hits the floor’ because you’re still learning what the problems are as well as how to solve them. Ok, what if the sound is already playing? What do you mean by ‘Floor’ in this context? Should it just play once? But what if it bounces? Should it play when something hit it? What if it just moves a little bit? Play the whole ‘I just fell six feet’ type sound? Should I track the velocity then? Is that expensive to keep testing at run-time? Should I use continuous collision detection? Shouldn’t all this really be in a base class? Oh my, I should redesign the weapon implementation to use class hierarchy! Geez, all I wanted to do was play a sound.
Get to the point
The point is, sometimes when I think something will take a few minutes it doesn’t. Experienced developers know this. I think that they would be the ones that say, ‘hey, lets not worry about all the if’s and but’s and lets just draw this on a bit of paper, assume we can work the details out, and see if we still like the look of the basic thing that this feature is supposed to provide’. That would be a very mature thing to do.
And so, with that in mind, I would apply this to the Mobsters Vs. Barbers concept by mocking up each screen initially, menus and so on, and then every major action in the main gameplay loops for each of the teams. Then I would ask some testers to have a couple of goes at it and see what they said. I think that the project would be so very early in its development that just listening to the first thoughts that your testers have would provide more feedback than you could implement. I would worry that more complex games that relied on multiple game systems would be very difficult to test in this way, if not impossible so I would reserve this for sections that are easily contained (inventory traversal for instance) or games that are very simple like Cut The Rope and so on.
I must admit that I didn’t really understand what the ‘remote context’ part of the question meant. If it was along the lines of ‘how are you going to test this remotely as the testers are not in the room’, then that sounds like a video chat, but that would just put a boundary between the player and the prototype. There is no location-based functionality like GPS in the idea that I described so I would hazard a guess that I would not use a remote context at all.
Chronicles of a Sofa Ninja 