In part one of this four part series, I introduced a prototyping project, a Christmas game called StackHack, and showed how early design ideas were worked out using a paper prototype. In this part I’ll explain the transition from the paper prototype to a digital prototype.
The first decision to be made when moving to a digital prototype is “what platform should I use to create the prototype?” In some cases the prototyping platform will be the same as the final target platform, but that’s not always the case. For example, if you were creating a console game, you might choose not to develop your initial prototypes on that console. Instead you might choose to develop an HTML5 prototype or make use of a simple game development engine as a prototyping tool. Generally you will want to choose a prototyping platform that will enable you to very quickly create and test the ideas you worked out during the paper prototyping stage.
In the case of this game, I wanted to meet these criteria:
- The game should be available to as broad an audience as possible
- The development should not require any investment beyond my time and the software and equipment I already had to hand
For this reason I chose HTML5 as the ideal target platform, because the game could be played by anyone with access to a recent browser, and because HTML5 does not require any specialised tools other than a text editor.
I decided that HTML5 would also be suitable as a prototyping platform, both for the reasons listed above and also because I have a good knowledge of HTML, CSS and JavaScript, so I could get a prototype up and running quickly.
Once you have made a decision about a prototyping platform, the tendency is to get straight down to work on the fun stuff – programming a prototype. But this is invariably a mistake. Remember that the key aim of any prototype is to get game concepts up and running quickly so you can evaluate if they work and modify or discard them if they don’t. Since speed is one of the key concerns, it’s important to avoid reinventing the wheel. Instead ask yourself – are there any ideas or tools out there that I can make use of to get me closer to my end goal without any significant effort on my part.
As part of my approach to this project I began by consulting a book on HTML5 game development – the excellent Pro HTML5 Games by the very talented Aditya Ravi Shankar. In his book, which I highly recommend if you are interested in HTML5 games development, Aditya proposes a game system based on two very popular libraries:
- The ubiquitous jQuery, which makes it much easier for JavaScript programmers to access the browser’s document object model (DOM) with cross browser compatible code.
- The Box2D library (the thing that does all the hard work behind the scenes in Angry Birds and hundreds of other great games).
Between them, these two proven libraries do a lot of the hard work for you to give you a basic engine, leaving you to focus on creating the mechanics for the game and saving you a lot of time.
There are three other common mistakes with digital prototyping. The first is to try and squeeze every aspect of your concept into the first prototype. Not only will doing this take a long time, but if the fundamental concept just doesn’t work well, then you’ve wasted a lot of effort on something you are just going to discard.
The second is to try to create reusable, production-quality code. Again this is unnecessary effort on something that may well be discarded, so it should be avoided. Focus more on getting the prototype working quickly and don’t worry so much about the quality of the code at this stage. If you decide to move forward after the prototyping stage, you can either rebuild or refactor your code at that point, when the effort will be worthwhile.
The third is to create nice artwork for the prototype. Again this takes a long time, and it might be a wasted effort if you end up discarding the prototype. There’s another very good reason for doing this. When you come to play test your prototype, you’ll find that testers are easily distracted by visual aspects of the game, and their response will be affected by how much they like or dislike your art. What you really want them to be focused on at this stage is the gameplay, so it’s best to keep your prototype art as plain and distraction-free as possible.
You can play my first digital prototype. You’ll need to use an up to date browser on a device with a keyboard. The controls are:
- Move left: left arrow key
- Move right: right arrow key
- Jump: up arrow key
- Pick up/drop a block: space
As you can see, this first prototype has just a single level that focuses on the central mechanic of being able to pick up and carry presents and drop them onto the guides. For this initial prototype, I chose to exclude the other elements of the game, such as the cannon, platforms and guides that require specific presents. In fact there aren’t even different types of present in this early version. Making the first prototype this focused allowed me to concentrate on how well the core mechanic worked without being distracted by other features.
You’ll also notice that the graphics in this version are minimal to say the least. In fact most of the graphics in this version are generated by the box2D library; the only graphics that I’ve added are the static stick man and the red box that shows where presents have been successfully locked in guides.
Even though this prototype is very primitive, it enabled me to establish that the core concept worked and was worth proceeding with, and to tweak aspects of the core mechanic, e.g. character movement, picking up and placement of blocks, etc.
At this stage you might well decide that the core concept isn’t strong enough and scrap the prototype. In this case you will at least have the consolation of knowing that you reached that decision without having expended an inordinate amount of effort.
Or you might decide to move on to the next stage, which is to incrementally introduce other game elements to your prototype, and I’ll cover this in the next part.
Be First to Comment