We’ve released a lot of games on several different portals so we’re quite experienced with the Greater Internet Bastard Theory and how it is prevalent amongst what seems like a significant portion of the Flash game playing community. Last month we launched a single-level teaser of the upcoming Battalion games, and I must say, even though I usually can brush off this type of thing, many of the responses to the teaser level really left a bad taste in my mouth.

We wanted to put out Battalion: Skirmish for a few different reasons:

1. We wanted to raise awareness of the fact that there were additional Battalion games in the works, that they were coming soon, and that there would be a level editor and competitive multiplayer.
2. We wanted to recruit additional beta testers for Arena, the multiplayer version of the game.
3. We wanted to pimp the iPhone release of our puzzle game, Robo Riot.
4. We wanted to get feedback about all the changes we made since the first Battalion, Nemesis, including all the new graphics.
5. We recoded significant portions of the game (including a total rewrite of the AI, the UI and many of the rendering systems), so we wanted to get this code battle tested.

We released the game early on a Friday evening. By the time I went to bed, the game was hovering around almost a thousand plays and had a very respectable rating of almost 4.2 on Kongregate.

When I woke up on Saturday morning, the number of plays had jumped to almost 20,000, and the score had dropped to almost 3.6. Although that is only a 12% drop, it represents, for me, the difference between a Great Game and a Decent Game. I was really surprised. Battalion is a GOOD game, how could it be at 3.6?

After my initial panic, I realized that my biggest mistake was in failing to manage expectations. In the description on Kongregate I clearly stated that this was just a teaser level, and what our goals with this release were. When I read over all the comments, it was clear that the length of the game was failing to meet the player’s expectations and so they felt compelled to punish me for it. They hadn’t read the game description. My first reaction was to ignore people who were going to be that stupid. Then after I settled down a little, I understood that I couldn’t expect people to read the game description when even I didn’t read them most of the time.

So, I put out a new build that made it very obvious that the game was just a teaser level and that it was a sneak peek (actually, I said sneak peak which I left up on purpose), and updated the description:

Some people missed in the description that the purpose of this game is to get some community feedback on the new features, and also to give people a sneak peak at the game itself. I updated the title screen to show this more clearly. I don’t know if its too late to change anything, but such is life. I apologize to anyone who was expecting anything more than just a mission showing off a couple new units and the new graphics.

I think it is pretty obvious from this little excerpt that I was not at all happy how this little teaser level experience had turned out. In fact, I remember thinking how unfortunate it was because I would NEVER attempt another teaser level again because the feedback from the community was almost entirely useless, and, if I took it literally, would give me very bad feedback about future games even if they were awesome.

Time has passed and wounds have healed. I knew then that I had failed to manage people’s expectations and I know this is even more true now. After I made the changes to the title screen, the score started creeping up and it has settled at 3.74. I really wish I could see statistics about how many 1/5s there are because I think it would be very telling.

The game has hit almost 1.2M plays after three weeks, which for a teaser level is sort of amazing for me. Despite the bad rating on Kongregate, I feel like it has achieved all of its primary goals. We got tons of valuable feedback and bug reports for very obscure edge case bugs. The iPhone port of Robo Riot got as much exposure as I could have hoped for. I don’t think I’m ready to give up on the idea of small teaser games or previews, but I do know that I’m going to approach them a lot more carefully in the future.

This puts me in a fairly unique position to comment upon the production cycle at what I dare-say is a fairly typical development house. I have a degree of experience with generalized project management and have been a life-long gamer and for the past few years a game-writer, so I understand the basic structure of gaming. Getting in up to my elbows in the swamp that is production, though, has been an illuminating process, and something I’ll likely be writing about with some degree of regularity here.

Now: the topic at hand. Urbansquall released recently Battalion: Skirmish, a one-level preview for its upcoming releases in the Battalion franchise (multiplayer, single-player and cooperative games are due to be released in frighteningly rapid succession over the course of the summer). I had joined on as a producer at the final stages of Skirmish’s lifespan, and was asked to assist in its general release to some of the major Flash game portals that Urbansquall releases at (Kongregate, Newgrounds, etc.). And here’s what I learned.

1) Verify the .swf you will be Uploading

I would sincerely hope that this comes across as a massive no-brainer for everyone out there, but it bears mentioning. This is especially true if you are releasing with any degree of exclusivity to any particular portal. If that’s the case, it’s likely that you are releasing an .swf that has full-functionality with your main portal, and limited functionality with all others. It’s pretty crucial that you verify that the .swf will behave properly in each location. So, pretty please, take the extra time, check your file.

