Sharing Dave’s Social Mobile Protip

During the Smart Money in Gaming event, Dave Biscelgia (b shell ia) provided some great, and very specific advice for social, mobile start ups.  The first piece of advice, test internationally.  This strategy is called a soft launch.  The goal of which is not to generate tons of revenue, but rather to gather user data.  This data helps tune retention, figure out where problems exist in the app/game, and add polish to the product before the real launch in the U.S. market.

Also during the event Tier 5 was mentioned as a specific example of a location where cost to acquire users is extremely low, however conversion is really bad.  There are some terms in that sentence which are new to the blog.  We’ll go into them a little more specifically in the near future.

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.

3 Business Models for your mobile game.

The topic of business models happened to come up at the GAMBIT event at MIT titled “Indies will shoot you in the Kneecaps”.  Eitan of Firehose Games, Ichiro of Dejobaan Games, and Scott of MacGuffin Games and now of Viximo, talked about working for Indie Start ups in all stages of operation.  The moderator was Alex of Owlchemy Labs who stepped out from behind the lap top to answer a question himself.   For PC games check out a business plan for a computer game…  But let’s shift focus to mobile games for a moment and take a look.

Some of the MIT students had questions relating to the business model for releasing games as apps.  They were concerned about spreading the game while also recovering some money.  The price point of most games needs to be low in order to attract an audience.  Competition is fierce to drop the price and get more players.  But development costs need to be recouped.  How do you make sure to have some kind of return on investment while still attracting an audience?  From that discussion came these suggestions about business models for your apps.

The Long Game: Give away your app for free to build a fan base.  Worry about recouping development costs later.  This method works if you are in college and have the time to really focus on community development.  In college you have time and a roof over your head to make games which build a name.  This is not a great option for those who do not have resources to cover their expenses up front.

The Guilt Game: Give away low cost of free app, have in app purchases.  This requires using a system that allows for in app purchases.  Which apparently completely excludes Microsoft products.  Some players may have negative attitudes towards in-app or in-game purchases, and this may drive some audiences away.  Many times gamers feel that a free game should be completely free.  They erroneously believe that games appear as if by magic, and there is no cost associated with the production of said games.  Free to play games are slowly eroding that stance.

The Twin Game: Release a free version of an app that contains ads along side a paid version of that app which contains no ads.  This requires more work, and more development time.  Not only do you have to code a version of the game which contains some kind of ad support, but you also have to code one without.  While this may not exactly double the amount of work you have to do before launching a title, it will require more resources.  However, it will allow players to self select into the kind of game experience they prefer.

Have you launched any games under these models?  Mobile or otherwise?  Any horror stories about a method that you will never use again?  If you know someone that can use this information don’t forget to +1 the post!  Or share with them directly through twitter.