Knowing which ideas are the right ones to make is the hard part.  So what to do?  How do you know when an idea is the right?  This is how I do it.

First: start with some limiting criteria: must work on this platform, must use a specific control scheme (one button/touch control on mobile), be for a specific audience, be in a specific genre, etc.  Most people do this without realizing they are doing it.  But if you can be thoughtful about the criteria, it let’s you dig deeper and identify special characteristics that can help with generating ideas.

For example, the Wii is known for its innovative motion controls and family fun.  That means people expect some amount of motion controls and the audience tends to skew towards women and children; so your ideas should fit.

Second: generate a list of ideas.  I know some people who start working on the first thing that pops into their heads, but personally, I like options.  The first thing you think of could be great… or it could suck, without any comparison, you won’t know until your release… that’s the worst time to find out you picked the wrong idea.

Third: narrow it down.  Now that you have a list of a ton of great ideas, narrow it down to your top 10.  Pick your personal favorites, but keep in mind the criteria.  Also, know what you are capable of.  This is really important.  Don’t use this knowledge to limit the ideas, but use it to narrow the list.  If you really love an idea but realize you can’t execute on it right now or it doesn’t fit the criteria, save it for later.  Don’t try to make a mega game unless you have the team and budget for it.

Fourth: use Market Research to cut some more.  Do some market research and reduce the list to the 5 ideas that have the best potential in sales.  Do any games like the ones you want to make exist?  If so, how well did they do?  Is there room in the market for another?  Can you improve upon the idea?  Is there something about your idea that will make it different from the others?  If yes to all, then keep it on the list, if no to any, then cross it off.  If there is nothing like it, it will be harder to project potential, but you can still determine if it is something people are asking for… or if it is something they will want once they know it exists (be honest with your assessment – but know that the next step will weed it out if you are wrong).

Five: Focus test your ideas.  By now you probably have around 5 ideas that you absolutely love and after doing the market research you are sure they can all be hit games.  You can only do one though… and even if you are being super objective, some bias probably still clouded the results.  This is where focus testing comes into play.  There are a couple ways to do this, from asking friends to paying an agency.  Whatever you do, you need a lot of people who fit within the audience profile to get a good representation and to avoid ties.  If you don’t have a large enough network to tap into, you can engage your audience online.  Whatever method you use, it is important that the people you ask match up with the primary audience for the intended game.

Six: We have a winner!  At this point, there should be a clear winner.  You now have an idea that you love, which has an audience, is relevant on its intended platform, and people agree with you that it’s something they’d like to play.  Now comes the hard part: execution!

To be continued…

Super Nut Jump taught us a lot about handling our assets for cross-platform projects. Our pipeline worked, but it was time-costly in a tight spot because things just needed to be done, not done efficiently. Now we have time to prepare for future projects by using a slightly modified version of the Super Nut Jump pipeline, made possible with Flash. Flash makes setting up a cascading inheritance system extremely easy. Applied properly this can lead to massive time savings, even in the face of ‘need-it-now’ changes.

The Problem With The Cross-Platform Pipeline

One way of developing for multiple platforms requires several sets of assets tailored to different screen resolutions. This means the same assets and animations at many different sizes, which in turn means a lot of resizing and exporting. The issue is compounded because all assets will eventually change, and going back and resizing and re-exporting everything is a time sink even with vector based graphics. Waiting until we think we’re asset complete before exporting for other platforms isn’t a good solution either because we’d like to be testing on as many platforms as possible as soon as possible.

So how do we quickly change, update, and export the assets for every platform? We use Flash to create a cascading inheritance pipeline.

The Cascading Inheritance Solution

It’s not exactly an award winning infographic, but this figure illustrates the basic pipeline for getting all of our assets:

Figure 1

The Mother FLA allows us to do all of our editing in one file throughout the duration of project. (We could also have it inherit from other files itself if we needed multiple artists to be working on the project at a time.)

Once we have all of our known assets in some initial placeholder state, we can start saving out copies of the Mother FLA and resizing them to fit different resolutions. Each movieclip in the libraries of these Sized FLAs has to be set to inherit from the Mother FLA. This way when we make changes everything can be updated without having to resize it again.

Once everything is sized properly, we use the Sized FLAs to save special PNG Export FLAs that will contain only the graphics we need to export to PNG format. This is done because Flash exports everything that is visible on the stage when it exports PNGs, so we have to tailor the size of the stage to each individual PNG graphic so we aren’t dealing with massive images full of wasted pixels. We can still have multiple graphics in one PNG Export FLA, though (all standard sized buttons, for instance). The PNG Export FLA libraries should also inherit directly from the Mother FLA.

The inherited libraries allow us to easily make changes once and have a full set of ready-to-export, pre-sized assets for every targeted platform.

Smoothing Out The Process

There is always a high probability that the graphic needs for the game will change course during production. That could throw a wrench in our system if we wanted to add something new. Any fresh artwork might have to be dropped into all of our Sized FLAs and painfully calculated to be resized in each one. To remedy this, we can keep things grouped together logically in big movieclips (all buttons, all menu items, all characters). That way when we add something new we can stick it in a movieclip that is cascading down the pipeline already.

