Atari Haiku: Baptism By Pixel

Baptism By Pixel


The back of the store


Right of the housewares


Next to the fire door

Heavy Sixer with Combat!

Two wide-eyed kids


Thumbs on the buttons

CX-40s in our palms

Hands and eyes in-sync


“This f-ing rules man!”

“cool-ass games on a TV!”

“Much better than Pong!”


Tanks, bi-planes and jets

Bouncing shots, racking-up scores

We play while mom shops


“This aint no arcade”

Yells the TV salesman in

The C&R suit


He says “That’s it boys”

He then hits the power switch

“Not get outta here!”


We skulk away

From the TV section, but

We will be back soon

Balloon Pop!

So, if you have looked at our Work In Progress page you will notice that we have a lot of half-finished games and ideas that we plan to someday come back to.   To be honest, the list on that page really only scratches the surface.  I probably have 2 dozen more games to add on that page.  I plan to to start adding more as soon as possible, but there are so many that it cuts into my time to develop and finish ideas.

One of the games on that page is simply named Balloon .   It can’t recall exactly why I started to make it, but I’m sure it was for some type of game related to a girl’s toy in 2001.   At the time it seemed like a no-brainer:  who doesn’t like the the satisfying feeling of popping balloons?  (my wife, it turns out, but that’s another story)   However, after getting the rudimentary code finished that would allow the balloons to be randomly created and a mouse roll-over to pop them, I quit.   I still like the concept thouugh,  I think it will work especially well for Nintendo Wii focused browser games.

So, my first step was to take a look at the balloon.fla file to see what I was thinking 6 years ago.   Apparently, I was not thinking of much because the Flash 5 Actionscript programming was terrible.  Code on all sorts of layers, embedded in movie clips, embedded ON movie clips.   I decided to salvage the graphics only, and move on.    I have begun a new version named Balloon Pop based on the Fireworks Blast engine.    It is mostly object oriented at uses Actionscript 2.0 code, and has some physics and trig routines already built-in, which will help speed development.

The first real decison I have to make is how to handle the controls.  For a Web Flash Game, shooting ballons Pooyan style seems fun, but the for the Wii, this might pose a problem.  You can’t click the button fast enough (at least in my tests) to make a playable game that requires fast mouse clicks.    I might have to re-too la Wii version that relies on roll-over.  Hmm…


Nintendo Wii Flash Development

So we are just starting to experiment with Flash games designed specifically for the nintendo Wii.  I started this process on Dec. 24th, the day the Wii opera Browser was downloadable. That day I got the first version of Fireworks Blast ready to work on the Wii.  

Thge first thing I discovered was that the Wii Flash player is slow.  It only runs Flash 7 and below, which is fine for a Beta, but makes playing most modern Flash games very difficult.

The next thing I noticed is that the (A) button response on the Wii is not like a mouse click in any way.  The (A) button simply does not register every click.   It seems like the button needs to be completely pressed and then depressed before it will register a second click.  This means that most fast action games where the player fires rapidly are out too…for now

The 3rd observation I made is that the resolution displayed must be optimized to give your games the best look possible.  After searching a bit on the Internet, I found that the people at had found out that the best possible rosultion for Wii Games is 608×456.  However, 640 x 480 is supposed to scale properly as well.   I’m not sure if this is the same for 16×9 presentation.  I will have to research that.

That’s it for now.  We are just starting this section, but we hope to optimize as many games for Wii play as possible.



Haiku: Breakout 2600

Breakout 2600


Hypnotic death notes

Each block wails an 8-bit tone

Blinks out then silence


Burrow A Hole Through

Your color-banded shield

Watch ball go ape-crap


Difficulty B

Paddle too tiny. Back to

Difficulty A


One last little block

Yes! I cleared level two

What? No Level Three?

A different approach to path finding.

