I was up late last night finishing my latest tutorial, so I was a little late to the game hearing the announcement that Alaska Governor Sarah Palin will be the vice presidential candidate on the ticket with John McCain. This certainly is not a political blog, and since both Steve and I are pretty "middle of the road" when it comes to politics (I especially think anyone who goes strictly down a party line, no matter the party, is a little suspect), I will not publicly endorse any candidate. Anyway I haven't even heard anything good from any candidate on some subjects that concern me :Net Neutrality, DRM, etc. Since we are retro here, and one of my favorite all time movies, Election is pretty retro nowadays I decided to post something that struck me as I watched video of her introduction. In the film, a young Reese Witherspoon perfectly portrays a high school over achiever, student council candidate. I wanted to point out that Sarah Palin speaks, acts and looks a lot like Witherspoon's character, Tracy Flick. Especially in the way she talks and pauses and doesn't move her lower lip as much as you'd expect when she wants to make a point clear. They don't have the same color hair, and the facial features are different, but their mannerism and overall persona remind me of one another. You have to watch video of both of them to fully appreciate it. By the way, I am fully aware that people also compared Hillary Clinton to Tracy Flick. No comment.

I am a media junky and have stations tuned to both conservative talk radio, Air America, John Stewart, Stephen Colbert, and others. I don't take it as seriously as that might sound, but I like to know a lot about a subject and try to find funny things about it if possible. By the way, I like all 4 of the people on the presidential tickets, even if I don't agree with a some of what they might stand for. They all bring something unique to the table, have interesting background stories, and are mavericks in their own unique ways. If you are in the USA and of age, please pick a candidate and vote. I don't care which one, but please exercise your right to do it. This is going to be a very interesting election.

Some Flash / Retro Stuff so this blog entry seems relevant:
Squize has some new good stuff up on his blog. His latest is on unique collision detection schemes and it has created a good discussion.

The 8bit City Blog has an interesting entry on a game that was never released in the USA, Battle Loderunner. This might make a cool Flash game.

I just bought Mario Cart for the Wii with a second steering wheel controller. I have been trying to find a game for my 3 year old son to play (besides hitting buttons and getting tickets for toys at Chucky Cheese). This game is finally it! He can use the steering wheel and press the 1 and 2 buttons to accelerate and brake. It has been a blast having a second player around the house the last couple days. My wife has even been playing it!

In this tutorial will will explore basic blitting from a tile sheet to a single blit canvas. We will do so by implementing a common animation problem - rotation. We will also demonstrate the simple math tricks that are used to find the starting point to copy from the tile sheet given the tile number and width and height of the sprite to be copied.

As part of my 24 hour game challenge, I am creating a game similar to Atari 2600 Air-Sea Battle mixed with the game Point Blank.
This has opened up an opportunity for me to deliver a tutorial based on one of the game display concepts that I need to achieve: Blitting an object around a center point in space. I want to tackle radial rotation around a center point, and we will get there in part 2. We must first take a look at simple rotation using a sprite sheet before we get to that slightly more advanced topic. As you will see, they are very much related.

