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.


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.

Failure is always an option.

The Zorts Project is most likely going to fail.  TapDave asked me a direct question about the future of the project, and point blank the answer was “I am planning on the project failing”.   The reason behind that is the project may come to a point where we stop working on it.  That does not mean that we have failed.  Quit the opposite actually.  Learning something is never a true failure.

What are we learning from the ZoRTS Project?

There is, of course, another school of thought that only when you embrace that something could fail are you actually prepared from something great to happen.  Failure could even be the very thing that drives the economy!  What are your stories of success through failure?  Share in the comments!

Finals are done!

The final final was taken last night!  It feels really good to get that done.  As a (relatively) free man it is time to start looking for a job, and working more on the ZoRTS project, which by extension means this blog.  It is time to take the advice of Markco (err Chris) and go through and cross link all my old blog posts.  Hopefully that way someone other than myself will actually read this!

Coming up in the near future: More Networking.  TapDave pointed me to TheRubyRiot.  A networking event for startups, people looking for employers and perhaps, a person like myself, learning about the business of computer games.  Time to dive in and see what happens.

Networking Round 2

Todays round of networking quickly follows yesterdays.  Had an amazing chat with Dave Bisceglia CEO of The Tap Lab.  And I forgot to ask him how to pronounce his name!  Damn.  We chatted about games, games, QR codes, Retail Impulse Purchasing, funding startups, being a start up, our favorite professor at BU… John Meyer (“…” used to emphasize that John Meyer is not our favorite professor at BU).  We talked about the Zorts project and why it is not a company.  Very positive chat and I think a future freind.  It was exactly the kind of conversation I was looking for, both ‘nuts and bolts’ and dreams of what gaming can be.  My lunch with Chris produced a lot more actionable items for the Zorts Project, but then Chris is an amazing project manager so that’s to be expected.  Dave is a CEO who is dealing with funding issues, venture capital companies, finding users…  Two very different conversations, but two very good ones to have.