I spent the last week working on jStar. After researching and working with a* for the last few days, I came to the conclusion that while very powerful, it was slow and overkill for my arcade-adventure, shoot the robots game. Also, since the player is constantly moving, the recalculations using the recursive path finding approach was killing my frame rate. I will explore more on this later, but I basically threw every thing I was working on to the side and set out to create my own path finding routine.

I started with these constraints:

1. I don’t need 360 degree movement, my enemy robots only need to move up, down, right left. For this reason, even 8-way a*. is a little too much power for my use.
2. Actual collision detection between the enemy robots and the walls is time consuming and difficult. If I can eliminate the need, it would speed up the routine significantly.
3. The robots can be intelligent, but they don’t need to be smart, remember, they are robots.
4. The grid squares for the robot movement must be large enough to hold an entire enemy robot. That would mean completely changing both my grid and my sprites. I thought maybe a complete over-head perspective would suit this fine.
5. I would need to create a specific, invisible path that the robots can walk on, eliminating the need to a* like calculation, and collision detection between robots and walls.
6. The path should be drawn so there are always 2 tiles that the robot can move to from the current tile.

I took these new constraints to the computer and sat down to write some pseudo code. Here is what I cam up with:

If Robot Not Moving then
	check to see what CURRENT TILE the robot is in
	check the tile UP, DOWN, RIGHT, LEFT tiles from CURRENT TILE
	if a tile is on pre-determined ROBOT PATH , push it to movement stack (this should always result in 2 tiles)
	Compare the two tile by taking the absolute value of the different between the x and y positions of the tile
	and the x and y positions of the player.
	Which ever produces a lower number will be the CRITICAL path on the pre-determined movement path.
	set Robot Moving Boolean to True
	Add the the delta to the movement x,y for the robot for the next frame
	Before moving the robot, check to see if it was made it completely inside the destination path square
	if so, stop the robot set Robot Moving Boolean to false
end if

That’s basically all there is to it. You can test this completely new and very basic looking overhead version by clicking the link below.
Use the arrow keys to move the green circle with the “P”. The Red Circle with the “E” on it is the enemy and he will attempt chase you on the path.
See jStar in action

Obviously, there are a few things are left out. The first one is the robot’s ability to fire a missile at the player when within range. The second is collision detection between the robot and the player. Lastly, if I want to use the “berserk-like” perspective I have already put hours into designing, I will have to modify this engine. Those are my next steps.

Path finding…sucks!

Ok, so I can count all of my previous experience programming path finding algorithms on two fingers. The first was in high school when Steve and I had a very rudimentary computer class instead of typing. One of the basic programming tasks we were asked to perform was to make a simple chase game on an old HP CPM desktop computer. I actually don’t remember if the machines ran CPM or not, but they surely didn’t run MS Dos. Maybe HP had some sort of proprietary desktop operating system, but I didn’t care enough at the time to find out. I am sure I also attempted some simple chase games on the Atari 800, but I can’t put my finger on any solid examples. The only other time I have even some simple AI was in Retro Blaster, my forthcoming Asteroids on steroids game. In that game I created some simple and complex patterns for the enemy ships to use, and I had enemy missile find the player using simple vector math which produced a direction for them to move toward the player.

So, this morning I decided to read up on path finding around objects for Retro Goes Berserk. If you have read any of the other entries on this game, you might recall that it is a maze chase style action adventure game where the player must negotiate a series of rooms, fight robots and find the pieces to a reactor before time expires. In the game, I need to robots to chase the user. The play field is set up using a grid of 10X10 blocks as tiles. The walls are just a series of these blocks attached to one another. The most difficult problem I had accomplished so far was to create a tile based collision detection routine for the player’s hero. This is an efficient method of collision detection because it doesn’t rely on looping through all of the tiles on every game loop pass to check collisions between the player and the walls.