2) Pay Attention to the Small Things – Short vs. Long Description, Instructions

Do not underestimate the power of these small items. If you’re releasing a game on a major portal, you’re talking about hitting into the hundreds of thousands of gamers—a pretty hefty demographic spread. This horde of gamers is also choosing between a mob of games to play. How do they choose which to play and which to avoid? Presentation. And this is presentation before they have even loaded your game, so pay attention to the little things.

Most portals have two sets of description you can post, a short and a long. The short will display on their main page, the long once the game-page has been loaded. Some tips for creating these descriptions.

Your short description needs to be carefully crafted. Chances are you have no more than two fairly short or one complex sentence to get across the sense of what your game is. Don’t waste your time spouting how great and revolutionary your game is. Do give the gamer a sense of what they have to look forward to. What action can the gamer expect from your title? What experience will they be having? Distill that concept down to a single sentence. That’s your short description. If your game is part of a series, find a way to work that in, especially if the earlier games were popular. People will zero in on that keyword immediately.

The long description is where you want to get into the various features that will give your game legs. Think of anything that might be unique selling points, anything that will allow the player to customize or extend their gameplay past a single run-through.

Instructions: just because you have them in-game doesn’t mean you should half-ass writing them out by hand. Maybe in-game you were limited by screen-space or functionality. Take the time to write out some solid instructions for posting alongside your game description. It’s a useful exercise, too, because perhaps it will highlight something to you that you had overlooked previously. And when it comes to Instructions, step 4 below is crucial.

3) Choose the right Thumb

Thumbnail selection is probably the single most important step here. We’re very visual these days, and Flash portal main pages are rife with images. If your screenshot does not stand out in some way, you are lost in a sea of colors. Just as your short description should encapsulate the feel of the game experience, so should your thumbnail. I’m a fan of including notable in-game art. The player character, a cool enemy, a critical power-up. Something that will give the player a sense of what the game will actually look like. Thumbs of the splash screen are doable, but less exciting. That art likely doesn’t reference what the game will actually look like. It’s either boring or disingenuous, and those are both bad. Bottom of the rung in my opinion is a thumbnail showing the game’s title. I know what the title is. It’s right next to the thumb. Now I just see the title twice.

4) Have Someone Else Review All of your Release Materials

I cannot stress this enough. Even if you are a one-man development team, you need to have someone else review your materials. In fact, it’s better if someone who is not part of production review these materials. You’re too close to it. The concept is to have all of these items grab someone unfamiliar with the game and pull them in. Who best to review than someone who is actually unfamiliar with the game.

Do your thumbs look clear? Or are they too jumbled? Does the description give them a good sense of anything? Is the longer description readable? Do the instructions make sense?

Never underestimate your ability to gloss over mistakes. The brain is adept at this. It autocorrects, so be sure you have a failsafe.

Robo Riot on the iPhone

Robots are tired of doing the bidding of their human masters and they’ve figured it’s finally time to overthrow them. Robo Riot is an iPhone port of our recent Flash game of the same name. As it turns out, the game is very naturally suited to the iPhone platform and, dare I say, is even more fun in a mobile setting. Give it a whirl and let us know what you think!

Battalion: Skirmish

Take command of the mighty Warmachine and lead your troops to victory in the latest chapter of the Battalion saga! We wanted to celebrate the release of Robo Riot on the iPhone, and show off some of the tasty new graphics and features in the upcoming Battalion game. This is just a single-level teaser, but it should be enough to give you a pretty cool idea of some of the fun stuff you’ll be seeing in the rest of the series.

In the past, I’ve discussed the importance of using version control and also ways for structuring your subversion repository. Today, I’d like to cover an important best practices with version control whether you are a lone wolf developer or you frequently travel in a pack.

After you’ve wrapped your head around version control (and I’ll be honest, it baffled me the first time I was forced to use it), there’s only a couple more best practices you need to be aware of to get the most out it.

Don’t Commit Conflict Bait

Conflict Bait is basically something that’s going to generate conflicts pretty much any time a team member updates from the repository. A good example of Conflict Bait is the swf file that your project generates when you build, or intermediate build files that your IDE might generate. Don’t put these in the repository, because you will publicly mocked by your more senior team members when they are forced to remove them.

Exceptions: This one isn’t such a big deal if you’re the only person working on a particular project. When you are rocking it solo, it can sometimes be useful (read: lazy) to let version control track your builds so can look up old versions without checking out a fresh copy of the whole repository.

Write Comments In Your Commit Message

