GreenJay Blog

In my last post I showed off round one of the design for the game. While I am sure that the design will go through many rounds of changes before it is ready, now it a good time to explore a method for getting those graphics into the game engine. I am going to start with the static objects, as they are the simplest to implement. Because the static objects don’t move once they are placed I can simply place the graphic in the right place when creating the physics object.

Separating code from design

The library of objects

Because this is the first encounter with any type of graphics, I want to make sure I do it right. I want to create a clear line between the world of the flash designer and the world of the flash developer. Obviously using Flex would create this division for me, but within flash alone, I find it helpful to think of the Library as the designer’s territory. In this way, we can still keep the stage clean of anything (design or code).

I have created a library of 2 types of static block and 2 types of ramp. Each has a name beginning with an underscore which I do to distinguish export objects from the others. They have also been given export names which basically attaches a blank class to the movieclip. In this way, the objects can be instantiated with some pretty simple code.

1
2

var block1:Sprite = new BlockType1(); // Create a block as a Sprite
addChild(block1); //Add the block to the display list

Let’s make this a bit more object oriented

At the moment, all of our object creation is in the TileGame.as class. What would be better, instead of a messy block of code in the TileGame.as class every time an object needs to be created, would be a call to an external class. Ultimately, we want to be able to create our objects with pieces of code like this.

124
125
126
127
128
129
130
131

case "1": //When we want to create a block
    var block:Block = new Block(levelB, i, j, m_physScale, 1, STD_FRICTION, STD_RESTITUTION, this);
    m_sprite.addChild(block);						
break;
case "2": //When we want to create a ramp
    var rampa:Ramp = new Ramp(levelB, i, j, m_physScale, 1, STD_FRICTION, STD_RESTITUTION, this);
    m_sprite.addChild(rampa);					
break;

Isn’t that a lot simpler than the big block of code we had before. Basically, we are creating a new Block or Ramp object, and passing the necessary variables through the object instantiation. To better understand these variables, lets have a look inside the block class, which is defined in the seperate actionscript file Block.as.

12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