Anyway, to make the robots move, I had to use the exact same collision detection code, but add path finding around the walls so the robots would move in at somewhat realistically intelligent manner. I first consulted Jobe Markar’s discussions of A* in his great Flash game programming books. A* sounded great, but after more investigation I found it better for use with over-head perspective sprites that can be rotated 360 degrees for absolute realism. Since my game is to be much simpler than that – all characters can only move up/down/left/right, I figured it would be better to create a modified version that would include changing the facing and animation frames for each direction the robot would be able to move.

After also consulting O’Reilly’s AI for Game Developers book, I decided on this for my pseudo code:

*** jeff’s 4 direction path finder (j* for short)
//1. figure out where the player is in relation to the robot
//2. re-arrange up, down, right, left directions in an array best possible moves
//3. try the best one first, if robot can move there (tile is a floor) then move him.
//4. if he cannot move there (tile is a wall) then try the other three until he can find a direction to move, or don’t move at all.

That’s it, it seems pretty simple at first glance, and after some fits and starts at figuring out how to use and sort associative arrays in Flash ( the first idea I came up with a complex data structure that can be sorted) I went to work creating this code in a sample .fla file:

var aDirection:Array=new Array();
var x2:Number=player._x;
var x1:Number=enemy._x;
var y2:Number=player._y;
var y1:Number=enemy._y;

var diffx = x2-x1;
var diffy = y2-y1;

trace(“player x=”+x2);
trace(“player y=”+y2);
trace(“enemy x=”+x1);
trace(“enemy y=”+y1);