This one is a bit of a “Duh, really?” When you’re going back over a log of 1,000 commits, you’re going to be sorry you didn’t leave the breadcrumbs to help you track down that bug in that feature you haven’t tested in over 3 months.

Only Commit Verified Builds

Don’t commit code that breaks trunk. If you do, you will be shot and beaten. Resist the urge to commit that untested feature right before you sign off for the day. This is the absolutely WRONG thing to do. Perhaps your fellow coders were planning a code binge that night and your last minute tweak sends them on a 4 hour bug hunt instead. Don’t do this to your teammates.

Exceptions: This again is more applicable in a team environment.

Close Your Open Files Before Updating

Sure, Flash Develop or Flex Builder will usually warn you when a file has been externally updated and ask you if you want to reload. Usually. In my life, I’ve wasted at least 2 day’s work undoing the damage caused by accidental overwrites after the IDE failed to recognize an update changed a file. Close your open files, then update. Don’t be that guy, really.

Make Your Commit As Small As Possible

You might think you’re awesome by making monolithic commits, but you’re really just overcompensating. The best commits are ones that are as granular as possible. This is a good practice for numerous reasons, and one that helps support many of the other best practices already mentioned.

1. It keeps your project manager informed of your progress. If you’re making commits every 5 days, it doesn’t matter how big they are, you still look like you are not pulling your weight when your project manager gets his daily commit log and your name isn’t on it.
2. Your commit becomes easy to refer to because of its unique revision ID. It becomes an entity that can be referred to, entered into bug databases, etc.
3. When you’re digging through logs that have one succinct change applied to a single file, it is far more useful than a commit log that is 9 pages long and involved 30 files, which may or may not be related to your current search.
4. Your commit becomes easy to undo. Let’s say you really screwed things up and totally broke a feature (and then went to bed for the night). Your team members can see quickly from your commit log that revision 324 was a granular commit related to that feature and is likely the source of the issue. They can roll back the change and move forward while just cursing you briefly.

I’ve been using version control in a team environment for about a decade now. Hopefully this helps you benefit from some of that experience.

Showering is an important part of everyone’s daily routine, even if it is one that programmers avoid too often. At Urbansquall, the daily showering ritual has taken on a whole different meaning. It is during this time that many of our most difficult problems are solved, or our most creative ideas born. Let’s delve a little deeper into “Shower Moments” and the critical role they play in effective game development.

Shower Moments Defined

A Shower Moment is an epiphany, a moment of focused clarity that changes your perspective on a particular design choice or implementation challenge. A Shower Moment doesn’t have to necessarily occur in a shower. It can happen while you’re on the toilet. Or while you’re eating a cheeseburger. Or while you are out walking your dog.

The Importance of Shower Moments

At the start of this year we had an impossibly short deadline to deliver a fairly complex game for one of our favorite clients. I was not sure if we would deliver the game on time, but I did my best to remove any production obstacles by trying to design the entire game up front before a single line of code was written. This worked as hoped for the most part, at least until a few days before the game was supposed to be ready to ship.

The controls were designed in a vacuum, and, in practice, they were far too complex. Everyone was too busy hammering to get the game done in time to notice, until I had one of these “Shower Moments” when my subconscious basically slapped me in the face and said “The game sucks and it is because of the controls!” Fortunately, we had just enough time left in the schedule to redo the control scheme. This didn’t instantly make the game great, but it saved it from being a total catastrophe. I became peripherally aware that shorter game development schedules were risky not only because there was less time to polish, but also because of something else. I just couldn’t put my finger on it.

The Shower Moment of Shower Moments

I only became acutely aware of the concept of the “Shower Moment” this year while attending a panel at the GDC. A developer from Capcom was complaining how difficult it was dropping from a traditional 2+ year development cycle to a 6+ month development cycle for console downloadable titles. The thing he lamented the most was not that it required smaller teams, or smaller scopes, but simply that there is a lot less idle time during a 6 month project than there is in a 2 year project. And no, the implication was not that 2 year development cycles have more downtime during production (they might), but rather that there was just less time with the project in general.

This is something I alluded to in my article about Maximizing Efficiency By Taking Breaks, so I was peripherally aware of the importance of this idle “production” time but I just didn’t fully grasp it until that panel.

Why Shower Moments Are Important

It’s possible to do a lot of proactive design and problem solving before production, but it is so rare that a game ends up being made exactly as it was penciled on paper. Throughout the course of a game’s development there are hundreds, if not thousands of little unplanned decisions that ultimately combine to create the final package. It’s fairly tempting to brute force all these decisions as they come up and often we have to do this. Many times these gut shot decisions are correct and life carries on, but frequently we’ll make a mistake, or base a decision on a false belief.

