Tutorial: Using Flash CS3 and Actionscript 3 to create Atari 7800 Asteroids Part 4

Tutorial: Using Flash CS3 and Actionscript 3 to create Atari 7800 Asteroids Part 4

In this 4th and final part we will cover 2 main topics. First, we will use pixel perfect BitmapData collision detection to detect missile and ship collisions with the rocks. And second, we will create a very simple particle engine and use a pre-created farm/pool of particles to draw from. This will allow us to have some nice particle effects but also keep optimization in mind.

In Part 3 we covered firing missiles from the player ship. We used a png sprite sheet for the missile animation and demonstrated how to blit the missiles to the BitmapData canvas.

In Part 2 we covered adding the asteroids to the screen. The asteroid animation was cached into an array in a different manner then the ship rotation. With the asteroids, we took the frames of a timeline animation and drew each one into a BitmapData image that was placed into an array.

In Part 1 we covered creating an array of pre-calculated vector values for animating our player ship. We also covered caching the rotated frames of the ship in an array of BitmapData objects. We also added the ship to the screen and move it with the keyboard.

First, here is the the final game we will create. It isn't fully fleshed out game-wise, but it contains all of the basic elements necessary for you to apply to your own games. There is only 1 level, and the ship will not die. It will collide with rocks and provide a particle explosion though. In the upper part of the screen you will see Active Graph showing the game's current memory usage. When you click to start a new game, I don't explicitly null out all of the created objects, so you will see a slight increase in memory use on 2nd and subsequent plays. If this were a real game, I would set every object to null and call dispose() on all BitmapData objects. You will also see a frameRate counter next to the Active Graph. It is included in the zip file below.

Arrow keys rotate left and right and the up thrusts forward. The [z] key fires. The the window is embeded with a wmode=window. It will work at about 5 more FPS if I could use use the transparent or opaque settings. I don't because some browsers will not work with with it yet.. The below example starts with 20 rocks and each use up 40 particles for each explosion. Even using the BitmapData collision detection (which uses more resources than math-based) we can still keep a pretty constant 30 FPS frame rate. The .fla and all class files are provide so you can play with it and change things around if you like.

The source files are here: 7800 Asteroids Tutorial Part 4 source files

In the first 3 parts of this tutorial I have exhaustively gone through all of the code for each section of the game. I am not going to do that in part 4. My reasoning is simple. I don't think the tutorials layout has been as effective as they can be up to this point. The code box has been easy to read, but the explanations have not. I am currently fiddling with the layout and content of this an future tutorials, so I will do this one a little different. I will explain in detail as much as I feel is sufficient, but I will focus on a little more of the details behind these two theories. I definitely will show the code here, but you will need to unzip the files and play with them to see absolutely everything in action. I have added in some optimizations in this version that I will also explain at the end.

BitmapData pixel perfect collision detection
The theory about collision detection up to this point (especially in Flash) has been that math based detection is the best manner in which to detect. I agree with this, but I have seen some pretty un optimized math based collisions in my time. This is especially true if you are going to use the new Point() class and check the radius of each object against the other objects to see if they overlap. While this is an excellent way to do collisions, most new AS3 programmers make the mistake of in-line creating new Point objects on every frame tick. This wastes a lot of execution time because Object creation is very time consuming in Actionscript. Now, I'm not saying that checking each non-transparent pixel on a BitmapData object is faster, but as you will see it works fine and maintains a decent frame rate. So, since I wanted to try and make a game with pixel perfect collision detection I went ahead with this later route. What I am saying here really is no matter what type of collision detection you choose, if you write un-optimized code, it can perform worse than you might have imagined.

BitmapData objects are basically a collection of colored and transparent pixels. When two BitmapData objects overlap, if any non-transparent pixels are in the overlapped portion, a hit will be detected. This is very different from the standard Bounding Box to Bounding Box and Bounding Box to single screen point that is available with standard display objects. Now, you can also test pixel perfect collisions between a BitmapData object and a Sprite or MovieClip, but we will keep it simple as check to BitmapData objects against one another.

