Garage Launched Games!

Garage Launched Games!

If you haven’t read Steve’s first blog entry, you should take it in. It describes how we started making games (or at least how we started to want to make games), and gives you an idea of how little time we really have to make games in our “spare” time. With kids and families, and work, etc, it is very difficult to find time to make games. Since that is what we want to do, we make them in the few hours a week we can spare.

I have spent the last few nights creating pre-alpha version of Retro Goes Berserk.

What I have done is finally create (what to me is) an acceptable running animation for my little hero creature. He kind of looks like a little green space man with a backpack. Currently he is controlled with the arrow keys. The Z key will fire his weapon. You can select from 3 different weapons by clicking on the 1,2,and 3 keys. I have uploaded a version to test. I’ll discuss some of the details of creating this pre-alpha below, and it might help to have tried it out.

Play the Pre-Alpha here

The first big problem I had to tackle was the collision detection between the little green space man and the walls of the room (those are the blue square things that kind of look like walls if viewed from above). Since each wall tile brick is only a 10×10 square, using tile based collision detection on the space man sprite that is considerably larger took a little extra time to figure out. Eventually I decided to do 3 checks per frame. Each of these checks looks at where the spaceman will be on the next frame after a key has been pressed in a certain direction. In essence, when the player clicks on the right arrow key, my code does all of the calculations and checks before you visually see the little space dude move on the screen. In the case of moving to the right, I check to see which tiles he would hit with his head, his feet, and his middle origin point on the next frame. If any of those are a tile with a wall in it, he is not moved. There are still some collision detection problems with the walls, but I think I have masked most of them with slightly clever wall designs.

After finally accomplishing the collision detection, I drew 3 tiny gun sprites that are swapped out on the space man when you press the 1,2, or 3 keys. I then applied a modified version of Steve’s Particle Explosion class with my bitMapAnimation code to create an explosion that can be seen when the bullets hit the walls. I added in a frame rate counter in the bottom right of the screen. A good way to test the FPS is to stand close to a wall (facing it) and fire the [3] key gun as fast as you can. I watched the frame rate counter dip as animated explosions are created, animated and removed in succession on the screen. I could only have about 8 explosion going before I got a frame rare dip. I decided to use special code and techniques I developed while build my still unreleased shooter called Retro Blaster. If you try hard enough, you can still probably see some dip as multiple explosions are being drawn. What you can’t tell if how low the frame rate would have dipped if those same explosions were movie clips running through their animation sequences in real time. You could probably only have 10 or 11 on the screen at once before there would be a noticeable drop in frame rate. The reason is that the ParticleExplosion class creates and uses a movie clip for each particle in the explosion. Each particle moves on each frame, changing size, alpha, position, and rotation. There can be 100’s of particles in one explosion. Flash 8 is FAST, and Steve’s code is tight, but games need to use as many tricks as possible to be fully optimized. Because of the changes to the clips on each frame, the “cacheAsBitmap=true” attribute would be of no use, and actually slow the animations even more. The solution I have come up with to provide many animations on the screen at one time is called Bitmap Animation Caching.

If you clicked on the pre-Alpha link above, you may have noticed that before the game starts, the screen says “Caching Animations” and you can viability see a large red explosion on the screen. What I do here is copy each from of that animation into a bitmapData object. Those objects are then store in what I call a “reel”. The animation reel is simply an array of these objects that when played back in order will create the illusion of an animation. This is just like the flip book animations that you may or may not have created when you were younger. When an explosion is created on the screen, I simply place a blank movieClip at the coordinates where I want the explosion to to happen, and then attach a bitmap from the correct reel on each subsequent frame until the reel array has reached its length-1. I then remove the explosion object and clip from the screen.

Next up, I plan to design some enemy robots and add some AI to their movements. I can’t have the roots running into walls (well, not the smart ones anyway).

Retro Gone Berserk. Christmas is over time to start again.

Over that last few days working on the game has been a learning experience and an exercise in frustration. I finally found a halfway decent running animation to use as a template. It came from the 2600 version of Miner 2049er. Having finally found a decent animation, I dug into setting up a room in code and animating my little player around in it.

It doesn’t look like much and it also doesn’t play like much either. I have to admit that making small games in your spare time can be just as challenging as making PS3 games full time. Bedroom / home-office / garage game programming takes a lot of time. Those of us with children and wives can’t spend days on end creating exotic game engines, so we use the 1-2 hours a day we have at most to create fun small games.

