Flash Truth

…about flash gamedev and business

Integrating GameJacket in your game

Hello again. I’ve read a lot of people complaining about the difficulty of integrating GameJacket in their games. I had a lot of problems when I did it the first time, biggest of all was that I assumed it worked just like MochiAds, meaning, it was a preloader. That is the biggest misconception about GameJacket and it’s what causes most of the difficulties developers complaint about. It’s not the technology itself, but rather our understanding of it. So here goes the tech crunch.

How does it work?

GameJacket serves as a wrapper for your game. What this means is that the file GameJacket distributes is not your game, but rather their loader that wraps your game. I don’t know why GameJacket decided to do it this way, but it addresses one of the major problems with other advertising networks: it is pointless to decompile the wrapper because the game itself won’t load without it.

The code that is delivered with the instructions has one and only one objective: to prevent the game from being ran without being called by the wrapper. This is a good thing: it assures you will get the play from wherever the game is. In case you are wondering, there are portals that will decompile your game, rip your logos and advertising code and post it as if it was a non-exclusive license. This prevents it.

So… what about the preloader?

You will have to write your preloader to all games that you want GameJacket to go with, but that shouldn’t be a big deal really, that’s something you should always consider anyway. To make it simple: write your preloader as if you were releasing the game without advertising; insert GameJacket’s classes and code as explained in the documentation; make the success event trigger your preloader graphics and finally make the failure event go to a nice message box that says where people can get a legitimate copy of your game.

The workflow of all this is?…

As I explained, the distribution file is not your game, but rather a wrapper. When it is loaded from a site it will show the ad and when the “Play” button is clicked, it will load your game. When your game is loaded, the code you inserted will confirm if the game was loaded from the wrapper or not. It will either launch a success event, launching your preloader, or a failure event, showing the message you want.

The good: Version control, more difficult to rip your game ads
The bad: Well, we are kind of used to have Mochis preloader

Hope this helps!

Advertisements

December 19, 2008 Posted by | Advertising Networks, Monetizing, Technical | , , , , , , | 2 Comments

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!

November 18, 2008 Posted by | Technical | , , , , , | 6 Comments