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.

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.

1. Mochi’s Re-cap and Round Up
2. Nitpicking the Flash Game Summit – from Kongregate’s Greg who reiterates a lot of his points from our recent Q&A
3. Some great and less great commentary from Gamezebo

I don’t think I can do the material justice in the short time I have available, but essentially there were a lot of great things about the conference (Mochi’s Ada did such a kick ass job on pulling off the event), but also several things that left me scratching my head.

1. A lot of the misinformation out there is being perpetuated by either people who really have no idea what is going on with Flash games, or by people who are deliberately spreading that misinformation for their own purposes. Even more scary is that some of these people wield a lot of power at some fairly substantial organizations.
2. Flash developers are increasingly treating this as a business and not a hobby and that has some interesting ramifications.
3. Most of the larger portals seem obsessed with establishing repeatable sources of revenue from Flash games that aren’t based on advertising, and that no one really knows quite how to do it (although everyone seems to be betting on synchronous multiplayer microtransaction games).
4. It’s a good time to be a competent Flash game developer.

We’ll chat about it in greater detail later.

If you’re like me, you might find this data to be somewhat discouraging. While some people might be encouraged by the idea of making $2,000.00 per exclusive game, consider how long it takes to produce the average game that sells on Flash Game License. If you could crank out a game every two weeks, never took any time off, and had zero overhead, you could make 26 games a year. At $2,000.00 per game, that means you could earn a gross income of $52,000.00.

Obviously that’s an over simplification because each game, theoretically, can build upon the next and can be leveraged in other ways to increase your average income across each of the games. But, at the same time, 2 weeks to make a game you can sell for $2,000.00 is going to be a challenge, and making 26 of those in a row is a pace that would be close to impossible to sustain.

So, what do you do? Don’t even bother trying, right? Well, no, it means that you need to be aware that the game you’re working on is unlikely to be a resounding financial success (it’s most likely to earn you between $1,000 and $2,000), so you need to make sure you have another way to pay your bills.

My recommendations:

1. Marry someone rich.
2. Live with your parents.
3. Don’t quit your day job.

Perhaps even all three.

One common problem shared by most indie game developers is an obsession with game ideas that are bigger than we can execute. Even the most realistic indie has to beat back the little voice in his head that keeps telling him to go bigger and (presumably) better. It’s great to have big ideas, but we need to make sure we bite off only the pieces we can chew. Rather than give up on our grand ideas, we need to break them down into smaller easier to execute pieces in a process I call recursive development.

In the last 14 months, I’ve employed recursive development on one big Urbansquall project, and actively chosen not to use it on another. One of these turned out to be a resounding success that is already set to be Urbansquall’s most successful game series, the other was a financial catastrophe that almost torpedoed the whole company. I spent a fortune confirming the validity of this approach and one of my greatest regrets was ignoring my gut instinct, and not utilizing recursive development to control the scope of the project that failed. I will not make that mistake again.

What is recursive development?

The core premise is that any large game is really just a combination of smaller medium sized games and that any medium game is in turn a combination of several smaller sized games. Recursive development describes the process where we take our grandiose game design and chop it into smaller games that we can develop and release individually, with the goal of working towards our final epic vision.

Why does this work?

Except for some very specific exceptions, the whole is rarely greater than the sum of its parts. In fact, a lot of the time, the majority of these component parts are not only unnecessary, they also damage the quality of the overall product by spreading our limited resources too thin. A development methodology that focuses on each part rigorously proving its worth as a standalone component results in a stronger final product that is cheaper and faster to develop, and is done so at lower risk.

While this doesn’t really apply to small single-concept games, it definitely applies in cases where adding additional features requires massive code changes (like adding multiplayer for example).

How have I applied and failed to apply this methodology?

Zombieland

The original concept was a cooperative multiplayer RPG survival zombie shooter game. I started by making a simple side scrolling zombie shooter. That was released as Zombieland: Bonesnap Boulevard. I never got passed this stage, but theoretically the next step would have added the RPG elements and the large, interactive world. From there would have been the persistent back-end and high scores and that was probably sufficient to release a new game. Then I could have finally added the cooperative multiplayer.

Recursive development worked here because it kept the development costs low. I didn’t have to do any multiplayer, RPG elements or back-end storage for the first pass, which also significantly shortened the time to market (approximately 5 weeks). I collected a check for this first release (it wasn’t a lot, but it allowed me to put some money in my pocket). It really lowered the risk by completely removing the need to find a distribution partner (or try self-distribute, which would have been a failure) – a necessary prerequisite for a multiplayer game. Plus, it let me fail (and fail cheaply) on a few key design choices (which ultimately stifled the game’s popularity).

End result? I screwed up. Made a little money. Built some useful AS3 classes that got reused on several projects following it.

Battalion

The first Battalion was a multiplayer-only game that took about 11 months to build, which, at an hourly minimum wage, meant that the net profit was negative. Very very negative.

I wanted to do a multiplayer sequel to that game (madness, I know). None of the code was reusable because of several features desired in the sequel and because of scale concerns with the original code base. Instead of going for broke, I designed the multiplayer game and then worked backwards until I had just enough elements to make a compelling singleplayer experience. That resulted ultimately in the release of Battalion:Nemesis, which Kongregate really liked and signed on to help fund and distribute two sequels and the multiplayer game.

End result? 2009 looks to be a banner year for Urbansquall with the sequel set to launch on my favorite Flash portal. I’ve made some money and got a game out there in the wild.

Discarded