Keep your library organized from day one, asset one. As soon as your library gets out of hand you will be spending half an hour a day digging through it. This is true for each library, but it’s most important in the Mother FLA.

Keep a folder in the Mother FLA to contain all of your old, out of date assets and animations. This will be helpful later if design needs are reverted.

Use Flash Project folders to build all of your .FLAs at once, updating every asset for all platforms with a single click. Set all of your inherited movie clips to update every time the FLAs are published, and publish the whole project at once.

Movieclip inheritance links will break once you edit a movieclip. If you want to keep the link you will have to reset it after editing. Because we are embedding multiple graphics in single movieclip containers (all standard size buttons), we would want to turn certain layers on or off before publishing. This counts as an edit and will break the link. We could export and re-establish the link afterward, but this adds a complicated step to the pipeline. To remedy this problem, we can nest asset movieclips in a container movieclip that will update everything, and keep the single movieclips on their own top-level layers we can turn on and off without breaking any links. This bloats our top-level timeline a little bit, but is worth it.

Save out some templates for different screen resolutions. These can be used as a reference only, or you can copy and paste your content from the Mother FLA into these pre-sized templates instead of saving a copy and changing your stage size every time. When copying content into a template, select all (ctrl+a) and use locked width/height to quickly scale everything using a precisely calculated number. Have a stage outline rectangle specifically for matching everything up by snapping the corners to a grid.

Limitations

In this pipeline, absolutely everything has to be inside a movieclip. Top-level free artwork will not inherit down, so it has to be contained in something that can be grabbed from another FLA automatically.

This system does not export final assets automatically (still working on that one), so any changes to graphics will still have to be re-exported for every device after they are updated.

Using this system is also going to require a lot of forethought and prep work, which may be counter-productive and slow down the beginning of your project. Having a dedicated ‘pipeline negotiator’ would help alleviate this issue, but it will still result in time savings with even a single artist.

Conclusions

We will be using this Cascading Inheritance system for future projects until something better reveals itself. It’s a great way to keep our assets organized, consistent, and easy to update. It’s fast and reliable, but does require some invested preparation. Please share your thoughts, questions, and any tips you might have. If you try this out, let us know how it goes! Next time I’ll tackle how to design the assets themselves for a cross platform production.

So last October, with the Kindle Fire launch a month away, we decided to try our hand at mobile games, starting with Android.  We’ve released 3 titles since then on the Amazon and Google Play app stores. Our most successful title has been Zombie Chess, which launched December 28^th, 2011.

Since then we have expanded our technology to allow us to build iOS, Android, and Web games simultaneously with a single code base.  We split the team, which was small for a Facebook company but large for a mobile company, into 4 sub-teams, each working on their own projects.  To stay focused, we created the following guidelines for all the teams to follow:

• The game must work for Web and Mobile;
• The game should take less than 2 months to complete; and
• The teams must spend the same amount of time polishing and improving the game after it is “completed;”
• The game should be polished until it is fun and interesting;
• Each new game should be an improvement in quality over the previous games;
• And there has to be an audience for that type of game!

This brings us up to today – we now have 3 games that are weeks away from launching (the 4th team has been working on client work – we are bootstrapping after all).  Over the next couple weeks, we’ll be sharing our thought process on all the games, but below is a sneak peak at Super Nut Jump – a game about one young squirrel’s dream to fly high – coming soon to web, iOS, and Android. ]]> http://purebang.com/focus-attained-super-nut-jump/feed/ 0 http://purebang.com/now-were-bloggin/ http://purebang.com/now-were-bloggin/#comments Wed, 23 May 2012 17:07:33 +0000 http://www.purebang.com/?p=107

Welcome to the Pure Bang Games blog. We’ve avoided blogging in the past because we were intimidated. I mean, who cares what we have to say, and how can we possibly write interesting posts week after week?

I used to think the same thing about speaking at schools and conferences until I started doing it. I am still amazed that when I speak about my game development experiences, people not only listen, but ask a ton of questions. Whenever I meet another developer, we have a great time talking about what we are doing, how we are doing it, and the results. It’s not only informative, but inspiring.

Recently, we released our sixth game, Corril Slayer. Despite being written about on Kotaku, Rock, Paper, Shotgun, and other sites, the sales were lower than what we expected. I will be writing up a post-mortem about the game in a future post, but one of the big reasons I feel that it didn’t get the desired traction is because nobody knows who we are. There are a few reasons for that. One is because we started on Facebook with a game called My Pet Rock, which is played mostly by women and tweens outside the U.S. But I think the bigger reason is that we haven’t given anyone the ability to know us. Sure we use Twitter, Facebook, and we have a website (without a blog until today)… but we’ve done a poor job communicating to our would-be fans anything about us as people, why we make the games we make, and most importantly, why they should care.

Hopefully, today’s addition of a blog will fix that. We will be posting on all sorts of topics that we think are informative and inspiring, including lessons learned, technical walkthroughs on animation, and our favorite games. We hope that you will follow along and get to know us, and we encourage you to respond so that we can get to know you, too!

This is our voice. We hope you like it!

Sincerely,

Ben Walsh

p.s. Thanks to Noonan and Yuzun for getting the blog set up.