Contests or how to trick developers to work for free

Contests have been a big part of flash game development since… ever I guess. Back in the days where portals got all the cash and flash developers worked for the simple love of the (usually awful yet addictive) game that having contests was a way of pushing some coins to the developers.

Right now (and let me remind you that this is the end of 2008) a lot of developers look for ways of making money from their games. Either pocket change to buy the next console game or to make a living from their flash creations. This is simple economic evolution of business model. The portals attracted users and for that reason, money was generated. Along the way, portals shared their earnings through investments in sponsorship deals and later on licensing deals.

Contests haven’t followed this evolution. Contests still exist based on the fact that developers want fame and glory, not money. It’s fair to say that the prize is usually money, but it’s a contest, not a business decision. It’s ok to have contests for developers who do it for fun, as long as the developers understand that someone will be making a load of money at their expense.

I’m writting this because Mochi Ads and Arcade Town joint forces to put up a old-school contest. The winners of the contest get sponsorship deals from Arcade Town. Here’s why this is tricky…

1. To enter the contest the developer has to distribute the game using Mochi technology. By definition, a distributed game has no sponsorship or primary licensing value, so by entering the contest the developer hands over the possibility of getting a deal. Mochi Media on the other hand, has a bunch of games to distribute and Arcade Town has the exclusive right to sponsor the games, since no one else will want it.

2. To enter the contest the developer must use the tremendously bugged version control system from Mochi. The reason is simple: As soon as the winners are announced, to have access to the prize money, they have to brand the game with Arcade Town’s logos. Without the version control in place, the already distributed versions wouldn’t have Arcade Town’s branding, therefor this wouldn’t be interesting.

3. In the forums, where the discussion piles up, some Mochi’s employees use a sentence that really gets on my nerves: “You’ll have bragging rights if you win!” What these folks are saying is: it’s not important that you are potentially loosing money as long as you can brag about it.

The problem with contests is that it’s a way of getting the usual stuff (traffic) to the usual people (portals) with less money to the same guys (developers). Almost all contests are based on this: you have to brand to the contest holder or you cannot launch your game or you’ll loose any chance of a sponsorship deal. Contests are a way of tricking developers to work for free.

Time based vs Frame based

This topic pops up from time to time. Usualy because someone is having a hard time in getting his game flowing decently. Flash is so accessible that even the most obvious things done time and time again for more seasoned developers escapes the grasp of the vast majority of new developers.

“Stop the bla bla bla and get to business” says the little voice in my head! Ok! The problem is the use of ENTER_FRAME events. Games live off these events and those are used and abused without any care. Here are some rules to have your game running smoothly and frame rate independent.

Use only one ENTER_FRAME event

You should have only one ENTER_FRAME event. This should act as your game loop. If you have several events, you will have several game loops and not only this can be a CPU hog, but it can generate logic inconsistencies.

Having one game loop for ALL the game can be quite a challenge for a less experience developer, so I would adivse you to start with having one ENTER_FRAME event where it matters, for instance, on a movie clip that holds the levels, but your ambition should be to have one and only one game loop that holds a list of what it has to update.

Use delta times

Delta time is the difference between the last rendering and the current rendering. Write classes that take delta time into consideration. The main difference is that if you have a sprite that moves 5 pixels per frame, if the frame rate changes, so will the number of pixels the sprite moves per second. What you want to achieve is the exact opposite. Regardless of the frame rate, the sprite moves the a number of pixels per second.

Remember to remove your listeners

This is too easy to forget! When you don’t have the use for the events, remove the listeners! Even if you remove a movie clip from stage, the listeners will be active, thus bringing up the problem of multiple game loops and inconsistencies.

Hope this helps! Have fun!

Nonoba

One of the subjects I want to bring to this blog is a vision of the pros and cons of several portals. I considered several of them to start up this category, all pretty obvious, like Kongregate or Addicting Games, but I wanted something more… Nonoba provides that something more I was thinking.

“Why?” you ask… or don’t ask. First and foremost, Nonoba is a great site. It has the basic condiments of that make a modern gaming site: developer profiles, a ton of APIs, great social implementation, lots and lots of things to have both players and developers entertained for hours.

More, developers can make money from it. First and most obvious, Nonoba allows advertising, such as Mochi Ads or Game Jacket. Not that much traffic to make it an extraordinary portal to monetize from ads, but that’s always a good add-on for developers. Second, it holds weekly and monthly competitions, based on number of plays with some juicy prize money. Third, Nonoba has a micro-transaction API which allows players to win money from in-game features, like objects or extra content.

Sounds really juicy but… Don’t you hate when someone says “but” right after something really good is showed? What is the problem with Nonoba then? A developer can see Nonoba in two different ways.

The first is the typical one: you create a game, put up some APIs and hope to get some traffic. This is where the problem starts since most portals pay to have their APIs integrated and Nonoba does not. So, the developer has the trouble of putting their APIs up, testing it and hope the game does good enough to get some money from advertising. You don’t need a lot of math to see this is not worth the trouble most of the times.

The second route is to go for multiplayer and transaction APIs which Nonoba supports fully. First… the APIs are wonderful. Really easy, really good. But the problem with traffic stands again since you won’t be able to sponsor your game or even to distribute it because both APIs are heavily branded with Nonoba logos and worst, Nonoba register user buttons and so on. No portal is interested in having that kind of branding, therefor, the game will not be sponsored or even distributed, bringing the problem of traffic up again.

So… Nonoba is a terrific idea that will go really bad if they can’t build the traffic up. The only developers interested in doing some real work there will be the ones aiming for the prizes (some are really pros at this) or contracted ones, since the rest is almost pointless. Ok, there are developers doing it for fun, but most good developers are pros or getting close to it. All other developers will simply upload the games, hopefully get some hits and that’s it.

Good things: Technology, social aspects
Bad things: Over branding, no payment