public class Block extends Sprite 
    {
        private var body:b2Body; //The body we want to attach the block to
        private var base:Object; //The base object or root of this object
        private var row:int; //The row this tile is to be placed at
        private var column:int; //The column this tile is to placed at
        private var m_physScale:int; //The physics scale of the world
        private var type:int; //The type of block. This is used for placing different graphics.
        private var bFriction:Number; //The friction of the block
        private var bRes:Number; //The bounce of the block
 
        public function Block(bd:b2Body, r:int, c:int, p:int, t:int, f:Number, res:Number, bs:Object)
        {   //Here we attribute the received values to our object
            body = bd;
            base = bs;
            row = r;
            column = c;
            m_physScale = p;
            bFriction = f;
            bRes = res;
            type = t;
            //Now we begin the function that builds the block
            addBlock();
        }

And now to have a quick look at the addBlock class. I won’t spend time commenting the Box2d code as we have examined this before. More important is the part of the code that deals with the graphics. In order to deal with multiple block with different graphics, a switch statement is used after the physics of the block has been created. This saves time creating different block classes when the only thing that changes is the graphics.

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71

public function addBlock():void 
{
    var wallFd:b2FixtureDef = new b2FixtureDef();
    var wallSd:b2PolygonShape= new b2PolygonShape();						
    var wallBd:b2BodyDef = new b2BodyDef();
    wallBd.position.Set(column/ m_physScale*30, row/ m_physScale*30);
    wallBd.type = b2Body.b2_staticBody;
    wallFd.friction = bFriction;
    wallFd.restitution = bRes;
    wallFd.shape = wallSd;
 
    //Create an object with the name of the object and a reference to the root
    var dataObj:Object = new Object();
    dataObj.name = "BLOCK";
    dataObj.base = base;
    //This object is stored in the Fixture Definition userData object
    wallFd.userData = dataObj;
 
    wallSd.SetAsBox(15 / m_physScale, 15 / m_physScale);	//Dimensions of the block					
    body = base.m_world.CreateBody(wallBd); //Add the body to the physics world
    body.CreateFixture(wallFd);
    var xyPos:b2Vec2 = body.GetPosition(); //Gets the postion of the physics object
    this.x = xyPos.x*30; //Converts the physics position into normal pixels so when...
    this.y = xyPos.y*30; //...we place our object it will already be in the right place.
    switch(type) //Remember that type was a value passed in at the start
    {
        case 1: //This value decided what graphics the block uses
            var block1:Sprite = new BlockType1(); //Instantiate a BlockType1 as a sprite
            addChild(block1); //Add the block to the Display List
        break;
 
        case 2: //This is a different style of block
            var block2:Sprite = new BlockType2();
            addChild(block2);
        break;
    }		
}

And that is all there is to it. When these objects are instantiated, they will have both physical and graphical presence. Obviously this won’t work with dynamic objects as we only set the position of the graphic one time at the object creation. I won’t bother explaining the Ramp.as file as it is the same idea as the Block class. The only difference is that because different ramps face different ways, I had to include the structural code in a switch statement. Feel free to check out the full source code or just a simple version for editing levels in XML.

The Result

Note: The Box2d decoding graphics are still present behind our new graphics. If these were turned off now, you wouldn’t be able to see the moving objects.

The challenges we face

For a while, I have wanted to have a reset button for this game. Often, I will get the player stuck in some position, or lose him all together off the map, and will have to restart the flash file to restart. What I realised, is that by building a reset button, I would also be creating the code I need to progress levels, and to send the player back to the start if he dies.

Because the game uses a combination of physics objects and normal movieclips, we need to be able to clear the entire level of both of these before we can rebuild another level over the top. Another important thing to remember, is that the game is constantly running cycles of the physics engine. You can’t remove objects mid cycle, so we will need to find the right place to stop and check if the reset button has been hit.

Let’s look at the code

First off, we setup reset and the current level as global variables in TileGame.as.

16
17
18
19

public class TileGame extends MovieClip
    {
        public var lvlCurrent:int = 1;
        public var reset:Boolean = false;

Then I added a new key to listen for in my key_pressed() event listener function

211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228

function key_pressed(event:KeyboardEvent):void {
    if (event.keyCode == 37) {
        rightKeyDown = true;
    }
    if (event.keyCode == 39) {
        leftKeyDown = true;
    }
    if (event.keyCode == 38) {
        upKeyDown = true;
    }			
    if (event.keyCode == 40) {
        downKeyDown = true;
    }	
    //The new reset key is a lowercase "r"
    if (event.keyCode == 82) {
        reset = true;
    }	
}

So now we have function that sets the reset variable to true every time the “r” key is pressed. But how do we translate that into actually resetting the level? As I said before, we need to make sure we do our resetting in the right place. We need to do it at the start of a physics cycle to make sure that no physics calculations are happening when we start destroying the level. So we check for a level reset at the start of the run() function which basically runs the entire engine.

324
325
326
327
328
329
330
331
332

private function run(e:Event):void
{
    if(reset)
    {
        destroyLvl();
    }
 
    // The rest of the function updates physics etc etc
}

Below is a detailed look at the destroyLvl() function. Before destroying any objects though, the game engine needs to be stopped. By removing the ENTER_FRAME event listener, the game no longer calls the run() function, and we can begin deleting the objects that make up the level. We do not need to restart this listener, as that is done at the end of the createLvl() function which we call at the end.

244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273

private function destroyLvl()
{
    //Temporarily stops the game running
    removeEventListener(Event.ENTER_FRAME, run); 
 
    //Put the value back to false for when the game starts again
    reset = false;
 
    //Gets a list of every physics object created
    var node:b2Body = m_world.GetBodyList();
 
    //Loops through each object and destroys it
    while (node)
    {
        var b:b2Body = node;
        node = node.GetNext();
        m_world.DestroyBody(b);
    }
 
    //Loops through every sprite in the level and destroys it
    while (m_sprite.numChildren)
    {
        m_sprite.removeChildAt(0);
    }
 
    //Recreate the level from scratch
    //Note: null needed because at the moment, createLvl is an 
    //event function but this will be fixed in later versions
    createLvl(null);
}

We can also use this destroyLvl() function to progress to the next level, all you need to do is increase the lvlCurrent variable before you change the reset variable to true. For an example, see below.

1
2

lvlCurrent++;
reset = true;

When our level gets created, we use the lvlCurrent variable to tell it which level to build from our Levels array.

81
82
83
84
85
86

private function createLvl(e:Event):void
    {
        //The -1 is needed as arrays always start at 0
        var lvlArray:Array = L.levels[lvlCurrent-1].data;
 
        //... createLvl function continues as normal

Next post we will look into object collision detection within the Box2d physics engine, and how it can be used to create game goals, enemies and other effects.

Source files

Here is the source code, and here is a simpler version where you can edit levels, but not the original source code.

The game engine (remember to double click inside the box to play)

Don’t forget to try the “r” key to reset the level

Hello again, I am back from my holiday and am now living near Milan Italy. The last post I made showed a lot of improvements to the game engine, but I did not have time to describe the additions in detail. Today I will be describing in more detail the new camera movement being used in the game Please refer to the last post for game source files.

The reason I had to write a smarter camera into the code is because the old camera would follow the player no matter where it went. If the player is near the edge of the screen, or the whole level fits within the screen, we don’t want the camera to follow. When the camera should and shouldn’t follow can be a little confusing to put into code, so lets look at it in a diagram first.

Camera Movement Diagram

The rules of camera movement

In this diagram, X equals the screen or stage width, and Y is the height. When the player’s X position is more than half of the stage width, the camera begins to follow. If however, the player becomes close to the other side of the level (when the player’s X position is greater than the level width minus half the stage width) the camera ceases to follow again.

Visually, when the player’s position is in the lightest grey areas, the camera doesn’t follow at all. When the player is in the medium grey areas, the camera follows the X or Y movement of the player, and when the player is in the darkest grey area, the camera follows both the X and Y movement of the player. Whew! I knew it would be difficult to explain in words. Let’s have a look at it in the code.

The following extract of code is found in the TileGame.as file at line 269 of last weeks source code files.

Camera Movement Code

269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319

//Please note: m_sprite is basically a container for the whole level
//and WORLD_OFFSET is a constant used to adjust the level positioning.
 
private function moveWorld()
{
	var vect:b2Vec2 = player.GetPosition(); //Sprite position in Vect format
 
        //This statement deals with the player X position
	if(m_sprite.width>stage.stageWidth)
	{
                //If X position is away from the edges of the level
		if(vect.x*30 < (m_sprite.width - stage.stageWidth/2) && vect.x*30 > stage.stageWidth/2)
		{
                        //Notice there is no camera to move but the
                        //sprite containing the level which moves
			m_sprite.x = -(vect.x*30)+(stage.stageWidth/2);
		}
                //If the X position goes near the right edge
		else if(vect.x*30 >= (m_sprite.width - stage.stageWidth/2))
		{
                        //Set the camera to hold on the right edge
			m_sprite.x = -(m_sprite.width - stage.stageWidth);
		}
                //If the X position is close to the left edge
		else
		{
                        //Set the camera to hold on the left edge
			m_sprite.x = 0;
		}
                //An offset constant is added to place the camera exactly
		m_sprite.x = m_sprite.x+WORLD_OFFSET;
	}
 
        //We repeat the process with the Y position
	if(m_sprite.height>stage.stageHeight)
	{
		if(vect.y*30 < (m_sprite.height - stage.stageHeight/2) && vect.y*30 > stage.stageHeight/2)
		{
			m_sprite.y = -(vect.y*30)+(stage.stageHeight/2);
		}
		else if(vect.y*30 >= (m_sprite.height - stage.stageHeight/2))
		{
			m_sprite.y = -(m_sprite.height - stage.stageHeight);
		}
		else
		{
			m_sprite.y = 0;
		}
		m_sprite.y = m_sprite.y+WORLD_OFFSET;
	}
}

As you can see in the flash example from last week, we now have a camera that moves with the player, but will not pan so far as to expose the world beyond the edge of the level. See you soon for more details on game goals and creating multiple levels.