Anyway, I digressed from the ugly monster you see above. My first attempts had the player 2x the size he is above and the walls a single square thickness. I liked the look of that more than this, but efficient collision detection has proven to be elusive no matter the size of the player or the walls. The problem detecting wall collisions is that you really need to ‘look ahead’ to where the player will be on the next frame and check whether of not he/she will be colliding with a wall. Also, for efficiency sake, I am using wall tiles and simple math to check the player’s registration point in the next frame against the tile. If the tile is a wall, then the player should not move. If I move the player first, then check for a hit (which very well might be the way I have to go), I might have strange issues with the player bouncing off the walls repeatedly. Since I have never made a game like this before, I just have to experiment to see what works best.

Click the link here and use the arrow keys to move the player.
Try a Demo

You will see that I was so frustrated with registration point collision detection that I applied a red ‘look ahead’ clip to the player. That clip actually moves first and does a ‘box’ collision detection on the wall. Unfortunately, that seems to not work right either. I highly recommend Jobe Makar’s books on Flash Game Development. In fact, his books are so good, that his ideas can be applied to any kind of small game development, even with programs like Game Maker. I will turn to his book now and use his chapter on tile based worlds to help fix the mess you have just witnessed. Hopefully in my next posting, I will have a demo that works much better. It may no look much better though

Atari Nerd Chronicles #1: The Beginning

While Jeff is starting this blog by instantly working on a new game, I want to take a look back before going forward. There are tons of old games we have worked on, plus many work-in-progress projects, stories and other stuff that I want to archive. If not necessarily for others to read, than just for my own selfish purposes.

I just started reading the book Commodork by Rob O’Hara. The book is not comprehensive history of an era like The First Quarter, or gripping yarn like The Cuckoo’s Egg , but instead,,  a very personal story in the vein of Extra Life.  It’s is a nice collection of anecdotes and a solid look-back at the BBS days of the 80’s. O’Hara chronicles his love of computers as a kid in Oklahoma, growing up through the 90’s. I recommend it for anyone who is even remotely interested in the days of ‘Personal Computers’ before the IBM compatible behemoth swallowed almost all but very few. Rob’s experiences mirror Jeff and mine pretty closely, except that Rob was a ‘Commode-Door’ junkie and we were solid Atari fans from California. I’ve been trying to write something similar for a long time, focusing on Atari, but I could never really find the right angle to keep the story rolling. Now that Mr. O’Hara has pretty much covered the ground fully (just substitute Atari 800 in your mind for Commodore and the story is pretty much the same), I feel a sense of freedom. I know that sounds weird, but it’s true. I’ve always felt that the 80’s computer era was story that needed to be told, and I felt the need to tell it, but now that his story is out there, there really is no need to cover the same ground. This is a good, because, while Jeff and I participated in many of the same activities chronicled in Commodork, the most important thing for us was not really covered by Mr. O’Hara: designing and making games.

While we did not officially start writing games until the late 90’s, there were many attempts, false starts, successes and ideas brewing as far back as 1981. Much like Mr. O’Hara, our first real love of computers came from the Apple II. When Jeff and were 11 years old, our friend down the street, Eric Barth got an Apple II computer. We would type all sorts of basic programs in and watch their results. However, the most enjoyable of these were the ‘rockets’. Since the Apple II display was very slow at updating, printing out text to the screen was painful to watch. However, we used this to our advantage to create some of our first ‘entertainment’ on the computer. We would use apple basic ‘Print’ statements to design ridiculously huge ‘rockets’. Then we would ‘launch’ them by running the program. See example below:

In aside from playing ‘MLB Baseball’ and ‘Astrosmash’ on Eric’s Mattel Intellivision, and watching second rate movies on ‘ON TV’ in his living room, this is how we spent most summer nights in 1981. While we did play games on the Apple (my personal favorite was shooter named ‘Ceiling Zero’) programming was what we really loved to do. Any possible way we could start making our own games, even if those ‘games’ were just animations that only worked because of the limitations of the machine we wrote it on, that is where we wanted to be.

Anyway, in honor of those first animations we made on the Apple II, we have decided to call this site, and our collective selves (myself Steve Fulton and my twin brother Jeff Fulton) ‘8-Bit Rocket’. The subtitle ‘Garage Launched Games’ signifies where we are coming from. While we do spend much of our time at our actual jobs (to be revealed later) making web-based games and entertainment, this site is not really about those projects. While we might mention them here, the work here is separate. This site is dedicated to midnight coders, garage games, and making your ideas come alive one hour at a time, at night, while the kids are asleep. It’s about those golden moments, when you are close to nodding off yourself, but your force fingers write that one last line of code so you can feel like you have accomplished something, anything, before the sun comes up and your real life starts again the next morning.