First, here is the tile sheet we will be using. The enemy in this case is a helicopter that is a simplified version of one that I will be using for my game. In this version, the helicopter has one frame of animation and 36 different angles it can be positioned in. We will do this in both the clockwise and counter clockwise directions. This gives us 72 different frames of animation that must be pre-rendered. There certainly are other ways to do the same thing, but they are more advanced. In this instance we will use the basic sprite sheet method of blitting from png sheet to the screen canvas. Whatever angle the helicopter is rotated in will be the angle that it is traveling and it will do its traveling around a center point on the screen. I would usually have more than one frame for the helicopter (maybe have the rotor look like it's spinning for example). I have left out the second frame of animation for this basic tutorial so what we have below are the 36 frames needed to render the helicopter at angles 0-359 with 10 degrees in between each step. I have split the clockwise and counter clockwise rotations into two separate sheets. I have done this purely out of convenience. This certainly could have been on one sprite sheet, but splitting it into two makes finding the right sprite to use easier.

Here is the clockwise sheet:

Here is the counter clockwise sheet:

These were both created in Fireworks. I started by pixel drawing the first frame (actually with a cool green pallet, but it didn't work well on a black background). I then copied it to the subsequent tiles and rotated it 10 degrees each time. One note on rotating a bitmap, always make sure you use the original tile for each new rotated tile. For example, I rotated the first tile by 10 degrees to make the second tile. I did NOT rotate the second tile by 10 degrees to make the third, but rotated the first by 20 degrees. Unlike rotating vectors in Flash, bitmaps degenerate into what can only be described as PIXEL MUSH on each rotation because of deformations. If you look closely even at the single deformations I have created, all but the direct right angles look a tab bit strange close up.

Also, I have chosen a pretty ugly pink sprite because it will contrast well with the black background we are going to use in our demo. My pretty green sprites were hard to pick out from the background because I used a green that was too dark in places.

The basics of circular motion
We have covered the basics of blitting and blitting with transparency before, so if you want to look up the details, feel free. We will cover them in summary a little later. The first example we will run through is how to do a simple blit of our sprite sheet corresponding to the angle we want to rotate our sprite. It will end up looking like the helicopter is simply rotating in place, This is really easy if we are using display objects, we just need to set the rotation property with a value of -180 through 180. But with blitting, we need to use a different approach. That is why I spent the time creating the rudimentary sprite sheets above. We can simulate rotation simply by running through the sprites in order like a flip book animation. That is exactly what we have done before in the earlier blitting lessons. In this case, we will take it a step further and force our blitted sprite to appear to point in the direction of a calculated angle.

In the clockwise sprite sheet above, the first sprite cell is a helicopter pointed to the right. That sprite will correspond to the angle 0. The last sprite in the sheet (#35, 0 relative) corresponds to angle 350 (360 is the same as 0). If we know our angle, we can display the right sprite cell to correspond to the direction we want to helicopter to face.

To rotate an object using math, rather than the built in functions for display objects, we need to first choose a center point for our object. In this case I have chosen 50x and 50y as the center point. We then choose a radius from that center point (the distance from the center) that we want out object to be placed. If we choose a radius of 0, then our object will appear to rotate in place like an Asteroids ship. If we choose a radius other than 0, our object will appear to rotate AROUND the center point at the radius distance.

Some Math that you won't need for this example, but will prepare you for part 2So, for our first example, we will have the object appear to rotate in place. To find the x and y values for the location of our object in space, we use the cosine and sine of our angle (cos for x, sin for y) and multiply by the radius. We add this to our start position 50x and 50y to get the location in space for our object.

Because we are going to be rotating the object in place, our radius is 0. This calculation is completely unneeded for a radius of 0 because it will always return 0 to be added to both the x and y value, leaving your object exactly where it is, but rotating it on the center point. Here is the calculation anyway:

x=centerX+Math.cos(angle) * radius; or x=50+Math.cos(0)*0; or in other words, 50;
y=centerY+Math.sin(angle) * radius; or y=50+Math.sin(0)*0; or in other words 50;

For this lesson the math is not as important because we are simply rotating on a center point. In lesson 2 we will complicate this more by actually using a radius to give the illusion of radial circular motion.

That is where we will start our first example we will leave out this calculation because we just want to blit the object around a center point.

Here is what we are going to try and accomplish:

Obviously there is nothing earth shattering about simply rotating an object in Flash. Our version uses a high-speed blitting technique rather than the standard display object rotation. I only have 36 frames of animation, so the spinning helicopter looks a little choppy. Plus, I may have been off a pixel or two from my center point on a couple frames, but you get the general idea of when we are doing this.

This does seem like a lot of code to simply rotate an object, but there is a lot going on here that can be useful for more complicated projects.

Let's go through some of this code in detail code to ensure you understand the basics of blitting from a tile sheet as well as the basic math involved. We have added a concept to our blitting in this example. We now have 36 sprite sheet tiles to use and that will necessitate some simple sprite sheet math needed to find the location of the sprite to blit onto the canvas.

The Sprite Sheet
The sprite sheet is embedded in our .fla library with a class name of "heli_sheet". It is a 360x144 tile sheet with the 36 frames of animation needed just for the clockwise motion of the helicopter.

We bring it into use like this: [cc lang="javascript" width="550"]tileSheet=new heli_sheet(360,144);[/cc]
The basics of tile sheet blitting can be found in this tutorial.

The CanvasWe will be using a single canvas as our drawing surface for all objects (in this case we have just one object); We need a 400x400 blank canvasBD BitmapData object and we need a way to display it on the screen, so we also have a canvasBitmap display object that is added to our displayList

The Helicopter
If this was a more elaborate game, we would have some sort of helicopter object to hold all of the properties and many of the methods used for it. In this simple case, we just have a few global variables that are used for that purpose:
[cc lang="javascript" width="550"]
heliRect=new Rectangle(0,0,36,36);
heliX=50;
heliY=50;
heliPoint = new Point(heliX, heliY);
[/cc]

The heliX and heliY do nothing more than give us a location for the the top left corner of our helicopter object. This is also the center point of any radial circular rotation we might want to display. Since this first example if just rotating an object in place, we don't need any other calculations to find the x and y values for the helicopter. They will be heliX and heliY (50,50) nd will not change.

The heliRect variable is used for our blitting of the helicopter to the canvasBD. It defines a rectangle of that starts at 0,0 and goes to 36x and 36y. It tells the blitting method how much of the sprite sheet to put on the canvasBD.

The heliPoint is always the current x and y value where we want the sprite to be blit onto the screen. In this case is will remain 50,50 the entire time.

The Background
The background we are using is a simple black 400x400 square. We don't need to do anything difficult to create this other than specify it when we create out background BitmapData object:
[cc lang="javascript" width="550"]
backgroundBD=new BitmapData(400,400,false,0x000000);
backgroundRect=new Rectangle(0,0,400,400);
backgroundPoint = new Point(0, 0);[/cc]

The backgroundPoint and the backgroundRect are used when blitting them to the canvas. The point will always be 0,0 (the top left of the screen) and the rect will always be a 400x400 rectangle covering the entire background.

Using blitting from a tile sheet with multiple rows and columnsIn the previous blitting tutorials we have covered how to blit a finite row of tiles in a loop to create a simulated animation. In this example we will take it a bit further and show how to blit from all 4 rows to the canvas, not just from one row. The size of each tile we are going to use is 36x36 and we have 36 tiles. There is no extra significance for the use of the number 36 and it is just a coincidence that I used that number for the tile width and height as well as the number of angles for a rotation.When we have more than one row of tiles to blit from (there are three full rows of 10 and one row of 6 sprite tiles) we can use a simple math trick to tell the program where to start cutting from the tile sheet to paste onto the canvas.
[cc lang="javascript" width="550"]
heliRect.x = int((animationIndex % spritesPerRow))*tileWidth;
heliRect.y = int((animationIndex / spritesPerRow))*tileHeight;
canvasBD.copyPixels(tileSheet,heliRect, heliPoint);
[/cc]

The heliRect.x and heliRect.y values need to be updated each time a new frame of animation is to be shown. Note: In the above example I do it on EVERY frame, but this can be optimized further to have it only calculated when a new frame is to be shown.

What we need to know here first is the current frame of animation we want to display. That is represented by animationIndex and is a number from 0-35. We also need to know the maximum number of tiles per row in our spriteSheet. That is represented by the spritesPerRow variable. Since animationIndex starts ar 0, the first sprite tile to blit is 0:

To find the starting x value on the spriteSheet to copy from, we use this simple formula:
x=int(animationIndex % spritesPerRow)*tileWidth;
For tile 0 on our sheet, the calculation would look like this:
x=int(0 % 10)*36.
0/10 = 0 with 0 remainder, so 0 % 10 =0; 0*36=0; Our start x location is 0;

To find the starting y value on the spriteSheet to copy from, we use this simple formula:
y=(animationIndex / spritesPerRow) * tileHeight
For tile 0 on our sheet, the calculation would look like this:
y=int(0/10)*36.
0/10 =0, so 0*36=0; the start y location=0;

This seems pretty simple for the first spriteSheet tile, so now we'll test it out on the 15th tile (the 15th tile would be the 16th on our sheet because we start at 0).

For tile 15, the x calculation would be:
x=int(15%10) * 36.
15 % 10 =5 (5 is the remainder from the division of 15 by 10);
5*36=180;
Our x start location is 180;

Slowing down our animation
One last thing we do in this simple second part to our blitting tutorials is create a delay between the display of animation frames for our rotation. We do this so the helicopter does not spin too fast on the screen.
[cc lang="javascript" width="550"]
if (animationCount == animationDelay) {
animationIndex++;
animationCount = 0;
if (animationIndex == heliTilesLength){
animationIndex = 0;
}
}else{
animationCount++;
}
[/cc]

Basically this counts 3 frames and then increases the animationIndex by 1.
When the animationIndex is greater than 35 it sets id back to 0;

Where is the rotation code?
Good question. As you can see by analyzing the above code, we didn't use any of this formula:
x=centerX+Math.cos(angle) * radius; or x=50+Math.cos(0)*0; or in other words, 50;
y=centerY+Math.sin(angle) * radius; or y=50+Math.sin(0)*0; or in other words 50;

The reason for this is simple. The outcome of each of those formulas is still just the current center point. Also, since we are using the animationIndex value to loop through our spriteSheet, we just need to multiply it by 10 to get the current angle that the heliCopter is facing. We did not need that information in this first part, so I left it out. It will be needed when we rotation with a radius around a center point and especially when we turn the helicopter to face the direction of this radial motion.

My buddy, Chris Cutler, sent me a link to this site today (www.soundsnap.com) and I have been exploring it on an off in the limited free time I have had tonight. There are literally 1000's of great sounds and music free for you to use in your games.

The latest in Blog entries and articles that might interest Flash game developers. It's time to hit my favorite Flash sites and see what's new in game development.

This time we cover The difference between "distance between points" methods in AS3; MAME Goes the way of Flash; 50 ways to improve your web site; the latest Mochi winner; Tutorials on Photoshop and Adobe Air; How to design game that won't numb the player; 4 cool Mochi games and lots lots more.

Mochiland has announced the latest Flash Friday Winner, Addup by Deadwhale.com. Addup is a match 2 style game where the sum of the numbers you select much "add-up" to the a certain number. It's a fun little diversion and a unique match style game.

As has been the case for a long time, Game Poetry has another wonderful article, this time on game design. It deals with giving the player breaks in game play and is called Numbing the Player. Also, the tool SFXR (something we have highlighted 2x before also) is discussed in Sound Effects on a Budget. It is a great 8-bit sound generator.

Today I noticed that it has been picked-up by Kotaku. They had something very nice and insightful to say about the article:

"It's stuffed with quotes, so the length isn't simply 'and then ... and then ... and then ....'". I know that doesn't sound like much, but it just so happens to be the one major thing i was trying to do with the article. I did not want a long diatribe of my own personal prose vomited on the page with no outside perspective. I'm so very happy they like the approach.

The second part of my "History Of Atari" launched today on Gamasutra. "Atari: The Golden Years A History, 1978-1981" is long, and self-indulges a lot with the history of the Atari computer line (because the story has told in many places before). If have a bit of time, please go by and read it.

Along with many other little projects, I have begun research into creating a AS3 Quad Tree implementation to extend the optimized code in my series on creating an optimized Asteroids Game. A couple other blogs have also started their own implementations, including Fatal Exception and Polygonal Labs. Neither have any code to look at yet, but they both have nice examples to view and are far ahead of where I am right now. Although it is not directly related to quad trees, I also found a very interesting discussion on Grid Based Collision detection at the N site. I am far behind the curve on advance math based collision routines, so it has taken me a while just to get this far.

Formal Research
I have a huge library of game programming an design books across multiple different languages and disciplines. I first checked out a great volume called Data Structures and Algorithms for Game Developers. This book has a section on trees, especially BSP and Quad trees. A BSP or Binary Space Partitioning Tree is used mostly for 3d development. Basically is creates a hierarchy of objects from front to back based in the z-order (I'm simplifying here). This type of tree splits the virtual space into planes and creates the hierarchical tree based on which side of a dissection plane and object resides. Maybe we'll explore this one in detail some day, but we are interested in seeing how another type, the Quad tree can help us with our collision detection. A quad is mostly used for 2d games. The tree would first split our play screen into 4 distinct quadrants (0-3). So if we have a 400 x 400 game play area, we would end up with a set of quads that look like this:

These four boxes are child nodes of the screen. A object would be in node 0,1,2, or 3. Node 0 contains the red helicopter and node 3 contains the skull and cross-bones. Inside of each node, a recursive quad split would occur when a condition is met. That condition could be something like is 4 objects exist in a quad, and would spit that quad further. For example:

In the above example, quad 0 has 5 objects in it, so we have split it into 4 more quads (numbered 0.0 - 0.3). Quad 0.1 contains two objects, both a helicopter and a skull and cross-bones. This is useful because on the frame there this occurred, instead of matching all helicopters in a loop against all skulls, we would only need to check if the two objects in quad 0.1 were colliding. If implemented properly, this would greatly lower the process time needed for collision detection. Since I am using BitmapData collision detection, this would help immensely with optimization for my game.

One more note on this type of structure: The above is an over simplification of how a game's quads would look in a real game. In reality, objects would be in more than one quad frequently:

In the above example, a skull is in both 0.1 and 0.3 at the same time. If we just used the upper right-hand corner x,y values for positioning, then we would only be adding this to the object list of quad 0.1. That would make us miss the actual collision that occurs in quad 0.3 between the skull and the helicopter. I'm not quite sure how the experts would handle this, but I would take the bounding box of the skull and use that to decide what quads it reside in, then add it to the list of objects to be tested in each of those quads.

Of course, I might be wrong here because after reading through a chapter in Game Programming Gems (the first volume) I find that the prevailing opinion is that two objects MUST be COMPOLTETELY in the same quad to be tested against one another. Hmm, that doesn't see to work very well, but of course I have not tried it in code yet. If that is the case, then let's first attempt to split quad 0.1 and 0.3 into more quads and see what we come up with:

Hmm, that just leaves more questions, Now that 0.1 and 0.3 have been split again into 4 more nodes each, we get even more problems. Every object in those nodes now crosses at least 2 sub nodes. What a nightmare. I think I will go back and suggest that when I attempt to actually code this up I will allow an object to exist in more than one node based on all the nodes it's bounding box touches. I'm not sure how this will affect performance, but I will give it a shot. Reading further in the Game Programming Gems chapter I find that the author (Thatcher Ulrich) agrees that in some cases this is allowable. He doesn't go into how to detect what objects a node is in, but I will have to experiment with that anyway. He solves this problem with what he calls LOOSE trees. He allows the quad (in his case octree) boundary to be loose and expand when needed. This is an interesting concept that I don't completely understand at this time.

My next Tutorial:Maybe I am making this more complicated than necessary. Next time I will attempt an actual implementation. BUT not in my next tutorial as I have a new addition to the basic blitting tutorials I have been working on coming up next. In this one I will create a tile sheet of 36 rotations for an object and then use those to blit an object to the screen that is rotating around a point. We will blit the correct sprite from the sheet so the object is always facing in the direction that it is rotating. It would look something like this:

The latest in Blog entries and articles that might interest Flash game developers.

This time we cover FlashGameLicense.com; How people are cheating and hacking Flash games; How to Pause and Resume a sound in AS3; How to implement A* in AS3; 6 new action games on Kongregate, and more.

Mr Sun has a great little article on why he loves Flashgamelicense.com so much (and things he would like to change). We at 8bitrocket wholeheartedly agree! As Mr Sun states, the 10% fee paid back to FlashGameLicense.com is NOT mandatory, but we encourage that all developers pay it. Services such as FGL need to make a profit to keep going. Along with Mochi and GameJacket, FGL has been a sincere friend to independent developers and deserves at least this commission.

I'm really not quite sure what point there is in CHEATING AT FLASH GAMES, but if you are interested in finding ways that your players might try to do so, check out the Cheat Engine. I would have loved to have this on the Atari ST when I actually had to pay for games and wanted to extend their life after I was done with them, but for free games? The kids these days...

Gary Rosenzweig has a new tutorial (video) that shows how to pause and resume a sound in AS3. Gary is a true professional and I own both of his great books. His first book gave me the basic understanding to create Retro Blaster. I see a lot of copies of his games out on the sites. Some of them are hardly different than the examples in his book! Shame, shame!

FreelanceFlashGames.com gives us some good advice on How To Email A Sponsor. One comment says that FGL is making this direct contact redundant, but I don't agree completely. FGL is AWESOME, but making your own relationships with sponsors can get you better payments and custom work.