I could write a book about Discarded. Indeed, several posts in the next few months will go over some of the tragic mistakes that were made that ultimately crippled that project. The biggest mistake I personally made was ignoring my instinct and deciding not to follow the recursive development methodology on the project (I ended up using “Release Early, Release Often”, which is a catastrophic mistake in game development, it turns out). Discarded is a multiplayer side scrolling collectible card game beat em up RPG. If it’s not obvious how many ways Discarded could have instead been a collection of smaller self-contained games, then you probably haven’t been paying attention.

End result? So much time was spent on all the other aspects of the game that the core gameplay was ill conceived and badly implemented. Many design decisions had to be redone several times (expensive) because everyone’s focus was elsewhere. No feature of the game really ever hit 1.0, and the game was a financial failure of epic proportions. If we had instead focused on a smaller game, a side scrolling singleplayer beat ‘em up, not only would it have been cheaper, we would have finished something and at least pulled down some sort of income in the form of a sponsorship. It would have been better for morale. It would have been less effort. It would have been much lower risk. The list really goes on and on.

Conclusion

It’s great to dream big. When you have an awesome concept for an epic game you want to make, consider that just the starting point of your design work. From there, break the game apart. Try to discover each gem of fun gameplay that can be extracted and be built into a separate game by itself. Do this for every aspect of the game. Now build each of the component games. You’ll be releasing smaller games, on a quicker schedule, all the while slowly building towards your ultimate goal. Instead of working towards one epic and overwhelming release target, give yourself the opportunity to have lots of small successes (and failures!) along the way. The components that survive the process will be the ones that are truly worth integrating into your grand vision. You’ll make more money, reduce your overall risk, and create better games in the process.

That being said, I think Jeff’s message is important just the same. Generally speaking you can make a lot more money in other industries, so don’t bother making games if you’re focused simply on the money. You’re here because you have a passion for making games and because you have to make games, there is simply no other option. Don’t let dollars (hard to get dollars, at that) deprive you of your reason for being here.

On every project there comes a moment where an obstacle keeps you from progressing. Either you can’t figure out a design element in your gameplay, you are uninspired for a particular level design, or there is a bug you simply cannot track down. If the clock is ticking, or you are highly motivated, your inclination might be to grind the problem until a solution presents itself. While there are many situations where this is the only option (like a deadline that is hours away), if you have the ability, you should take a break. Something I’ve learned over the years is that taking a break is the best way to make progress when you’re stumped.

Everyone needs to take breaks. There are dozens of studies that prove that efficiency improves dramatically when people take regular breaks. The question, then, is when is the best time to take a break?

Many people like to use breaks as a reward. “I just need to fix this collision detection bug before I can take a break.” In my experience, this is exactly the wrong approach.

You operate most effectively when your confidence is high and you have lots of energy and mental acuity. If you don’t take a break until after you overcome your obstacle, that last grind will have neither. If you are desperate, you will try lots of really bad solutions to your problem. Rarely will any of these work, and if you had a little more confidence or clarity, you probably wouldn’t have wasted your time on those solutions in the first place.

When you hit an obstacle that you cannot figure out, that’s precisely when you should take your break. Whether it is a trip to the restroom, lunch or just a quick walk outside. Your subconscious will kick in and use your idle brain cycles to work on your solution from new angles. Your conscious, however, will be engaged in what you’re currently doing, which will give it an opportunity to rest and recuperate.

You’ll return to your issue with a sharper mind and you will very quickly come up with a solution that just works. Many times it will be so obvious that you want to kick yourself. You’ll wonder how much time you could have saved if you had only taken your break a little sooner.

For maximum efficiency, you have to consider your break times as little release valves that let you step away from a difficult problem and return to it with greater focus and efficiency. Sometimes you just need a little break to have a breakthrough.

I wrote up a guest article for the excellent Gaming Your Way. It is a very belated post-mortem of a game we completed in early 2007 called Zombieland. The full article can be read there.

Resist the temptation to completely ad-spaz your company website. This obviously has some very important exceptions, but the most important thing to keep in mind, is what exact purpose does your company website serve?

I get depressed when I visit indie dev company websites and I see them plastered with advertising. It instantly screams desperation to me, which almost immediately turns me off whatever game I was here to look at in the first place. Ask yourself what purpose does your company website serve?

Are you selling games to consumers?

OR

Are you selling your visitors to your advertising partners?

Obviously it is not impossible to do both (as every major portal will show you), but unlike most portals, you are selling something else, and that is your company image. Portals don’t need to care as much about this as we indie developers do. Being indie is a part of what makes us special, and if we pretend to be like a big fancy portal (which we will no doubt fail at because we barely have enough time to make games, let alone compete with companies that are massive compared to us), we end up with a lose-lose.

So, you’ve decided to embrace your indie spirit, and you’re not going to pretend to be a big fancy portal, which means you’re selling your indie image along with your games. The little business man in your head kicks in and starts screaming:

MONETIZE MONETIZE MONETIZE.

He’s telling you to monetize every visitor, every visit, every hit, every EYEBALL.

The problem with this approach is that the quickest buck rarely turns the biggest buck in the long term. By trying so hard to monetize at every opportunity, you’re going to end up turning off a lot of people. The reality is that while some people can make a living off one hit game, most indie developers are going to spend years building up a portfolio and reputation which they can leverage to make a living off games. That desire to instantly monetize every possible facet of your website is going to damage you big time in the long term.

Think about what your company website is trying to do. If you are trying to pull eyeballs, and a part of your business plan is to monetize those eyeballs with advertising, consider creating a separate site that is distinct from your company website. Your company website can focus on maintaining your indie image, where as the game website can pimp your games and monetize your ad space with impunity.

No matter how you tackle the topic, just do your best to stay on top of your priorities and make sure you don’t go overboard on the advertising. Just remember that every eyeball that is looking at an ad is no longer an eyeball that is looking at your game.