Retro Gone Berserk Day Two – When you can't draw, you improvise

Today I had time to work on the very very basic Flash version of the demo game. I have decided to make it as close to Bersek as possible for this first tech demo.  I currently have a room generated and a player running around the room, controlled with the arrow keys. What I have discovered is that the running animation needs more frames. I copied the two frames from the Atari 800 version and the player just runs like a spaz.

I decide to try the MAME version, but the player looks even more like a spaz in the arcade version of the game. Even though this will only be a tech demo game with very little optimized code and without a cleanly defined object structure, I still want it to look and play pretty well. All of the demo games that we post need to be as complete as possible so you guys can enjoy playing them, and enjoy pulling apart the .flas to see what makes them tick.

I have absolutely no formal art or design training (as you might be able to tell). So, before I ask someone like Marc Manalli (a seasoned, talented artist and animator) to help with a game, I need to at least try to create some good workable sprites of my own. Pixel art should be easy, but I really don’t know where to start with a running character that needs to be able to move up, down. right, left,  and in various diagonal directions. Plus, I need at least a simple illustration in multiple directions of him firing what needs to at least resemble a gun.  Since all of these demos will go in the games section of the site I needed to make something that wouldn’t immediately turn potential players off.

The first thing I tried was to Google ‘How to Draw a Running Man’. Nothing hit on that. I did get a Wikipedia entry for Pitfall. Did you know that the Atari 800 version has a complete separate game in it as an Easter Egg?  On another note, David  Crane, who designed and programmed the original 2600 version, works for a great company called Skyworks. They have created many-a great web game for various companies including my day job employers. He even signed my co-worker’s Atari 800!

Next I searched for ‘How to Draw’ and came up with many hits on good books that I might think about getting some day. What I really need to a way to copy all of the frames of the Intellivision classic running football player. Mattel had a pretty good simple 8-bit character that they used in many games. I visited the official Intellivision site, and they didn’t have what I needed. I’m not going to outright copy any images for any of my games, but an animated running man is a pretty difficult problem tackle for a sub-novice designer, so I need at least something that can act as an inspiration for my game design. 

The internet search under animated GIF was fruitless. There are so many crap sites out there that even if there was a goodx example some place, I’d never find it with that search. Next I decided to try some 2600 games. My thought was that maybe some of them had decent running or walking characters that I could try to view frame by frame. The first game I tried was Donkey Kong. Now, most people give this a bad review on the 2600, but I always like this game. My dad bought my brother this game for helping to move my grandma in 1982. It was the closest thing to the Arcade game at the time. We were always a little disappointed with our 2600 carts. Some were good (Demon Attack, River Raid), but most were just awful. I even remember always wanting something more from Activision games, even though most had the best visuals and game play. There was always something missing. For example, the skiing game on the Intellivision used the jump button for the player to avoid rocks and moguls, but even though Activision Skiing looked and played well, the button wasn’t used for anything, and the player jumped the rocks automatically. Anyway, enough of my digression, the Donkey Kong walking animation was not usable because its animation frames were much too difficult to separate.

Pitfall uses some ingenious animation frames, and the way David Crane made the ability to walk when the stick is pushed once, but run when it is held in a direction is a cool one, and I will try to use it as inspiration for my player animation. What I need is a piece of software that will capture the screen into a video. I know Replay software makes one for about $30.00, but I haven’t even needed the software. I’m trying not to spend much money making these games, so that might be out of the budget zone right now.

I FOUND ONE!!!
I had fun playing the emulated 2600 games, but none of them gave me the animation ideas I needed. I went back to the web and started hunting down other Intellivision sites besides Intellivision.com (a great site by the way).

