Emanuele Feronato

Talking about Actionscript 3, Flash, Game development, iOS and Users contributions.

There’s no doubt 2012 will be the year of the frameworks. Roger Engelbert in his blog rengelbert.com show us how to do a mobile Frogger game using four different frameworks: Starling, Sparrow, Cocos2D and LibGDX.

This is the game involved in the experiment:

Use arrow keys to move the frog, or click on the frog controller in the bottom right corner of the game.

Here is a brief intro by Roger:

I will first explain something of the logic controlling the game. It is very important to point out that the logic itself has nothing to do with any of the frameworks I’ll use. The frameworks for the most part only influence the VIEW part of the logic: the actual rendering of textures on screen in place of all the rectangle objects the logic handles.

So these tutorials are not meant to be on how to build a game like Frogger, but how to blitt stuff to the screen.

Having said that, I thought I might as well explain enough of the game logic so that you can separate that logic from the actual framework code.

The Game Engine

The engine manages a series of Screen objects, but displays only one screen at a time. So you can build an Intro Screen, a How to Play Screen, a High Scores Screen, a Game Screen… The Engine then updates the currently displayed Screen object within a loop.

For this example I created two screens, one called a MenuScreen that shows the instructions on how to play the game, and one screen called GameScreen where the actual game runs.

The main Game object contains exposed references to GameData, the TextureAtlas and Sounds. Every object in the game receives a reference to the Game object. I’ve decide to use composition and drop the Singletons.

Controls

For the Flash version of the game I will use two sets of controls: Key presses and Mouse clicks. Later when porting to mobile devices I will drop the Keyboard input logic and just keep the touch events.

The Game Logic

The game logic is very simple. The screen is divided into 13 rows, I called them Tiers. Each Tier has a bunch of sprites inside it, they can be cars, or turtles or tree logs.

The frog sprite, controlled by the player, can have only 13 possible values for its Y position, one value per Tier. So with every UP or DOWN movement the player Y value changes to either the next Tier or the previous one.

Collision is run only with the objects belonging to the Tier the frog is currently at.

Each Tier has the responsibility to update the positions of the sprites it contains.

The Skin Property

As I talked about earlier, the different frameworks used will be in charge of the SKIN property of the Sprites used in the game as well as the various Texture objects a skin may use (if it’s animated for instance.) It is here that the Framework logic and syntax can be found.

However when I update the position of sprites in the game I do this through the wrappers and not directly to the Image objects. This might seem like extra work for you, and you’re free to change this. I simply find this way to be the easiest when taking the same logic to different platforms as I only need to change the logic controlling rendering of the skins.

Now, you are ready to ready one of the most interesting tutorials I’ve ever seen.

http://www.rengelbert.com/tutorial.php?id=163 (using Starling)
http://www.rengelbert.com/tutorial.php?id=167 (using Sparrow)
http://www.rengelbert.com/tutorial.php?id=171 (using Cocos2D)
http://www.rengelbert.com/tutorial.php?id=175 (using LibGDX)

I am looking forward for playing and messing around with frameworks and publish my thoughts.