Saturday, October 30, 2010

Prototyping Ways

A while ago I posted an article about the way we envisioned our new development methodology via a Rapid Prototyping and today I would like to touch this topic once more.  But today ill delve more into ways of doing prototypes and what you can learn from those early prototypes that can help you make some important decision early on in your development (this is based on my current experience with the development of Mythlound so I have to put the usual YMMV disclaimer).

Then lets tackle our first entry in today agenda : Ways of doing prototypes.  I am sure you're eager to learn some new API/framework that will let you make prototype more quickly.  You probably already fired up Xcode with a template project or launch your favorite code editor.  I am sorry to disappoint you, but you will need to step away from the computer... as they won't be any line of code required to be type!  You say what??? Yes you read me correctly I am going to show you some ways of doing prototypes without the need to wrote any line of code ;-).

Got your attention? Good!  I know you must be thinking what is this Québec guys have been smoking/drinking/eating (yes yes I know we're a French culture and we do sometimes do some weird/funny thing ;-)).  Well nothing special really I swear, but just found easy and practical ways for prototyping game.  Of course what I am gonna give are suggestions and may not always be the best solutions for your type of game.

Most of the time you will get an idea for a game after seeing something of interest that has pick your curiosity and made a little light bulb goes on in your head (maybe it was something in another game, something you read in a novel, something you saw in a movie or simply in the nature).  Then you will often have the urge to go try out this new found idea directly in code, being coder/developer we often like to poke/peek thing around the machine.  But first ill advise you to try first note down the idea briefly (short sentence, a small paragraph) of the game you have in mind.

Now once you are done with writing your little note, you're ready to build a first prototype with... a deck of card!

You're now seeing what the first ever prototype of Mythlound look like way back in early 2008.  Why did I choose a deck of card? Well it provided 2 crucial elements I had in mind for Mythlound the first was a memory matching game (remember where the same elements are on the board), second was those elements can be move around a bit like in Tetris.  A deck of card can be easily obtain and you most probably already have one (if not even more than one) and it provide many elements for puzzle game.  For example you will get 4 time the same symbols (they are 13 different one in total) so you can easily do match 2, 3, 4 (even more if you decide to mix up more than 1 deck of card).  It provide randomness, as if you pick one card from the deck you don't know in advance what you will get.  And you can also hide/reveal what is on the card by flipping it on the other side which in the case of a memorization game is perfect.  The cards can be laid down on a table in different order, orientation, stack horizontally/vertically and move as you need.  You can see that with a simple deck of card it can solve a lot of questions you may have about your game and how it can be played.  For me I was able to test both elements, by putting several card on the table and adding a new one at the top at a regular interval while trying to find matching pairs.  And in all of this I type 0 line of code but had a working game prototype ;-).

Maybe you need to prototype a part of your game that involves random value (either for a distinct value or a chance of success/failure).  Well the simplest thing to use again without having to code some random() and seed() function are some set of dices.

The typical D6 dice can be used, but the best if is you have more variety in the set of dices like D10, D20, etc... Which of course will be familiar to an avid RPG gamer such as myself who have been playing D&D since the time of the original red box ;-).  They all come in different colours and shape and are not too expensive (usually around 5$).  If you find it difficult to find such dice in a store near you, they are also some virtual one available on the App Store.  I would recommend that you get Pip from @mysterycoconut which will let you have many dices as you need for rolling.

Don't forget also your good old friend pen & paper, which will let you draw some of the elements in your game prototype.  It could be the mock up of your UI, some of the sprites, the background graphics, etc...  Also if you can draw it to the actual size as its gonna be on the devices, the better!  For example if you working on your game prototype for an iDevices you can easily to go to Apple website and the check the actual dimension specification.  You can even get the iDevice template picture in Apple marketing ressource which you can print so it fit the right size.  Once you have that iDevice on paper its easy to put your game elements and see how they relate with the overall size of the iDevice (is it too big, too small?). 

They are even iPod and iPad stencil that you can buy from different source such as the one from Kapsoft.