References: A Paradox with BitmapData.hitTest?
Keep in mid that when you create a BitmapData object from another BitmapData object through the assignment operation (=), you have just created a reference to the original BitmapData object. You don't physically have two different pieces of BitmapData, but two references to the same object. This is important because our game is made up of a lot of objects that all share the same array of BitmapData objects for display. If we were to modify one of the frames of animation for an asteroid on the fly somehow (by setting a pixel color for instance), all of the asteroids would get the change because they all share the same original BitmapData objects for each animation frame. Since all of the asteroids share the same array of BitmapData objects, detecting collisions between objects based on the BitmapData of each object would seem impossible, but it isn't. You see, if you remember from earlier parts of this tutorial, on each frame tick, an object might animate by changing to the next frame of BitmapData in the shared array of a animation frames. Each asteroid holds just a index int that represents the location in the array of asteroid frames to copyPixels from for display to the canvas. There is no way we can use the same index and reference for collision detection. So, we simply need to make sure that each asteroid also contains another variable called bitmapData. This variable will hold a reference to the current BitmapData object that is displayed by the asteroid object. It doesn't sound logical, but it works. If you have any experience with the BitmapData object, you might think that you need to use the clone() method to create a new object for the hitTest, but you do not. I was surprised by this myself, and will keep exploring how this might be beneficial in the future.

This new checkCollisions() method is below. I will not be discussing each line of the code but the most significant functionality will be discussed in detail.

[cc lang="javascript" width="550"]
private function checkCollisions():void {
missileLen=aMissile.length-1;
rockLen=aRock.length-1;

rocks: for (rockCtr=rockLen;rockCtr>=0;rockCtr--) {
tempRock=aRock[rockCtr];
rockPoint.x=tempRock.x;
rockPoint.y=tempRock.y;
missiles: for (missileCtr=missileLen;missileCtr>=0;missileCtr--) {
tempMissile=aMissile[missileCtr];
missilePoint.x=tempMissile.x;
missilePoint.y=tempMissile.y;
//trace("1");
try{
if (tempMissile.bitmapData.hitTest(missilePoint,255,tempRock.bitmapData,rockPoint,255)) {
// trace("hit!");
createExplode(tempRock.x+18,tempRock.y+18);
tempMissile=null;
tempRock=null;
aMissile.splice(missileCtr,1);
aRock.splice(rockCtr,1);
break rocks;
break missiles;

}
}catch(e:Error) {
trace("error in missle test");
}
}

//trace("2");
playerPoint.x=playerObject.x;
playerPoint.y=playerObject.y;
try{
if (tempRock.bitmapData.hitTest(rockPoint,255,playerObject.bitmapData,playerPoint,255)){
//trace("ship hit");
createExplode(tempRock.x+18,tempRock.y+18);
tempRock=null;
aRock.splice(rockCtr,1);
}
}catch(e:Error) {
trace("error in ship test");
}
}

//trace("3");
}
[/cc]

Labels
We need to loop through all of the rocks and all of the missiles to see if they hit another. We don't care if the missiles hit other missiles, and we don't care if rocks hit other rocks, but we do care of rocks hit the playerShip. For that reason, we loop through the rocks in our outer loop and the missiles in our inner loop. If we looped through the missiles as our outer loop, then for each missile we would need to check each rock AND also check the ship against each rock. That would be a waste of time, so we loop through each rock in the outer loop - first looking to see if a rock has hit a missile, and if it does NOT, then check the rock against the ship. We do this be setting up two labels called:

rocks:
missiles:

You can use labels in nested loops to help discern the loop you want to break out of. We do that here when a rock and a missile collide. The break rocks; and break missiles; lines tell the run-time to stop looking at this rock and this missile and start with the next in each loop.