var absDiffx:Number=Math.abs(diffx);
var absDiffy:Number=Math.abs(diffy);
if (diffx < 0) {
} else if (diffx>0) {
} else if (diffx == 0) {
if (diffy>0) {
} else if (diffy<0) {
} else if (diffy == 0) {

aDirection.sortOn(“value”, Array.NUMERIC);

for (ctr=0;ctr<aDirection.length;ctr++) {
trace(aDirection[ctr].direction + ” ” + aDirection[ctr].value);


If you place two movie clips on the screen, and name them “player” and “enemy”, this code will create an associative array that contains the values up,down, right, left in the order of which is more relevant to moving the robot (enemy) in the direction on the player. The relevance is based on how far each is from the player. This was just my first attempt, but it worked pretty well in theory. I added in rudimentary hit detection by taking 3 points on the robot and checking whether any of those 3 points will hit a wall in the first direction, if so, then I choose the next direction in the list, and so on until the robot can find a direction to move. Since in reality, there will always only be two relvant paths directly to the player (without worrying about walls), either up/down or right/left will be #’s 1 and #2  in the sorted list,. The remaining two get values of 1000 (for sorting)  and will only be tried if needed.

The this took all day to write and integrate into the existing game, and unfortunately, I will have to go back to the drawing board. The problem is this: if the robot needs to go down, but it hits a wall, it then looks left, right and up for a new direction that doesn’t hit a wall. Well, for some reason, it doesn’t go left and right, it seems to go up, then on the next frame go right back down again and then go back up, etc and repeat. This basically happens if the player stops in front of the robot, but behind a wall. Anyway, I am tired and need to get back to this tomorrow. My next attempt will be closer to A* (which uses tiles to find all adjacent tiles that the robots can move in, and then grades each for which would be the best move). I will use something similar, but I will just move the robot in 4 directions so I can make effective use of my pre-created robot animations that go only in 4 directions.

Play test this version of the game with the flawed first edition of J* path finding.

Pixel Art, Game Design, Legos, and more

Even before we owned a computer or game console, Steve and I were designing games. All the way back in 1978 I was borrowing graph paper from my dad and designing pixel art of space ships, baseball games, and what not. Computer graphics design was a brand new field, and the rudimentary nature of the early game visuals made designing games accessible to even an 8 year old kid. I didn’t need a computer to envision the games I wanted to make (and wouldn’t have my own for 5 years), and even if I did have one back then, I would probably have been very disappointed in resolution and lack of colors on the Apple I and TRS80. All I needed was an idea, some colored pencils and a pad of excess paper that my dad brought home from Hughes Aircraft. I had absolutely no idea what the resolution was of the machines of  the time, but that didn’t matter. I would spend every possible minute at grocery stores, pizza places, and even 7-11s, playing and watching my favorite games of the day – Asteroids, Space Invaders, Star Castle, Galaxian, and Wizard of War. I would then go home and take the colored pencils and graph out what my games would be like, envisioning worlds different from my own, baseball stadiums, soccer fields, breakout clones, driving games, and especially Star Wars games. Electronic Games magazine fueled this even further. I think Steve and I bought every issue until its untimely demise in 1983. We begged and borrowed to buy and pour over every issue more than a year before we even had a 2600 console of our own. The images and art in this magazine just added kerosene to the game design fire in the bellies of two young video game mad young boys.

Before video games, the most creative way for kids of the 70’s to imagine space worlds and imaginary places was with Legos. The Lego sets of yesteryear were far different than the ones of today. We were forced to be creative and imagine what a boat or a plane would look like if it was built almost completely with 2×4 bricks and maybe (maybe!) a special piece that took the shape of a windshield or propeller. That is very different from today where the boat set of Legos comes with a giant hollow boat piece and the child basically adds accessories to the it (not unlike a barbie doll). The similarities to pixel art and basic Lego bricks are numerous, with the rigid grid of brick placements, and the limited color pallet to choose from, Legos basically were a proving ground for our later game design and development.

One of the reasons I like designing 8 and 16 bit style games now is that pixel art can be used to create very clean looking, effective worlds, players, enemies, etc. I almost feel like one of the earliest game developers who had to be the game designer, programmer, artist, and sound engineer all in one. Flash (and other high level languages), along with Photoshop, Acid, and other modern tools give the retro programmers of today high powered tools to quickly replicate what took computer science wizards and MIT versed hackers years to perfect at Atari and Apple.

When I was 10, our school was one of the first to obtain some Apple II computers. I spent many hours banging out simple game graphics, and designing elaborate worlds on graph paper, and then hunting and pecking my way through Apple basic’s plot commands. This game design fire was turbo fueled when when Steve and I received our Holy Grail Atari 800 in 1982 and all the way through obtaining the Atari ST, a 386DX40, and into modern PC times with animated gifs and what not for web sites. Pixel art (even though I still am not very good at it) is a skill that I have always needed, have always tried, and have always been kind of terrible at. I remember wanting to make games so terribly that Steve and I asked our mom to drive to HW Computers in Redondo Beach just to look at the Basic Language cartridge for the 2600. The was the first time we had seen an Atari 800 computer. The store employee basically warded us away from the 2600 basic cart and told us what we WANTED was the an Atari Computer. We grabbed a store software catalog, took one look at the 800 versions of Pacman, Missile Command, Breakout and other games, and we were reeled in hook line and sinker. It would still be a couple years before our family could afford the roughly $800 in extra 1970’s cash ($2500 now) that it cost to obtain this heavenly machine. One of the first games I played on that wondrous Southern California Christmas morning was K-razy shootout. That game and similar games of its ilk are the major inspiration for the current game I am working on called “Retro Goes Berserk”, and of course pixel art will play a major role in the design of the game.

On the Atari 800 we redefined the character set in the larger text mode and made simple grid based games and shooters in basic. We used 8 bit character sets to design Price is Right, and sentence generator games. We sought out game design books, and software that could be used to make even the simplest of games. I remember painstakingly typing in Antic and Analog game program listings and pouring over any and all game and graphics related basic code in Compute! and similar magazines. Unlike today, where every borders has a huge selection of computer books and a good smattering of game programming books, in 1982, you were lucky to find a Microsoft Flight Simulator flying manual if anything at all. Game programming was a series of tricks that only an elite few knew of, and even fewer mastered.

On the Atari ST we dove into GFA basic, DEgas Elite and STOS to plan out adventure, Yahtzee, and space shooter games. The PC brought us into the real work world where programming was not for fun, but for business applications. But Borland C++ allowed us enough power and to knock out some DOS games and begin the journey to the World Wide Web that has taken us up to this point. There were many breaks in game design time during all of these periods. School, girls, sports, work and all manner of other distractions have played a part in my never being satisfied with the catalog of games I have completed when compared to the wealth of ideas that have been left on the table. There were even years when I didn’t play any games at all much less have time to build any of my own. The time has finally come to put all of these ideas from the past 29 years to good use.

Over the last few days I have been working of some in game graphics for Retro Goes Berserk. I have blown them up slightly here so you can see the design a little better.

Here are the frames from the Hero of the game.

He is pretty basic looking. The first three frames create the illusion of a simple walking animation, while the final 4 create an even simpler up and down walking animation. I decided that all characters in the game would face forward when walking down the screen and face backward when going up the screen.

Here are the frames for the robots in the game.

This is the robot that you will fight in the game. The same up and down, left and right idea that applies to the hero, also applies to the robot. The one change is that the robot is on a tank-like track (he doesn’t have legs to walk on). I needed to create three frames for the tank track movement in each direction so when it plays back it will look at least a little like the tracks are moving forward.

I have also just begun preliminary graphics for the other elements of the game: Health packs, ammo clips, a turret that spins, follows the Hero and fires are him, and the pieces of the reactor that the Hero is trying to find to piece together the bomb to destroy the fortress.

The final picture is a blown up copy of the three types of guns the player will use in the game.

These all look pretty simple and rudimentary, but for someone with limited design / art skills (like me), they took a little time. The reactor was the easiest (as you can tell). It will be broken up into 4 pieces and scattered around the fortress for the hero to find.

Atari Nerd Chronicles: First Communion

Atari Nerd Chronicles: First Communion

In the fall of 1977 my mother surprised my 7-year old twin brother and I with some information that we had never bothered to learn beforehand: she told us we were Catholic. This came as quite a shock, as I had no idea we were religious.  We had attended church on most Sundays, but my dad was not into it at all and I had figured it was just something we did to get us out of the house to waste time between the Ch. 5 Tom Hatten Popeye show in the morning, and Ch. 9 Horror film Festival in the afternoon (pre-“Elvira Mistress Of The Dark”). It never occurred to me that we were actually serious about it.   However, the mere revelation that we were now religious was not the whole story, work was involved.    Now that we were Catholics, we would have to attend CCD class, a weekly one-hour bible study/snack time that was designed to prepare us for the second most important Catholic Sacrament, First Communion.  This in and of itself was not terrible news.  However, it turned out we were starting CCD class a year late, which meant as Second Graders we would be stuck with a bunch of immature First Graders.   Second graders mingling with lower classmen was a horrible situation to begin with, but then the other boot dropped: when would be carpooling with one of the aforementioned First Graders. Could it have gotten any worse?

No.  It got better, in fact, much better.  The ‘First Grader’ turned out to be a cute girl from up the street named Lori Cunningham.  She lived with her divorced mom and grandmother.  Her dad was no where to be found, and no utterance of his existence was every made.   Lori’s mom had a pretty plum job with the phone company, and she spent a lot of money buying Lori cool toys and gadgets that Jeff and I could only dream of owning.  It was obvious that Lori’s mom was trying to fill a void in Lori’s life with all this stuff, but she didn’t seem to mind at all, and in turn, neither did we.  By the spring of 1978 Jeff and I started hanging out at their house before and after CCD class, and soon after on the weekends too.  The three of us became pretty much, inseparable.  We played after school, on weekends, and any other time we could muster. We watched Select TV movies with her and her mom on Friday nights, and took trips to amusement parks together.  If there were ever any three people who could be called best friends, it was Jeff, Lori and I.  It was the first time I had ever experienced something like it in all my life. 

While it wasn’t the only reason we became friends, the lure of Lori’s cool toys was too much for either Jeff and to resist. Lori had ‘2XL’, an early talking robot learning toy that used 8-track tapes to simulate choices made by the user.  She had all manner of handheld electronic games from Tiger and Mattel, plus her own TV set and radio.  However the thing that made us never want to leave her house was the wood-paneled, ‘heavy sixer’ Atari 2600 VCS.  Her mom bought it for Christmas 1977, the first year it was available.  Along with the 2600, her mom bought her every game at the store: ‘Combat’, ‘Air Sea Battle’, ‘Basic Math’, ‘Blackjack’, ‘Indy 500’, ‘Surround’, ‘Video Olympics’ and even ‘Star Ship’.  By the time we started playing it with her, they had added ‘Street Racer’, ‘Outlaw’, and the title that would start my personal love affair with video games, ‘Breakout’.

‘Breakout’ was an Atari 2600 translation of an arcade game conceived by Nolan Bushnell, and designed by Steve Jobs at Atari in 1976.  The game consisted of a ball, a paddle at the bottom of the screen controlled by the player, and series of walls that needed to be destroyed by hitting the ball into them.   Brad Stewart, who would later go on to program  Asteroids for the Atari 2600 and then move onto 3rd party software pioneer Imagic, created Breakout as his first project for the Atari 2600.  He won the right to program the game by beating fellow programmer Ian Shepherd at the coin-op version of the game in the Atari break room.    The game was a masterpiece: the first real ‘puzzle’ type game ever created, and certainly one of the most insanely addicted experiences ever conceived. 

I remember the day I first played ‘Breakout’ vividly.  It was Lori’s 7th birthday party and her mom had bought her a slew of new Atari cartridges.  Jeff and I arrived at the party early, and the three of us jumped into the playing the 2600.   However, as more people arrived at the party, and Jeff and Lori went into the back yard to join with everyone else, I found myself unable to move.  I was caught in the clutches of ‘Breakout’, and I could not escape.

The elegant side-to-side movement of the paddle and, the simple musical tones that emanated whenever the ball touched anything combined to put  me into a near hypnotic state.   The sense was completely intensified when I hit the ball into the brown row of bricks.  This action increased the ball speed and shrunk my paddle.  The action suddenly went from pleasantly interesting to a battle for life itself.  Each time I hit ball with the paddle, a sense of relief swelled over me, but it quickly dislodged by the spine-chilling fear as the ball hit a brick or the wall, and raced back at my paddle. Euphoria and horror traded places in less than second, all the while a musical score of my own design was falling upon me.  The moment I ‘broke through’ the top of the brick wall, and ball began its brick-wall-brick-brick-wall dancing act at the top of the screen, the game became a completely transcendental experience.   Suddenly, the reward of the game came not from winning but from simply playing, and staying alive so that beautiful, euphoric, hypnotic feeling would not end.  The obvious poetic inevitability of missing the ball was lost on me at that age.  It just made me angry.   One more ball, or one more game was all I could I cared for.  I was going to keep it going, I was going to clear the screen of bricks.  I needed to. I had to.

The birthday party continued on in the back yard, but I don’t remember any of it.  I don’t think I ever stepped outside to see what it was like.  It was not a choice I made consciously that day, but it was one that I would affect me for the rest of the life.  The decision was made, that very day, for me to choose a virtual world over the real, one. 

If I could take back that fateful day of Lori’s birthday, I’m not sure if it would have played-out the same.   Playing video games at that time was just like anything else; riding a bike, watching cartoons, playing Garage Sports.  It could have meant nothing except a few lost hours and some practice with hand-eye coordination.  I could have turned away afterward, and gone to do other things, like skateboarding, surfing, yet I did not.    The moment my mind said “fuck, I’ve got to clear that screen” was the moment I bought the whole package.  There was no turning back.  The decision was made to live the life of video game addict, and I couldn’t even fathom the impending consequences.

If only I could have manipulated the real world as easily as that ‘Breakout’ paddle.  Jeff and I continued to be great friends with Lori through our Catholic First Communion in May of 1978, and through the summer.   However, by the fall, things started to change.  Lori continued on to Second Grade CCD, while Jeff and I skipped to Third Grade so we could be with friends our own age.  We still hung out every once-in-a-while, but with no solid reason to get together, our visits became more and more infrequent until they evaporated completely.   We went from best friends, to playing a bit on the playground, to waving in the halls, to a simple, occasional smile.  Lori started Catholic School the next year, and after that, she might as well have dropped off the face of the planet.  Not only did Jeff and I lose access to the Atari 2600, but we lost a good friend too, something that, as we realized not too soon enough, was not easily replaced.

I still played ‘Breakout’ whenever I could, but that was only on the rare trip to the arcade, or when it was on demo in the Fedmart TV department.  However, whenever I played that game, my mind raced back to those good old days with our friend Lori, First Communion, and how difficult it was to make the world into what I wanted.  However, those thoughts fleeted away as I entered the ‘Breakout’ zone. The moment I flicked the reset-switch, tapped the red-button on the paddles, and guided my rectangular on-screen avatar to hit the ball back into a brand-new wall of bricks, everything else seemed irrelevant.  The rules were simple, defined, and finite.  I knew I was in complete control of my little universe.  If I was good enough, I could make the game last as long as I wanted, maybe even forever. 

Atari Nerd Chronicles:: Garage Games – Literally

Atari Nerd Chronicles: Garage Games – Literally


As long as I can remember, Jeff and I have wanted to make games. I’m not exactly sure where to start this story, so for lack of a better place, I’ll pick  the beginning.  Jeff and I were born on January 24th, 1970, as 1 month pre-mature twins.  I arrived 4 minutes after Jeff, and was a complete surprise.   The doctors had no idea our mom was carrying twins  With both of us coming in at just about the 4lb mark, we arrived a bit underdeveloped, before our time and underestimated: a few of attributes that we have not been able to shake for most of our lives.


We grew up just like most suburban kids of the 70s; We rode our bikes, played guns and ditch ’em at the school, stayed out all day to come home when the street lights came on.  Our dad was an amateur motor-cross riding, fine-art major turned actor turned draftsman at Hughes Aircraft.  Our mom was an actress, turned housewife, CCD teacher and later a classroom instructional aid.  Our two older sisters were into KISS, Bowie, Iggy Pop, The Ramones and later grew into some of the first punk rockers in the area.  We lived in Manhattan Beach, which then (and now) sold itself as one of the premier beach communities in Southern California.  At the time, the city was quickly changing from sleepy beach town into playground for the rich and powerful.   It was common belief among the Manhattan Beach populace that the city was split down the middle: the ‘haves’ on the good side of town lived near the beach, the ‘have-nots’ (us), on ‘bad’ side, lived just to the East, across Sepulveda Blvd.    Still, we did not want for much. We had a nice little house on a quiet tree-lined street.  Food was always on the table (although it was often McDonald’s).  There was never a lot of money in the household, but we never realized it either.   The fact that our friends were always going on ski trips and had brand-new BMX bikes while we went on weekend trips to San Diego and rode hand-me-downs was mostly lost on us.    It just meant that we had to find creative was to entertain ourselves while our friends were busy doing things we could not participate in.   At a very early age, Jeff and started designing games of our own to help fill the days.

Our little house sat on pretty large lot of land.  The best feature was a 100 foot long driveway.   For a good amount of time in the mid-70’s, our mom had no car, and dad took the only drivable vehicle (a giant, white 4-door International pick-up) to work every day.   This left the entire driveway open for whatever games we wanted to play.   Jeff and I spent many days conceiving 2-player versions of nearly every sport imaginable. We referred to these sport as ‘Garage Games’ (i.e. Garage Baseball, Garage Basketball).  We didn’t own much official sports equipment, so we used whatever was available.   A found tennis ball (the old-money rich people up the street had their own tennis court) became baseball, and a bare open-hand, a glove.  We’d use the length of the driveway, and play a two-player version of over-the-line where the ball was thrown by the batter and the fielder did everything possible to stop it from hitting the garage.   An old, un-returned red rubber ball that rolled down the hill from the elementary school became our basketball.  The basket was two markings on the open garage door.   A basket was scored it you could wedge the ball between the open door and roof of the garage.  Brooms became hockey sticks, plywood on old roller skates became a street surfboard, the garage door became a soccer goal, two red wagons became race cars and the driveway our track.  We once spent a good amount of time pushing each other around on a broken-down 75CC motorcycle, pretending to be motor-cross racers before the gears froze permanently.

At about the same time, to try to make extra money, our Dad was taking electronics courses throughSouthBayAdultSchool.   He collected all manner of surplus extra electronic parts and broken equipment he could find, and stored it in the back of our garage.   Soon after, Jeff and I snuck in there and experimented with all the batteries, wires, lights, motors, potentiometers, etc. that were piling up in the back near the washer and dryer.   We had no idea what we were doing, but through trial and error started making electric gadgets with blinking lights,  switches, running motors, etc.   At one point we discovered that bouncing a marble off of a rubber-band stretched between two nails pounded into a board, created a pinball effect.  We then re-worked many of our gadgets into simple pinball tables with lights, spinning targets, etc.  They were very crude designs, created with very little electronic knowledge, and it showed.   Frustrating to play, and easily breakable, the ambition of the games far outstripped their execution and we were soon looking for other ways to make our own interactive entertainment.

Besides making up games in and outside the garage, there were many games and activities were devised in the ‘spirit’ of those Garage Games, but created in the house utilizing household items.   We spent many days creating animated ‘flip books’ out of every paper-back book we could find.   We would draw one little picture in the corner of one page, and use the indentation on the next page to make the next frame of animation.  Neither of us were great artists, so the animations had to be very simple. There was, at least, one full summer in theFulton household during which you could not read any soft-cover book without being distracted by cartons of exploding Tie-Fighters, flying arrows and text re-arranging itself running up the side of every page.

Another way we found to create our own games was to bypass the limitations of an already established toy and create something new out of it.    The best example of this was ‘Etch-A-Sketch Racing’.

Etch Maze


By using scotch tape and the lap timer on a digital watch, we created our own racing games using this seminal drawing toy.   First, one of us would spend the time to lay-down an elaborate track using scotch tape over the Etch-A-Sketch screen.  When that was finished, the other one of us would attempt to ‘race’ (draw a line through the track) as fast as possible without hitting any of the scotch tape lines as he was timed by the digital watch.  It worked fairly well, as long as the players were honest about not hitting the barriers. This kept our attention for a while and I’m sure we could have found many more uses for the Etch-A-Sketch Racing ‘engine’, but it was not to be.    Something else was on the horizon.

It seemed that just as soon as we had discovered a way to create games with an Etch-A-Sketch, many times more interesting things had suddenly arrived on the scene.  First came ‘Star Wars’ in 1977, which, basically, made everything else irrelevant.  All we wanted to do was play ‘Star Wars’, think ‘Star Wars’ and be ‘Star Wars’. Then, a year later, ‘Space Invaders’ arrived in the arcades and we were able to actually ‘play’ Star Wars’or a reasonable facsimile.  Then finally, later that year, the final nail in the coffin of our ‘Garage Game’ designs was delivered to us.  Its name was ‘Atari’ and it just about changed everything in our world.


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).

This site is protected by Comment SPAM Wiper.