Shower Moments are vital to a game’s development because they help fix the problems that can’t simply be fixed with a hammer and a nail. Shower Moments are there to give you that solution that is out of the box, to fix the problem that is so pervasive you may not even notice it.

Why Shower Moments Work

I’m sure there are a lot of reasons why Shower Moments work. I believe it has a lot to do with our subconscious’s propensity to solve problems differently from our conscious. It could just be that sensory deprivation (specifically in the case of a shower where everything is white and the sound of water drowns everything out), activates a different problem solving part of our brain. I believe we have all experienced these moments, even if we didn’t recognize what they were, so I believe it is just self evident.

Employing Shower Moments for Success

The biggest problem with Shower Moments is they can’t really be forced, and they are often the most important when you are least likely to have the ability to rely on them. My goal now is to give each important project enough time to have all the Shower Moments it needs in order to achieve its full potential.

It is a luxury, one that is not always afforded, but with the knowledge that this critical element of game development exists, I can at least start each project hoping to give it enough breathing room to let these important insights bubble to the surface.

I took copious notes at the Flash Gaming Summit that was held the Sunday before the GDC began. I thought that I might transcribe my favorite parts of the sessions and post them up on gamepoetry so that everyone could benefit from all the great information that was being shared. Turns out the furious note taking was pretty much completely unnecessary because Mochi Media ended up pretty much posting the whole thing for the world to view.

I had the opportunity to go through my notes this week and reflect on some of the things that were said and discussed. As I reviewed my notes, I noticed four nuggets of wisdom that were worth highlighting, even though the sessions were all available anyway. These are paraphrased based on my very short-handed notes:

1. Stephen Harris (Ninja Kiwi) – You need fresh eyes on your game constantly. Familiarity tends to amplify the perceived success or failure of a design.
2. Daniel James (Three Rings) – With all their knowledge and experience, Three Rings still make design mistakes. They’ve learned to use playtesting to guide their instincts.
3. Paul Preece (Casual Collective) – In competitive multiplayer, microtransaction models make you hate your rich friends. In cooperative multiplayer, microtransaction models make you love your rich friends.
4. Chris Hughes (Flash Game License) – It is okay to let the portals handle the monetization of your flash game, but make sure you’re participating in the benefits if your game is a runaway success.

Follow this 4 step process to make infinite sums of money making flash games!

The Steps!

Step 1: Make a game. Preferably a clone of an existing Flash game.

Step 2: Integrate in-game ads.

Step 3: Release on Newgrounds.

Step 4: Profit. Or Cry.

Mythical Money

If you think that’s the key to creating a viable business making Flash games, then you’re in for a bit of a reality check. Don’t get me wrong. There’s a percentage of people that will actually pull it off. It’s not quite as unlikely as winning the lottery but it’s not the type of business plan that’s going to impress anyone but your 13 year old nephew.

The myth of the Flash Rockstar is real. Media, even the smaller channels that cover Flash games, like to report on success stories because they tend to be more interesting than failures. “Developer Made $400,000 with Successful Flash Game” is always going to be more interesting to research and write about than “Yet Another Developer Fails To Recover Costs on Flash Flop.”

For every Flash game developer who is making a living off his latest runaway Flash hit, there are literally thousands more who are getting what amounts to nothing for hundreds of hours of hard work.

Diversify for Success

The reality is that becoming a successful Flash developer without relying on the “Luck Factor” requires you leverage every possible income stream available to you. You have to hustle. You have to work your contacts. You have to cut corners and save costs wherever possible. You have to work with people you trust. You have to take risks when it is smart. You have to avoid unnecessary risk like the plague. You have be brutally honest about your strengths and weaknesses. Mostly, though, you have to work your ass off. And you have to do it despite the constant stream of obstacles and setbacks you will encounter.

Sources of Income

The good news is that Flash development is one of the best ways for a talented developer to make money while working on games. There are many creative ways to generate income from Flash game development, and the start up developer needs to do their best to leverage these as much as is reasonable. Here are what I consider to be the primary sources:

Contracting

Generally speaking, this is when a client comes to you and says “We want a project that does XYZ and looks like ABC.” You build it and then they cut you a check. Sometimes you get to reuse the source code on future projects, but generally it’s Work For Hire. This stuff tends to be pretty faceless as it is contracted and sub-contracted down a long line of people with their hands stuck out. I can’t really point to any specific companies that are leveraging this for success, but the richest Flash companies out there are the ones doing this sort of work.