Looping Backward
Why the heck does Jeff loop backward through his arrays? Is he one of the THOSE people who can use ++i and i++ correctly? Sadly, I cannot, but that is beside the point. We loop backward through the rocks and the missiles because we need to splice them out of their respective arrays when a collision is detected. If we looped forward through the array, and we had to splice say the 10th element in the missile array, something unexpected would happen. We would actually SKIP checking the 11th element in our array. That is because if the missileCtr is on 10 and we splice the element at index 10 in our array, right away, the 11th element shifts into the 10th spot (and all other elements after 11 shift one spot also). The missileCtr would then increase from 10 to 11, and the former element at position 11 (now at 10) is never checked. By looping backward through the array, when we splice, we don't cause this same problem. If we splice the 10th element in the array, 11 certainly moves in to fill its place, but the next one we check is the element in position 9 (we are looping backward), so we never skip an element.

The BitmpData.hittest method.
[cc lang="javascript" width="550"]if (tempMissile.bitmapData.hitTest(missilePoint,255,tempRock.bitmapData,rockPoint,255))
[/cc]
The hitTest() method of the BitmapData object is a powerful one. When called on a BitmpData object, it looks at all of the pixels on the object to see if they are overlapping with pixels on the other object. If those pixels are not transparent (or don't fall over the opacity threshold value) and hit is detected. As an optimization, I created generic point objects called rockPoint and missilePoint as global class variables. By doing so, I use a little extra memory up front, but don't have to instantiate the point objects on each hitTest. The missilePoint and rockPoint must be the upper left-hand corner of each object on the scene in global coordinates. The 255 basically tells the hitTest that NO alpha areas are to be considered opaque for the rock. Setting this number lower we change areas with alpha values above it to be considered opaque for this test.

The tempMissle.bitmapData and tempRock.bitmpaData hold the current objects referenced to the bitmapData needed for the hitTest. It is essential that this be changed each time the BitmapData of the object changes.

For example, in the code below, I have modified the previous drawMissiles methods from Part 3 to include one more line at the bottom. (see the //added in part 4 section).

[cc lang="javascript" width="550"]
private function drawMissiles():void {
missileLen=aMissile.length-1;

for each (tempMissile in aMissile) {

//trace("tempRock.animationIndex=" + tempRock.animationIndex);
//trace("aAsteroidAnimation[tempRock.animationIndex]=" + aAsteroidAnimation[tempRock.animationIndex].width);
missilePoint.x=tempMissile.x;
missilePoint.y=tempMissile.y;

canvasBD.copyPixels(aMissileAnimation[tempMissile.animationIndex],missileRect, missilePoint);

tempMissile.animationIndex++;
if (tempMissile.animationIndex > missileArrayLength-1) {
tempMissile.animationIndex = 0;
}
//added in part 4
tempMissile.bitmapData=aMissileAnimation[tempMissile.animationIndex];

}

}[/cc]

//added in part 4

tempMissile.bitmapData=aMissileAnimation[tempMissile.animationIndex

As we update the missile on the screen we also change the piece of BitmapData that used to display it on the screen. (it animates from red to yellow). When this change is made, we store a reference to the new BitmapData object representing the animation in our tempMissile.bitmapData variable.

We have added similar lines to the the drawRocks() method (see the bottom).

[cc lang="javascript" width="550"]
private function drawRocks() {
rockLen=aRock.length-1;

for each (tempRock in aRock) {

//trace("tempRock.animationIndex=" + tempRock.animationIndex);
//trace("aAsteroidAnimation[tempRock.animationIndex]=" + aAsteroidAnimation[tempRock.animationIndex].width);
rockPoint.x=tempRock.x;
rockPoint.y=tempRock.y;

canvasBD.copyPixels(aAsteroidAnimation[tempRock.animationIndex],rockRect, rockPoint);

tempRock.frameCount++;
if (tempRock.frameCount > tempRock.frameDelay){

tempRock.animationIndex++;
if (tempRock.animationIndex > asteroidFrames-1) {
tempRock.animationIndex = 0;
}
tempRock.frameCount=0;
//added in part 4
tempRock.bitmapData=aAsteroidAnimation[tempRock.animationIndex];
}
}

}
[/cc]

For the playerObject. we needed to add the code only when the frame of animation changed by turning the ship:

[cc lang="javascript" width="550"]
private function checkKeys():void {
if (aKeyPress[38]){
//trace("up pressed");
playerObject.dx=aRotation[playerObject.arrayIndex].dx;
playerObject.dy=aRotation[playerObject.arrayIndex].dy;

var mxn:Number=playerObject.movex+playerObject.acceleration*(playerObject.dx);
var myn:Number=playerObject.movey+playerObject.acceleration*(playerObject.dy);

var currentSpeed:Number = Math.sqrt ((mxn*mxn) + (myn*myn));
if (currentSpeed < playerObject.maxVelocity) {
playerObject.movex=mxn;
playerObject.movey=myn;
} // end speed check

}
if (aKeyPress[37]){
playerObject.arrayIndex--;
if (playerObject.arrayIndex <0) playerObject.arrayIndex=shipAnimationArrayLength-1;
//added in part 4
playerObject.bitmapData=aShipAnimation[playerObject.arrayIndex];

}
if (aKeyPress[39]){
playerObject.arrayIndex++;
if (playerObject.arrayIndex ==shipAnimationArrayLength) playerObject.arrayIndex=0;
//added in part 4
playerObject.bitmapData=aShipAnimation[playerObject.arrayIndex];

}
//*** added for part 3
if (aKeyPress[90]){
fireMissile();

}

}
[/cc]

You can se in the above code we simply added
playerObject.bitmapData=aShipAnimation[playerObject.arrayIndex]

when a change is made to the animationIndex.

So, that's basically pixel perfect collision detection between bitmapData objects in a nut shell. You need 4 pieces of data:
1. A reference to the bitmapData object for the first object you want to check.
2. A reference to the bitmapData object for the second object you want to check.
3. A point object representing the current upper left corner x and y values of the first object.
4. A point object representing the current upper left corner x and y values for the second object.

I usually leave the Alpha threshold values at 255, but I can see a need for them with more complicated objects. So, here is what the code looks like for the hitTest between a rock and the playerObject:

[cc lang="javascript" width="550"]

package {

	import flash.display.MovieClip;

	import flash.events.*;

	public class StartBox extends MovieClip {

		var parentClass:MovieClip;
		public function StartBox(parentVal:MovieClip) {

			parentClass=parentVal;
		}
		public function startit():void {

			parentClass.addChild(this);

			trace("starting startBox");

			x=80;

			y=100;

			start_mc.addEventListener(MouseEvent.CLICK, startButtonListener,false,0,true);

		}
		public function stopit():void {

			start_mc.removeEventListener(MouseEvent.CLICK, startButtonListener);

			trace("stopping startBox");

			parentClass.removeChild(this);

		}
		private function startButtonListener(e:Event) {

			stopit();

			parentClass.startGame();

		}

	}
}

[/cc]
Final notes and optimizations
If you have read through all 4 parts of this tutorial, you will note that I didn't go as deep into making a finalized game as I initially intended. I decided to focus more on optimizations than adding in Mochi Ads and Leader Boards because those might not be relevant to all readers. If you compare the code provided for the Main class in part 3 with the code above for part 4, you notice quite a few changes. All have been noted in the variable definition section and inside the code where needed. Mostly, I moved many variables that were being locally defined over and over in loops and made them global variables. This gives the game a larger initial memory foot print, but will save much execution time while the game is processing.
That's it, if you have any questions or comments, please email info[at]8bitrocket[dot]com, leave a message below, or visit the forums and post.
Jeff Fulton (8bitjeff).


Filed under: Tutorial-Flash, Tutorials
2 Comments







20Mar/080
Flash Game Development Inter-web mash up : Mar. 20, 2008
The latest in Blog entries and articles that might interest Flash game developers. 
Mochiland and James Robinson bring you an absolutely essential article on Marketing Flash Games: The Other Half of the Battle. Please read the entire article, but in summary, Mark suggests that vigorous marketing of your game is essential once it is complete. His basic 3 points are:

  1. Create a distribution pack for email submit portals. It should include the protected swf file(s); logos and thumbnails; as well as a document with descriptions in various lengths, width and height information, and any other essential information about your creation.

2. Create a professional distribution email that says enough, but not too much about your game. Make sure to pinpoint what makes your game so special..

3. Make sure to maintain a list of portals (emails and submit urls) that you can attack once your games are finished. 
Steve has posted his latest opus, an article called Flash Game Design Kitchen Nightmares, where he details how to apply the Gordon Ramsey Kitchen Nightmares advice to Flash Game design. 
Google Docs has a slide show presentation by Brad Merritt, Lead Game Designer, Cartoon Network called Common Flash Game Mistakes. It is a 187 slide presentation that I was made aware of by browsing an evilzug Live Journal posting. It is a very detailed discussion on 2d camera issues and mistakes, keyboard control mistakes, lack of consistent communication and feedback to  the player, problems with relying on random numbers for game variation, issues with emulating previously published designs, and problems with setting game difficulty. He also goes into a number of smaller issues such as implementing power ups properly, making games too realistic, letting non-game players have too much say in a game design, using unfamiliar play mechanics, forcing the player to watch long intros before a game starts and much more.


Filed under: Flash Game Development
No Comments







19Mar/083
Flash Game Design Kitchen Nightmares
Flash Game Design Kitchen Nightmares
I've been watching a lot of the BBC America (plus the sub-par USA Fox version) of Chef Gordon Ramsey's reality show Kitchen Nightmares. You might know Chef Ramsey from the "foul-mouthed chef" reality contest series Hell's Kitchen. While that series is the standard by-the-numbers "Survivor meets The Apprentice" show, but with food, Kitchen Nightmares (especially the BBC version) is something else entirely. On that show, Chef Ramsey visits failing restaurants  to help them before they fall into financial ruin. He visits the restaurant, eats their food, comments on their menu, meets and watches the staff while they are working, and then gives his recommendations (usually peppered with the word "f*ck"). Most of the time, these recommendations fall into the same categories:

Simplify the menu
Sell what the public wants
Streamline your operations
Make sure the word gets out 

As it turns out, most restaurants (the ones featured on the show anyway) have similar problems, and these problems almost always lead to failure. Their menu  has too many items because they are trying to be all things to all people. The food they sell is too fancy or not the right mix for their location because the owner or chef are too emotionally involved in their own ideas and creations to see what will actually make a profit. Finally, they have too many people working in the wrong jobs and are creating artificial bottle-necks that drive customers away because they have had a bad experience. Chef Ramsey finds these flaws like clockwork, and bluntly tells the establishment what is required to heal their ills. Finally, after changes are made, Ramsey offers innovative ideas on how to let the public know about the new direction for the restaurant to get people through the door. The audience then watches to see if the establishment is willing or able to change it's ways fast enough to stay in-business.
Why am I writing about a "cooking show" on a blog dedicated to Flash game programming? Because as I've watched the show I've realized that the advice Chef Ramsey gives to failing restaurant entrepreneurs is great advice to anyone who is trying to create a business around offering their own creations that will be consumed by the public. I believe this extends to game design, and in particular, Flash Game Design.

Simplify The Menu: Not the menu exactly, but the elements of the game. Don't try to throw-in too much at once to cloud the main object of what you are trying to accomplish. In most cases, Flash Game designers are pretty good at this one. However, many games might be actually "too simple". They are based on a funny and or interesting but thin concept that is appealing at first, but has little staying value. Finding the right mix of features and ideas that will work might take some trial and error, but it seems that the most successful games have an appealing level of depth, but at the same time don't try to do too much at once. For instance a "tower defense" game at its heart is an addictive, one-sided game of "Capture the flag". The idea is simple, the execution is what makes the game a success.
Sell What The Public Wants: This might be hard to swallow, but it is possible that your "grand idea for a new concept in games and game play" is really not all that grand or new, and possibly, is not all that appealing. If you are in the business to make a living from your games, you might have to sacrifice the "big concept" for something that will appeal to the general public. This does not necessarily mean that you should copy a game that is current a success. Popular games are good guide as to what the public currently wants, but a cheap knock-off won't buy you much staying power. Instead you should should glean the elements that you think make make the popular, and make sure to fold similar elements or game play into your creations. The game should be accessible to the masses, but have just enough unique elements to make it stand-out.
Streamline Your Operations: This doesn't not apply to staffing, because most Flash game developers are very small operations. However, this does apply to resources you include in game itself. For instance, many games skimp on small but important elements like well thought-out controls, animation, sound, and music. The "idea" of your game might capture people initially, but the nuances of these other elements will keep them playing. My game Hot Wheels Trackmod, has been played now over 50,000,000 times. Most of the feedback I have received is along the lines of "I love the sublime game play, but the hypnotic music keeps me playing". Ira Willey has great blog entry named How to make a successful Flash Game that details many of these important elements that will help set a game apart from the pack.
Make sure the word gets out: No matter now good your game might be, getting people to play it takes more than just posting it on your site and crossing your fingers. James Robinson's recent article on Mochiland, Marketing Flash Games: The Other Half of the Battle is a fantastic guide on how to get the "word out" about your game. As well, the similar article on Mochiland , Sam Horton's Thumbnail Design: A Picture Is Worth A Thousand Plays details another important element in getting people to notice your game.
Franchise: OK, I made this one up myself mostly because the scope of the show Kitchen Nightmares can't address this, but most successful restaurants aim to branch out with more locations and franchises based on their good name and reputation. Your game should be no different. Create games and characters that you own (as soon as you create them they are copy-writed to yourself), that will (hopefully) become familiar to players. Create game engines that can be easily "re-skinnable" or re-used for more games of the same type or with the same characters of your own creation. This might take some advanced programming to accomplish (creating a re- usable state-machine game engine is good start), but the benefits will outweigh the investment in the time you take to develop your game code. People don't necessarily eat at McDonald;s because the food is exotic or gourmet, they eat at McDonald's because they know what they are getting. 



Filed under: Flash Game Development
3 Comments







18Mar/080
Site Down This Morning
We're not sure why, but the site has been down all morning. The hosting company was finally able to fix it, but we don't have an explanation as to why it occurred. We are using .net 2.0 and share an application pool with other sites on the same server, it could be that another site caused a problem, but we have no idea.
Anyway, we want apologize to anyone who tried to visit the site this morning. It is especially troubling because Pumpkin Man is getting a GIANT boost in plays today (10K already) and any clicks over to over to our site from portals were lost.
 


Filed under: 8bitrocket History
No Comments







16Mar/080
Mission Leprechaun

Gourdon Gruesome needs money. His untimely defeat at the hands of Pumpkin Man has left him broke and without minions to do his bidding. Help Gourdon finance his future evil deeds by rescuing Leprechauns who have been imprisoned in the potato field mazes. Gourdon must eat all of the clovers, and find all of the powers ups to complete each maze.  Find keys to unlock the prison doors and use rainbow transporters to get inside enclosed areas.
Watch out for rats and snakes, but be on the lookout for colored clovers, 4 leaf clovers, and mugs of ale. These will give you temporary powers to aide your quest.


Filed under: Games, Maze
No Comments







16Mar/080
The Mission Leprechaun Chronicles II
I did get one pretty good exclusive offer, but I have re-thought my need to sell off my IP and have looked for more places to post the game. Because the game has some tie-in to a holiday that is actually tomorrow, I figured that I should put it up myself, so I have changed the license offer to Non-Exclusive Only, and have started to upload the game to sites like UGOPlayer, Kongregate, NewGrounds, MochiAds for distribution, and abcarcade.com.
You can play Mission Leprechaun Here or check out the license opportunity at Flashgmelicense.com.


Filed under: Flash Game Development
No Comments









 
 Older Entries »




Our Other Sites
	

Management Sucks
Producto Studios

	

				
Recent Posts
		

				
Atari Announces Intriguing “Circus Atari” App for iOS
				
Things We’ve Learned The Hard Way #5: The Logic Of Mac Snobbery
				
Atari Pong Developer Challenge Diary: What The Radio Shack “TV Scoreboard” Taught Me About Game Design.
				
Not Flash! : The Angsty Zeitgeist Of HTML5 Technology Burnout
				
Things We Learned The Hard Way #4: The HTML5 Capabilities Meeting
				
		
Recent Comments
rozrywka na poziomie on Firework Blast! (2006)
rozrywka na poziomie on Firework Blast! (2006)
kultura masowa on Firework Blast! (2006)
oblicza kultury on Firework Blast! (2006)
apple iphone 4 jailbreak on 8bitrocket Diatribe: Drawing Vector Primitives into a BitmapData Object in AS2 and AS3.
Categories
		

	
16K Game Contest Entry

	
56k Connection

	
8bitrocket History

	
Action

	
Android Development

	
App Store Revolution

	
Apple

	
April 1st

	
April Fools

	
Atari 16K Contest 2010

	
Atari Navel Gazing

	
Atari Nerd

	
Atari Nerd Chronicles

	
Atari Poetry

	
Atari Pong Dev Challenge Diary

	
Atari ST

	
Book Reviews

	
Comedy

	
Contest Tracker

	
Contests

	
Corona Development

	
Daily Briefing

	
DevCon5

	
diatribe

	
Driving

	
Easter

	
Electronic Games Magazine

	
Electrotank

	
Engine

	
Essential Flash Games Book

	
Featured Games

	
Flash Game Development

	
Flash Games

	
Flash to HTML5

	
Forgotten Heroes: 80's Guitar Rock

	
Game Coding and Development Diary

	
Game Design And Theory

	
Game Programming Tool Kit

	
Game Reviews

	
Game Shift

	
Games

	
Google Chrome Web App Store

	
HTML 5 Canvas

	
HTML5 Canvas Book

	
HTML5 Canvas Games

	
HTML5 Game Development

	
Intellivision

	
Inter-Web Mash-Up

	
Interviews

	
iPod/iPad Develpment

	
Kids

	
Lost South Bay

	
Management Sucks

	
Maze

	
Mid-Core Game Reviews

	
Mid-Core Gamer

	
Misc Retro Games

	
Movies the Need To Be Made

	
Music with No Talent

	
Pixel Art

	
Podcasts

	
Poll

	
Predictions

	
Producto Studios

	
Puzzle

	
Random Awesomeness

	
Rest In Peace

	
Retro Excavation

	
Retro Game Magazines

	
Reviews

	
Shooter

	
Signs Of Doomsday

	
Silverlight

	
Simply Brilliant

	
Sociology Of Programming

	
Star Wars

	
Survey

	
The 8-bit Game

	
The Bug Off Development Diary

	
They Used Our Kung Fu

	
Things We've Learned The Hard Way

	
This Day In Atari History

	
This Day In Atari History

	
This Week in Atari History

	
Truth In Advertising

	
Tutorial-Flash

	
Tutorial-HTML5 Canvas

	
Tutorials

	
TwinEngine

	
Uncategorized

	
Video

	
Web Site Development

	
Word

	
World Famous Flash Retro Showcase

		
Archives
		

			
May 2012
	
April 2012
	
March 2012
	
February 2012
	
January 2012
	
December 2011
	
November 2011
	
October 2011
	
September 2011
	
August 2011
	
July 2011
	
June 2011
	
May 2011
	
April 2011
	
March 2011
	
February 2011
	
January 2011
	
December 2010
	
November 2010
	
October 2010
	
September 2010
	
August 2010
	
July 2010
	
June 2010
	
May 2010
	
April 2010
	
March 2010
	
February 2010
	
January 2010
	
December 2009
	
November 2009
	
October 2009
	
September 2009
	
August 2009
	
July 2009
	
June 2009
	
May 2009
	
April 2009
	
March 2009
	
February 2009
	
January 2009
	
December 2008
	
November 2008
	
October 2008
	
September 2008
	
August 2008
	
July 2008
	
June 2008
	
May 2008
	
April 2008
	
March 2008
	
February 2008
	
January 2008
	
December 2007
	
November 2007
	
October 2007
	
September 2007
	
August 2007
	
July 2007
	
June 2007
	
May 2007
	
April 2007
	
March 2007
	
February 2007
	
January 2007
	
December 2006
	
August 2006
	
July 2006
	
July 2004
	
January 1995
	
July 1991
		




Copyright © 2012 8bitrocket.com · Powered by WordPress 
Lightword Theme by Andrei Luca
Go to top ↑