I was able to learn a lot of valuable information by prototyping in one of the previous ways.  Ether it was the number of different elements that should be included (how much can I remember, especially if the location of them are moving).  Did it made sense to have the different elements be moved and if yes what will be the rules of their moving (is there any restriction?).  Is there enough randomness possibility and what are the statistics of recurring elements.  How can the layout of the game board can be arrange and we fit all the elements.  And many more without typing any line of code, but I did use the computer in a few occasion to print graphics mock up and check different layout (what... did you expect me to always draw and redraw everything on paper, this can become tedious at some point ;-)).  But for me the most important part to nail the basics of the game play was the deck of card, which was also easy to bring around and show to my other friend on how it was gonna work.  It will be the same for your prototype too, you can learn a large quantity of information that should recorded preciously.  Also you can quickly go from an idea to a basic game play in a very short time (could be a few minutes to a few hours).

Alas not everything is well with this methodology and this the second important thing I learn the hard way.  As at first when I came up with the game idea for Mythlound it was for the Xbox 360 via the service Xbox Live Indie Game, which of course involve a joy pad and bigger resolution.  The game play mechanics itself can be brought to many platforms as its fairly independent.  But the interaction can be quite different and its something that might not be so clear while prototyping by hand.  My vision originally was to use the 2 dual analogue stick from the Xbox 360 to control 2 hands that were gonna select 2 elements for the matching or for moving.

When I decide to bring this to the iDevices I had to change this slightly as putting 2 hands on the so tiny iDevices wasn't really desirable.  I prototype the solution of one hand with the deck of card and it work and made sense.  So far so good, but at that time I still no actual iDevices.  Then I build up my first prototype and did a preliminary test via the simulator... I have to say this loud and clear : BE VERY CAREFUL THIS IS NOT HOW IT GONNA FEEL ON ACTUAL iDEVICES!!! I know Apple warn us that this is not emulator but a simulator, but for the problem wasn't about performance, but the interaction.  I think you probably know what is the biggest culprit... yes the mouse versus finger!  Yes the mouse can easily simulate basic touch gesture interaction such as moving, tapping, as you would do with your finger on iDevices.  But it has one big difference in doing those actions and its PRECISION as in pixel accurate precision, sadly our finger aren't. 

So exactly what happen?  Well originally I made the basic elements that will be moved/flipped to be 24x24 pixels (yes it was that tinny), which was fine when I was clicking on it, dragging it around under the simulator on my Mac Mini.  Luckily I had the fortunate thinking of building a prototype around that key element and to test just this one element as I knew everything will be related/based on this.  So I sent an Ad Hoc build to my friend @tronicsynth who has an iPod Touch 2nd gen. and the first feedback was : "Too small, I have trouble to move/tap it".  Yikes and already had idea of putting many of those elements on the screen side by side, this would have been a huge mess!  What I did next was to sent him several version of the UI elements until we find the smallest size that I can go down too without compromising the interaction (the optimal size we found was 45x45 pixels for the element).

Moral of the story? Even though it can be very efficient and quick to prototype game ideas by hand (no coding required, so even none coder can do it).  But when it come to interaction with actual devices in general its a very important and crucial step to quickly find it gonna work or not.  The best way to do it is to concentrate is some specific interaction that will be in your game, ether is the tapping that need to be done, the dragging, pinching or other kind of gestures, build a simple app to test just that and see how it goes.  This is what I did first and I am glad that I did instead of building a larger prototype involving more of the game. 

N.b. Trivia question : What are the 2 main chips that are seen on the breadboard and from which machine does it come from ;-).

This post is part of iDevBlogADay, a group of indie iPhone development blogs featuring two posts per day. You can keep up with iDevBlogADay through the web site, RSS feed, or Twitter.


  1. Ah, the Commodore logo makes it to easy... it's the good old Amiga :)

    Trivia aside, great article. It's much too easy to fall into the trap of "quickly writing a prototype" when you can figure it out with all the things that surround you.

    This is a great reminder that sitting down at the computer shouldn't be our first choice.

  2. @Rachel

    C= logo maybe made it easy and you're right those 2 chips come from an Amiga... Well the bigger chip is the CPU (good old 68000). But does your knowledge is good enough to know which the name and function of the chip with the C= logo? They are another hint of what it does on that photo... ;-).

    Thanks for the comment its really appreciated. Indeed I also found myself falling into that trap too before (being a coder at heart I like to type in code). But this is not the only way and sometime its good to step back and go back to the roots of game, which often just involve us and our imagination (well it is for me).

    I often can find some idea and experiment with them with some simple thing that lay around my desk. Computer can be a great tools, but its not the panacea and we should sometime think about get back to basics.