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:

<strong>
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
Else
	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
</strong>

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);
trace(“diffx=”+diffx);
trace(“diffy=”+diffy);

var absDiffx:Number=Math.abs(diffx);
var absDiffy:Number=Math.abs(diffy);
if (diffx < 0) {
aDirection.push({direction:”left”,value:absDiffx});
aDirection.push({direction:”right”,value:1000});
} else if (diffx>0) {
aDirection.push({direction:”left”,value:1000});
aDirection.push({direction:”right”,value:absDiffx});
} else if (diffx == 0) {
aDirection.push({direction:”left”,value:1000});
aDirection.push({direction:”right”,value:1000});
}
if (diffy>0) {
aDirection.push({direction:”down”,value:absDiffy});
aDirection.push({direction:”up”,value:1000});
} else if (diffy<0) {
aDirection.push({direction:”down”,value:1000});
aDirection.push({direction:”up”,value:absDiffy});
} else if (diffy == 0) {
aDirection.push({direction:”down”,value:1000});
aDirection.push({direction:”up”,value:1000});
}

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

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.

This site is protected by Comment SPAM Wiper.