This time I’d like to talk about the process of creating prototypes. Though this blog is about mobile gaming, prototypes can be a valuable tool for almost any time of software development.
What is a prototype?
A prototype is an limited version of a program which is intended to test something, such as a new game idea. It’s definition is fairly open-ended, but it contrasts from a production version which is something designed to be used by customers, as a complete game or application.
When do I need a prototype?
Creating a prototype is typically warranted when there is some uncertainty the project which needs to be worked out, essentially de-risked, before taking on the full production project. Prototypes are usually appropriate when the full version will take quite a long time, possibly months or longer with a team of several developers and other staff.
The idea is that you want to avoid expending too many resources (money, time, etc.) until you have some level of confidence the project will succeed. Success is defined differently for each project, but it can involve making a certain amount of money, or just making a game that is fun to play.
The idea of prototypes also assumes the developer(s) have the capacity to work on more than project over time. If you compare working on a single project for a year, with a 50% chance at failure, as opposed to developing 10 prototypes during that time to find which idea(s) have the most potential, the latter could be considered a more efficient use of time.
How do I make a prototype?
The most important thing about prototypes is deciding exactly where is the risky part of your project, or the element(s) you want to validate. As an example, let’s say I have this great idea for a game that is a cross of checkers and a word game, and it seems really fun to imagine how it would work. In this case, the purpose of the prototype would be to see how enjoyable such a game would actually be, and to work out some of the gameplay elements.
You can work iteratively, trying one idea until you determine it doesn’t quite work, at which point you can add or change an element and do some more play testing. For example, in our checkers-word game example, you can play around with different scoring systems to see which is fair and offers the most challenge.
Tips for making a fast prototype
The prototype creation process helps guide you what order you do your activities in. If you are testing the gameplay of the checkers-word game, there is no need to spend any time on the main menu system, the credits page, or the sound effects. You should be spending most of your time in the risky or uncertain element you are trying to test.
With games, graphics assets are one area which can take a long time to produce, whether you are doing it yourself or with the assistance of graphic artist(s). For many prototypes, you can skimp on graphics and keep things very minimal and simple. Rather than a photo-realistic game tile, you can stick with a simple single-colored square, and so on. Of course, if your idea involves creating a game with a certain atmosphere (like a horror game), the graphics and sound might be more important than the gameplay, in which case your prototype would require more effort on those assets.
One nice thing about prototypes is that you have much more freedom. For example, you can potentially leverage a test license for a game engine which you couldn’t otherwise use for a commercial project without paying big bucks. You can do the same for other assets which are legal for non-commercial purposes, though if you switch to a more serious commercial project, you’ll have to purchase the proper licenses for everything being utilized.
Prototype coding practices
When developing a prototype, you also have some more freedom regarding how you write your code. You can probably get by with spending significantly less time on things like commenting, proper modular design, and efficient algorithms. However try and avoid taking things too far, since adopting horrible practices like stuffing all code into a single giant function would make modifications of the prototype difficult.
Also, some things which you typically try to avoid in production code, such as global variables and cryptically named variables, would probably be OK in a prototype. Proper memory deallocation can also be put off, since you can always restart the app as often as you like during test.
Levels of grey in prototyping
Prototyping isn’t all or nothing, in the sense that you don’t have to throw all your code away after a prototype. You have the option of reusing parts of your code in the production version, probably after some refinement, or even in another project.
After writing many prototypes, I’ve gotten into the habit or always writing “TODOs” in my code so that if I do get to make a production version, I know what I need to fix. I also always think about whether it’s worth the few minutes to write a block of code properly, or decide to leave it in a quick, “hacky” state. Spending the few extra minutes to write proper code also makes you a better developer in the long run.
Prototypes need planning too
If your coding is just as a hobby in your free time you can do whatever you like, but if there is a chance you will try to go commercial or enlist the help of other people, it’s good to have a plan even for your prototyping.
First, decide roughly on how you are going to measure the success of the prototype. Will you just play it yourself for a few hours and see if it feels fun enough? Or will you show it around to your friends to get their feedback? You could even target an app store (mobile or desktop) as an end goal to your prototype. You probably won’t get too many downloads because of the lack of polish, but the process of getting on a store is always a learning experience.
Second, get a general idea of how long you think the prototype should take. Generally, I would say a few days to a few weeks is a good range. If your prototype is taking more than a few months then I wouldn’t really consider it a prototype anymore.
For new developers
For those new to software development or game design, your first few projects will probably all be prototypes, whether you think of them that way or not. In that sense, the goal of your effort doesn’t have to be to make a great app or game, but instead just learn something.
As your coding skills improve, you’ll be able to write a rough prototype in a shorter span of time. Saving code you’ve written in the past and reusing it when possible is a great time saver.
A real life example
Recently I had an idea for a casual mobile game which I felt had great potential, so I tried to make a quick prototype to vet the idea. By surgically ripping out parts of a previous project, I managed to make a working prototype in only two hours, and then added a computer AI player in another two.
The idea turned out to be a little less interesting than I imagined, so I’m glad I didn’t try writing everything from scratch. But at the same time, I feel with a few tweaks the gameplay might be taken to a new level, so I’m going to try a few more things when I get a chance.
All prototyping is essentially an experiment, so have fun!
Mobile Game Development 