My search of the internet brought me to an Intellivision Web Ring. On that ring, I stumbled onto a site called Intellivision Exhibition (http://www.hotcom.com/intellivision/). I found I pretty good running animated gif on that site. I hope to use it at least for inspiration. Tomorrow, more of the game demo + It’s my nephew’s 12 birthday. We got him Guitar Hero 2!! I can’t wait to play it.

Retro Gone Berserk Day One

I was able to squeeze in a little work on the new game between trips to various shopping centers for Christmas presents. One thing I wanted to research is how collision detection is done in these overhead perspective retro games. I fired up the Atari 800 KRAZY Shootout first to look at this closer. In this game, if any part of the player touches a wall, the player if killed. It is very basic, but because the perspective in these games is not a true ‘ or a true overhead, it actually comes out playing odd. See the diagram below.

.
The red circle shows the head of the player. If this was a true ‘ perspective, the player would not be injured or hurt until his feet touch the blue wall. In this game, even the player’s head touching the wall results in a lost life. I will investigate trying to remedy this in my game.

The Berzerk games play basically the same. Marauder remedies this situation somewhat by using a true top-down perspective. It looks odd, and player even more odd (for other reasons), but is actually more realistic in a simple way.  Since I plan to pattern my player movement after Berzerk (KRazy Shootout’s running player looks silly), I will need to either accept or remedy the all collisions.

My next step was to create some simple frames of animation for the player. The Berkerk Atari 800 player has two basic frames. One is a standing frame, and the other is a running frame. It doesn’t make for very fluid animation, but for this test, those two will be fine. A modification I want to make in my game is to have the gun arm controlled by the mouse. It won’t be 100% realistic, but moving the mouse left and right will rotate the gun to 8 different firing positions. This will allow the player to run in one direction and fire in the other.

I'm itching to start a new game.

With Retro Blaster nearly complete, I have decided to start on a new game. This one will be very simple. I plan to do a few simple games in the next few weeks to try out my bitmap animation techniques in a variety of more simple shooters.  Since I love 8 and 16 bit retro games, I decided to try out some Atari 2600, 5200, 7800, and 800 games a make a list of the ones I want to tryout.

 

One of the best places to research Atari games is Atariage.com. They don’t cover Atari 800 games, but they have a full and complete listing of all carts (and most of the roms too) released for the Atari video game systems. I would love if they would add in a section for the XE Game System and list all of the carts released under that label, but so far they do not have that information. For the most extensive listing of Atari 800/XL and XE games, there is no better resource that Atarimania.com.

 

One of the first games I played in the arcades of the 80’s was Berzerk. There were a number of versions of this game made for various Atari systems. Atari released the arcade port on the 2600, 5200, and 800/XL/XE. There was also game very similar game called K-razy Shootout released for the Atari 800. Yet another similar clone was a game called Marauder.  I will play all of these and maybe a few more clones, if I can find them,  to create a non-scrolling, screen, by screen adventure / shoot ’em up.  To keep it simple, the maze screens will be the same each game, but you will start in a different room each game.  There will be some items to collect, a few extra weapons and power ups to find, and a ‘reactor’ or similar item that will need to be destroyed before the player moves to the next level. Each level will use the same screens, maybe mixed up randomly, but will get progressively harder with more enemies to fight and fewer health and weapon power ups to collects. That seems pretty simple.. I’ll play the games emulated to get some more ideas.

 

One thing I disliked about 80’s games was the use of ‘men’ or ‘ships’ to depict lives.  This is purely personal taste, but I like the convention of health or hit points. I used that idea in Retro Blaster, and I assume I will use the same convention in this game. It helps makes all games a little more role playing-like and adds a little bit of extra strategy to the game. Also, while I love games like 1942, I hate that every time I get hit by any ordinance, my plane crashed and I had to start over. I may love retro style games, but if I can improve on older conventions and make them more fun (for me at least) I will. Now, on to the games:

 

Atari 2600 Berzerk

berkerk2600.jpg

 

This is a pretty good version of the game. The arcade game wasn’t overly complicated, but this is still a very impressive game considering the limitations of the Atari 2600 hardware. The basic idea is to run from room to room, shooting the ‘Cylon’ like robots. If you stay too long in a room, Evil Otto will arrive and try to destroy you player. Some interesting things to note about this version:

1. You can only shoot one shot at a time.

2. The little light on the front of the ‘Cylon’ moves left to right, and is not a light, but just a rectangle that is the same color as the floor.

3. Evil Otto comes out in game variation #2 pretty quickly, and makes the game a little too difficult.

4. There is no point to the game other than surviving for as long as you can and racking up a score. There is nothing wrong with goals as un-lofty as these, especially for a retro game.

 

 

Atari 800 Berzerk

 berkerk800.jpg

 

 

This version is much closer to arcade perfect than the Atari 2600 version. It adds a couple elements not in that game.  Here are my observations about this version.

1. You get a bonus for shooting every robot on the screen without dying, and you can shoot two bullets at a time. The bonus is in the 2600 version (10 points for each robot, but it doesn’t say Bonus, it just puts the extra score on the screen in place of the user score)

2. The game is still too damn difficult to play though.

3. The robot heads rotate in this one very much like the 2600 version.

4. Also, the door the player entered through will be sealed off with a different colored wall so he/she cannot go back through to safety. 

5. Oh yeah, in both 2600 and 800 versions, you will die if you touch any of the walls. Now, I don’t want to get picky about ‘realism’ in 2d game where you are being chased by robots and a bouncing happy face will kill you, but who in their right mind would build a maze in which the walls kill any who touch them?  I might add this ‘feature’ into my game, but then again, I may not,

 

2600 Marauder

 marauder2600.jpg

 

This game is much like Berezek with some well defined differences.

 

  1. There are only a limited number of maze screens. Each is slightly more elaborate than the screens in berserk.
  2. The player’s goal is to find and destroy a power cell before a bonus gage at the bottom of the screen runs out.
  3. The game is much more colorful, but ultimately uglier than Berzerk. The player and enemy characters are down right weird.  The reason for this is the added ‘realism’ in the game. First off, the characters are all view from a direct above perspective. This explains how squashed everything looks. Also, enemy robots and valuable items (well item) will be hidden or invisible from view if they are behind a wall. You,  as a player looking at a birds-eye view of the game do not have an advantage over the player on the ground. It makes the game strange to play, but it is an interesting idea.
  4. The goal of the game is to destroy the shoot a power cell on one of the screens, and then do it all over again, and again and again. It is ultimately too easy.
  5. The one very unique thing about this game is the ability to pick up magic amour that will protect the player for a few seconds.

 

Atari 800 Marauder

 

marauder800.jpg

The graphics in this version are much higher resolution than the Atari 2600 version. Unfortunately it was based on a Apple II game and uses a black and white or only dithered color mode of the 6502. The 2600 version comes out looking slight better because of this.  This version plays and sounds much better than the 2600 version though.  It contains  many more screen variations and a very satisfying explosion when the player shoots the power cell. I can’t find any instructions for the game. Atarimania.com does have a review and some good comments on the game, but without the docs, I have no idea if there is a set of magic armor in this game.  Special note, this is actually stage 2 of a 2 stage game. Stratos is the first stage. It is a completely different game. It is more of a Missile Command / Space Invaders style game with more colors on the screen.

 

K-RAZY Shootout

 

krazyshootout800.jpg

 

K byte software made quite a few arcade game clones for the 800. KRAZY Shootout was one of the first games I ever played on my 800 on Christmas morning in 1982.  I remember being amazed at the detail in the images and explosions. There are many nice features and touches in this game.

 

  1. When the player leaves a screen, it animates out in a unique way, flattening down like a pancake.  Also between screens there is a bonus counting screen. Bonus is awarded based on how much time it takes the player to finish a screen.  There are three bars at the top of the screen: green, yellow and red. The player receives bonus if he/she can clear a screen while in the green or yellow zone. If you don’t shoot all of the enemy robots before the end of the red zone, you have to start the zone over again.
  2. The maze screens are created at random.
  3. Beside enemy robots that are on the screen when the maze appears, more will generate in as the player destroys robots. Also, there is radioactive debris lying around the screens that must be avoided.
  4.  The control in the game is very well done. Your player cannot run and shoot, if the action button is pressed down, the player will stop. The gun can then be aimed in any of 8 directions and fired.

 

My Retro Gone Berserk game.

 

I imagine that I will make a game that is more a combo of K-RAZY Shootout and Marauder than just plain Berkerk. For a ‘quicky’ game, I still need to add enough elements to keep it fun. It needs some of the game play sensibilities that the NES and Sega Master System brought to gaming in the late 80’s.  Those would be extra weapons and maybe a secret room.  Here is a basic outline for the game I will create in Flash.

 

  1. The game will be in a maze of rooms in a 5×5 grid. That will be 25 rooms. All rooms will have doors at the top, bottom, left and right.  For each game and each level, the rooms will be the same structure, but they will be randomly placed in the 5×5 grid.
  2. The start room will always be on the edge of the grid. The goal will be to destroy the power cell, and exit back through where you came.
  3. All of the outside doors, the door that would lead to no where if on the edge of the grid will take the user to the opposite side of the grid.  That will be the case in every room BUT the start room. In the start room, the outer door will be marked ‘Exit’ and exiting through it will trigger the end of level sequence.
  4. There will be a timer like in KRazy Shootout.  It will look like a colored bar and start at green. It will slowly change from green to yellow to red. The player will get more bonus points if he/she finishes the level in the green or yellow portion of the timer.
  5. The player will have attributes much like in a role playing game. There will only be a select number of these attributes. Hit Points will act like a life meter. When Hit Points reaches 0, the game is over. Shield will represent how many hits the player can take before Hit Points will be deducted. Shield and Hit Point upgrades can be found in chests.  Fire Power will represent how powerful the player weapon is. It will start relatively low, but will increase as the player picks up Gun upgrades from chests. The gun upgrades will add to the number of bullets on the screen at one time, the number of barrels the gun contains, and the size of the guns bullets. There will be some nasty fire power at 100% gun power.
  6. The power cell will explode, injuring the player if not destroyed by before the time runs out.
  7. The enemy will be robots. There will be a couple types of robots. The basic drones will just fire and move randomly. The chasers will come right at the player and try to hit him. The Black Knights will be the hardest. They will shoot directly at the player and become much more difficult to destroy in later levels.
  8. The walls will be radioactive and the player’s shield or hit points will be drained in he/she touches a wall.
  9. I want to attempt to use a mouse/keyboard control scheme. The player will move up, down, left and right with the WSAD keys, but will move his gun arm 360 degrees with the mouse and shoot with the mouse button.

 

Next up: My first milestone in creating this game will be to demo a maze and movement noted above. The next blog entry will be a discussion of and a playable version of this demo.

 

Retro Blaster is coming

Right now, Steve is putting the final touches on the technical design for our 8bitrocket.com site. It won’t be spectacular looking, but that is because we want a pretty basic site.  While he is doing that, I am finishing up my latest game called Retro Blaster. It is basically Asteroids, but I have put a lot of work into the Actionscript animation engine, so it is more of a tech demo that has ballooned into a much larger game. 

Retro Blaster uses a relatively new Flash 8 technique that I call bitmap animation caching.  It is an idea that I got from a short optimization conversation I had with Jobe Makar (http://www.electrotank.com/) about blitting objects on the screen in Flash. One of the largest resource hogs in Flash is the rendering engine. Complex animations, with many points, use up an incredible amount of resources. For example, I am using Steve’s particle engine to create explosions. These explosions use a small version of the object that is exploding as a base particle. The objects can have many points, and the particle engine will create individual particles from these small versions of the objects.  Basic Movieclip bitmap caching is fine for objects that are simply moving across the screen, but if an object needs to run through an animation sequence, Movieclip bitmap caching is completely useless because it will cache each animation change each frame and because the screen is invalidated on each frame, you derive absolutely not benefit from the cache.  In some cases, the system runs even slower than without Movieclip bitmap caching.

My solution was to copy each frame of an animation into a Bitmapdata object. All of those objects are pushed into an array. When played back in sequence by copying each frame in the array to a MovieClip you eliminate much of the resource use (not all, but about 75%) compared to rendering on the fly.  Basically this amounts to pre-rending all of the animations needed for game play. Everything from explosions to asteroids rotating can be cached in a BitmapData array and displayed when needed.

My first attempts at this amount to simple tech demos where I places as many as 1000 objects on the screen, and displayed their cached and non-cached animations. I calculated the frame rate.The frame rate for 1000 non-cached objects never rose about 7FPS on my Dual Core 3Ghz machine.
See a demo of 1000 objects rendered with plain vanilla Flash rendering

The frame rate for 1000 cached objects would hover around 18FPS. That means I could put nearly 3x the number of objects on the screen with my new method.
See the demo of 1000 animation cached objects<.

Since a decent Asteroids clone would probably never need more than 100 objects moving and animated on the screen, I decided that I could lover the number to 300 and check the frame rate.  At 300 objects, the frame rate stayed at a comfortable 30FPS and didn’t budge. That made me feel secure that I could sustain at least 25 FPS, even in the most hectic of Asteroids games.
See the demo of 300 animation cached objects.

All three of these frame per second calculations will be slightly lower when played in a web browser. I timed these inside of the Flash IDE. This problem can be aleviated in a number of ways. The best is to set your movie FPS to 100, and then use setInterval to run your game loop. If you must use onEnterFrame, then make sure to play with the wmode propeties of the imbed code to see which value works for the specific browser you are targeting.

Retro Blaster was born out of this. I started with my own rudimentary graphics, but after being completely unimpressed with my artistic ability, I asked a co-working named Marc Manalli to help out. He is a very gifted illustrator and was able to whip up some great stuff in just a few hours.

Brickbasher: No Way Out (2006)

Raindown Fireworks Show (2006)

Firework Blast! (2006)

This site is protected by Comment SPAM Wiper.