Wireframing for Game Design

Dave and Ralph over at The Tap Lab created an awesome game called TapCity and gave a great presentation about it at Mobile Monday Boston #momobo.  They also talked game startups at Boston Indies. But before building TapCity they built a binder called BigCity. This binder is a ‘wire frame’ of the game. The intention was to be able to sit down with the binder, and like a choose your own adventure game, play TapCity.  Of course like all projects, the scope had to be reduced to get things moving.  Unfortunately BigCity did not turn into a playable iOS prototype. Despite not being what they dreamed, BigCity is a tremendous resources and is worth learning from.

This post has some rather large graphics in it.  More after the break…

Yes, they really are goofy in person.

Wire Frame vs Playable Prototype

Less involved then a paper prototype the wire frames demonstrate the look, feel, and layout of the product.  They act
as a map for a web page or application.  Generally they show off the user interface.  For example on the website wireframe wikipedia page ‘the back end’ is completely ignored for the purposes of wireframing.

In the context of game design what you get from wire framing a game idea is a sketch of the look and feel before it’s made. This prevents confusion about GUI when the coders sit down to make it. This ended up being a problem on The ZoRTS Project.  It is also a great communication tool which expresses thoughts often missing from the Game Design Document.  A good creative lead in training is going to have at least a few screens done before the project starts.  Ultimately the level of completeness of the wire frame is going to depend on the project.

To create a paper prototype, on the other hand, you need a little bit more of your ‘backend’ in the frame work.  The mechanics have to be in place in order to have a functional paper prototype. Almost like playing a board game version of the game you eventually want to make.  Start with the wireframes of the UI with the paper mock up of the game and then begin adding game play loops, decision tree’s, and the individual game mechanics like mob stats, inventory, combat, etc.

On a hobby project, where you have all the time in the world if you can do this, DO IT.  The ability to play around and figure out what works and what is compelling about the game before writing a single line of code will be worth every minute or every dollar spent in averted disasters based on ineffective communication.  However, for a game with deadlines to meet, or experienced developers, either the wire frame or the paper prototype will be sufficient.  Alternatively some amount of both could work.  Much like a Game Design Document, mostly complete is usually close enough to get started.  Just don’t forget to update as the project changes.  As Rules for Revolutionaries says ‘Don’t worry, be crappy’.  As long as you ‘Churn baby churn.’

Wire frame Resource Kits

Ralph was kind enough to post a .pdf file of the mock up they used for the iPhone.  You can find that on his blog.  This document is great for printing out and hand drawing your game.  If you want something a little more digital, or for the iPad, check out this post on speckyboy which contains a Wireframe kit for the iPad.  Or perhaps this one with an Android kit and iPhone kit.  These resources are provided under a ‘pay what you like’.  If you do some serious development with them, please provide the author some remuneration.

Conclusion

As a hobby game designer looking to become a pro, you absolutely should build a game design document and a paper prototype of your game before coding begins.  Should you do this before assembling a team or after?  Honestly I have no opinion on that yet.  It can go either way.  You might need a paper prototype to convince a team to work with you…  Or you might have a team of passionate friends that would enjoy taking the time to make the prototype.  You could even start a monthly prototyping session just for the fun of it.

Some professional game developers note that there are limitations to paper prototyping and pit falls associated with creating a game design document.  Their warnings should be heeded.  For example making a paper prototype could cause your game to feel like a board game.  Players are going to be able to detect remnants of the foundation during play.  My advice is to wire frame and prototype anyway.  Especially if you are just starting out.  Polish the process until it’s an art form, and then you can start to move beyond those foundation documents.  Besides you might actually want to make a strategy game.  In which case, feeling like a board game is no problem.  Feeling like an award winning board game is not a bad thing for your first game.

Of the many things that BigCity did for The Tap Lab, increasing Foosball skill was not one of them.

Dave showing off BigCities ability to teach Foosball.
There were a lot more pictures taken from my visit to Tech Stars.  Check them out on imgur.  Including a full view of the TechStars Logo!  Sorry for cutting it off earlier.

Images are all © Jeremy Springfield 2011 – I made them myself! Please ask permission before using them for any purpose.

The new stage of game design to do first…

There is nothing new about Pretotyping except using the word.  At Gameloop Boston #gl11, during the Prototyping panel professional game designers discussed the various methods they use to prototype a game.  Flash, Game Maker, Unity are all the rage right now in big design companies to get their ideas down into a playable form before coding a new game.  And then there was one guy at the panel whose main prototyping experience was using a D&D dry erase battle mat before ever coding anything…  Yeah, that was me.

As an amateur game designer looking to turn pro you absolutely should take the time to pretotype before prototyping.  Before ever spending a dime on any kind of development play your game.  The point is to play it on paper before building any kind of code for the game.  Really think about the game play and base assumptions about the game before you ever even add a second member to your team.  This new step will make the stages of game design look like this:

  1. Pretotyping
  2. Prototype (digital)
  3. Alpha
  4. Beta
  5. Full Release

