Lillypad: Framework and Sprites

Posted in: Articles, Lilly Pad by preitz on

At the beginning it’s going to seem like I’m jumping around a bit on this project. I figure the best way to do this is to get the pieces done to a point to build a specific game. That game, and others that follow, will push this project to being more complete. And more stable.


To start off with I needed to have a basic frame work in place. Most APIs I’ve worked with start with a basic “game” class, that the document class should extend. So this is what I did. There is also usually a class to represent “levels”. I went with the same idea, but had to think about what to call it. This may seem a bit frivolous, but I believe the importance of naming is usually understated. In other APIs I’ve worked with, I’ve seen this class called “window”, “scene”, “world”, “state”, etc. I went with “scene” because I think this most accurately represents the range of uses this class will have. It could be actual game play, a menu, instruction screen, inventory, etc. So “world” or “window” doesn’t really cover that range. “State” may have worked, but it seemed a bit too “proper” for this sort of project, plus I have plans to include a state machine that can be used to give developers more control over game flow inside a scene.

To start a game there are two functions you use from the game class: onReady(), and startGame(). Override onReady(), and use startGame() to pass in the initial scene:

public override function onReady():void
	startGame(new MyScene());

The onReady() function is called after all of the initial setup is complete. It also ensures that the game has already been added to the stage (if not the game class will wait to call onReady()).

I’ve also included a utilities class that has a number of interesting static properties, such as stage width and height, frame rate, center x and center y. And more will be added as I need them. This is just a nicety so that these values can be grabbed easily. And, seriously, I don’t know why other APIs don’t just provide a center x and center y.

In order to change from one scene to another, there’s a function called transitionScene(). This takes two parameters, the new scene and an optional transition (transitions will be done on Tuesday). If only a scene is provided then the old and new scenes are just swapped out. If a transition is provided, then the transition is played to bring the new scene in.


The sprite class takes two parameters in the constructor; a graphic class, and an optional JSON object. If only a graphic class is provided, then the graphic is displayed. If a JSON object is provided, then that is used to build the sprite frames from the graphic.

The JSON file used is the one exported from Texturepacker (using the ‘JSON (Hash)’ format):

Although I intend to support a full range of features from Texturepacker, currently “Allow Rotation” needs to be disabled. Texturepacker can reduce the image size further by rotating some of the frames, but I haven’t gotten support for this feature working yet.

To create an animation the following function would be used: createAnimations(name:String, frames:Array, frameRate:Number, loop:Boolean, restore:Boolean)

  • name: A string reference used to play (and stop) the animation.
  • frames: An array of strings for the frames of the animation
  • frameRate: Frame rate of the animation (can be different than the SWF frame rate)
  • loop: Whether to loop the animation, or just play it once.
  • restore: If set to true, when the animation is stopped the sprite will display the first frame of the animation, otherwise it’ll display what ever frame it was stopped on.

The working test for this can be found here (you may need to click on it before it’ll accept keyboard input). use WASD or arrow keys to play the walk animations.

There won’t be an update tomorrow, but I’ll be back on Tuesday to talk about transitions.


Next: Scene Transitions

  • by eduardo, on August 13, 2014 - 2:44 PM

    This comment is awaiting approval