Licensing

This is what I call a “spec” projects that are created without the commitment of an external party. The majority of this income comes from sponsorships, but a notable portion of it comes from licensing older games and doing site-locked licenses for 3rd parties. It seems that Nitrome is basically printing money with this technique.

Advertising

This includes income received from anything related to ads, including Mochi and Google Ads. Generally it ranges from really crappy CPMs from in game ads, to respectable CPMs from custom deals negotiated directly with ad providers via something approximating a developer-run portal (the Ninja Kiwi method).

Upsell

This method of income generation usually requires some level of creativity on the part of the developer. Basically it means converting your free users into paid users by either charging for a premium version, a subscription, or integration with some sort of mictrotransaction driven setup. Fantastic Contraption rocks this technique.

There are definitely other ways to make money with Flash game development, but I consider these to be the most accessible to the average Flash developer.

Risk Versus Reward

Each one of these techniques has its various pro’s and con’s. Contracting tends to be very lucrative, but also very grinding and creatively bankrupt requires you to be constantly networking. Upselling tends to be SUPER risky, and very labor intensive to set up, and has a history of failing far more often than it succeeds but in the right situation it can pay off handsomely. Advertising tends to be low effort and low risk but generally it performs very poor in all but the best cases, but it can create some reasonable residual income. Licensing is far more reliable than Advertising and Upselling, but it tends to have a glass ceiling and doesn’t consistently generate remarkable income.

Where Urbansquall Makes Its Money

In 2008, Urbansquall’s income from these techniques broke down as follows:

1. Contracting
2. Licensing
3. Advertising
4. Other (includes Upsell and other miscellaneous sources of income)

The first year I started making Flash games the rough distribution was 90% Contracting versus 10% Licensing with negligible income from the other sources. Over the course of the last six years, the Licensing portion of the distribution has been steadily increasing. 2008 was our best year for advertising, and yet it failed to even make a dent in the big picture.

My hope is that 2009 is the year in which Upsell and Licensing combined overtakes Contracting as Urbansquall’s primary source of income. Bloody Fun Day is helping make this a reality with its sponsorship contributions and I have high hopes for the upsell portions of the upcoming Battalion games. So far, though, contracting is already setting the curve. It should be a good fight.

There are a few Open Source Actionscript projects that Urbansquall relies on for most of its games. Here’s an overview of the three open source tools that we’ve found essential to Flash game development.

BulkLoader

For any project where we need to load external files, we’ve come to rely on BulkLoader. If you’ve ever tried to load a few hundred files at once with AS3, you know that at some point Flash will fail fairly silently and just refuse to load the data you require. That’s where BulkLoader fits in. When you try to load something with BulkLoader, if its there it will arrive. No exceptions.

Box2D

Box2D is quickly becoming our de facto solution for anything related to 2D collision detection and resolution. There’s not much to say about Box2D except that it was the first Flash physics engine that did it right, and it quickly destroyed all the competition. We <3 Box2D.

Tweener

I feel dirty every time I use Tweener, but its ease of use and raw power makes it the most common open source actionscript we rely on here at Urbansquall. Even the most stale UI can be made to pop after a few hours in bed with Tweener.

Others?

There are plenty of open source Actionscript projects out there, here are some we hope we get to play with sometime in the future:

• Papervision3d – 3D Engine
• SPAS – UI framework
• AsWing – Another UI framework
• FAR – zip support

Of course we rely on the gamepoetry open source resources more than anything else.

Several of the 4k Flash Game competitors graciously agreed to write post mortems for their 4k Flash Game entries. Each of these competitors gives us a different perspective on their unique approach to the competition and the challenges they faced in implementing their chosen designs.

1. Steve gives us the skinny on Face Dodge
2. Jeff wrote a novel ( )about what went into Mine-x
3. Matt wrote up his experience developing Gompers
4. Clint gives us insights into the work that went into Falling With Style
5. The winner of our Audience Choice award, Filippo, educates us on putting 3D into 4K in 4k Pillars.

Thank you Steve, Jeff, Matt, Clint and Filippo for taking the time to give us a glimpse of all the hard work and thought that went into your development process!

The results are in, and the Audience Choice award goes to 4kPillars! This isn’t all too surprising. 4kPillars was actually the highest rated game from the judge round up but it could not place first (or second for that matter) because it was a closed source entry.

4kPillars narrowly beat out the excellent Ghost4koin and the stand out Falling With Style. Congratulations again to all participants!