Chances are good that you have everything you need to start pretotyping right away.  A table top gamer will have pens, graph paper, and dice.  Dave from The Tap Lab built a binder of paper ‘screen shots’ of TapCity before the game was coded.  Then used those to play the game!  If you don’t find those ideas interesting there are plenty of other sources for D.I.Y. pretotyping.  Simple things like Lego can give you a basic .  Flea markets and yard sales can provide a cheap source of tons of pretotyping gear which you can paint, color, alter, and cut up to make your game.

After the pretotype stage move on to the prototype stages using some kind of popular software.  Things like Game Maker, Flash, or Unity.  Additionally consider modding an existing games like Minecraft, the Unreal Engine.  After that process is complete move on to putting the effort into creating a unique game engine.

Do you have any tips or stories from pretotyping?  Even if you never knew the word before?  Post your stories to the comments!

The Adwords Experiment

Google was nice enough to send me a free $100 gift card for Adwords.  For anyone unfamiliar Adwords is the tool that lets you place ads in Googles search results.  You create an ad, and then bid on keywords.  The amount of competition, and your bid, determines if Google users see your ad or not.  For some keywords the competition can be fierce.  They keywords for most game related projects, however, remain very low in competition.

This ‘windfall’ represents the total marketing budget of The ZoRTS Project.  Instead of advertising a game which doesn’t exist yet it seemed like a better idea to get the word out about this blog.  The real goal is building a community of folks who can tell me when I’m saying something stupid (always appreciated) about game design.  This way the project benefits from more knowledge then I currently posses.  Also learning how Adwords works should be a marketable skill in this day and age, right?

Upon getting the gift card my first step was to contact thetrafficblogger and asked his advice.  He is my go to guy for all things blogging and social media related.  His suggestion was to start a campaign with as many keywords as possible, that have low competition, and start by bidding $.01 on clicks.  Thus began ‘The Adwords Experiment’.

The Goal: Get 10,000 hits using $100
Whoa!?!  That is a lot of hits, where did that number come from?  That goal came from TheTrafficBlogger himself.  Maybe he tossed it out randomly.  Or maybe from the point of view of a professional blogger that should be a reasonable number, he must get 10,000 hits a post…  But for a newbie like me?  It is quite the challenge.  But why not a randomly chosen big goal?  Right.  Jump in feet first!

The Method:
Week 1: One cent per click. Started July 14th to July 21st
Week 2: Two cents per click. July 22nd to July 28th
Week 3: Three center per click. July 29th to Aug 4th
Week 4: Four cents per click.  Aug 5th to Aug 11th

Now I will also be spreading the word about blog.zorts.net in other ways at the same time.  This behavior would loose points in the scientific world.  But as this is a completely new blog, its fair to allow for other traffic sources.  At the moment Reddit is my biggest source of traffic.  There could be some expansion from Empire Avenue readers.  It will also be very easy to figure out which hits came from where. So the analysis can include both with Reddit, and without.

First Hypothisis:
There is some cheap ‘magic number’ that will get me enough hits to break even between Adwords and Adsense.

Second Hypothisis:
There is some even more magic number which will net me a little profit for my trouble.

The Conclusion:
10,000 hits using only $100?  That is definitely a challenge.  We shall see if the final tally comes anywhere close.  Before collecting the data, I have no idea what to expect.  But imagine if that could be done!  Regardless of how the experiment goes over all, I’m sure this is a valuable learning experience.

There is a post qued up for tommorrow with some general thoughts and a couple things noticed about Adwords.  Expect additional posts as more is learned about Adwords.  Keep checking back for updates on the experiments progress.  Each week will get recapped on a Tuesday as an additional blog post!  As always ask questions if there is something that hasn’t been explained well.  Those kinds of questions really help me curate the blog, and help make sure the blog posts make sense as well as provide valuable information.  If you can think of anything that should be added to the experiment, comment below.

Cheap game design

Hypothetically lets assume you’re a gamer with an idea for a game.  This should be easy to imagine.  You want to make a game but have no money.  Once you have chosen your team, and gotten some idea of what you are building (with a game design document), and picked your distribution/coding platform, you realize that you need to keep track of a lot of different kinds of information.  Specifically bug and issue tracking.

There are many great services out there with the ability to track issues, but there is another method which is often overlooked.  You can build your own bug tracker using sites.google.com.  As we were starting the ZoRTS project the Lead Coder asked me to find bug tracker to use.  As a manager on a project with no money something with low cost is ideal.  The following video on youtube provided the answer.

Pros:

  • Works with other Google services
  • Cheap! As in free.
  • Hand built to do exactly what you need it to do.

Cons:

  • There are other methods which may be better
    • Basecamp (Which the ZoRTS project would like to use)
    • Assembla (Which the ZoRTS project is using)
    • 50 others.

There are a couple factors left out of the pros and cons.  For example using sites.google.com as your issue tracker takes effort to build and maintain.  You have to have and idea of what kinds of things you need to track ahead of time, and how the page is going to be used.  The ZoRTS website includes an example page so that you can get an idea of the kinds of columns that you might need.  However this is a moot point as you still need to spend time and effort updating and recording in any bug tracker.  It might just take a minute or two more to use google sites.

So what do you use to provide an infrastructure for communication of issues, bugs, design changes?  Why do you like to work with it?  If you have experience in the area please leave a comment below, let us know your opinion.