Once upon a time in flash game development – part II

This two post series started because of some difference of opinions. On one side, Greg from Kongregate. On the other Ryan from Untold Entertainment. In part I I tried to set straight my own thoughts about why is flash market different, where do we developers stand and how our expectations can make it or break business wise. I also left a whole section open: production failure and that’s what I’ll try to address now.

What is production failure?

Every time we don’t finish a game and let it die, there is a production failure. All developers faced it. The problem with failing to finish a game is that it can become the rule instead of the exception. There are acceptable reasons to cancel a game production, but there are a bunch of reasons that are just excuses.

Another production failure is to start something aiming high and then accomodate with a small version of it. Been there, done that, I’m guessing all developers have, but again, there aren’t any acceptable reasons to shrink down a project that I can think of. We shrink it down because you underestimated the effort needed. I really can’t imagine any other big reason. We either don’t have the knowledge, or the technology or the time, but we should know that before starting the project, no excuses.

So this leaves us basically with…

Cancelling a game

All the good reasons I can think are met very early on. Flash wise I would say… two weeks tops for a ‘common’ flash game. All the good reasons fall in the category “prototype does not kick in as expected”. If the game isn’t going to work out mechanics wise it’s better to stop right there, let the your brain do the background homework and pick it up later on. Back to the drawing board or to the drawer until better days.

In my opinion, patching it or forcing a solution is not a solution. Better have a canceled game than a bad one. Trick is, you must notice this early!

All the rest is excuses… often developers say that after coding all the mechanics, the game wasn’t being fun at all. If you already coded all the gameplay mechanics, you are heading for the non-fun part. It’s part of the job! It’s the 10-90 rule!

90% of the game takes 10% of the effort

this relates to gameplay… then you have to build the rest… and then polish… and so on… meaning…

10% of the game takes 90% of the effort

and these final 10% of game production that take 90% of the game production time are usually not that fun to do.

And back to Greg and Ryan

Flash game developers are still maturing and it will take a while. There are great examples of established studios that are way ahead of the others from my point of view, but the core developer base still isn’t able to adapt, to grow, to learn and to be bluntly honest: to create games and do business.

If this market was a mature one I would say that Ryan was dead right and Greg dead wrong. But it isn’t… developers are still a giant snowball of bad pratices and unrealistic demands. Developers don’t want or don’t know when or how to adapt. Like I mentioned on part I, what makes us different in the first place was to think out of the box, yet many developers keep their heads burried in a box of bad business and development pratices and still think they have the right to complaint about it.

All developers want a lot of cash for a little work… c’mon… did you think it would be that easy? Think again. Greg is right, no one asked us nothing so to get what we want, we have to be faster, be better and accept no excuses. Only then we are in the position to discuss our true position in this market.