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.

Retro Gone Berserk Day One

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

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

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

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

I'm itching to start a new game.

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

 

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

 

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

 

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

 

Atari 2600 Berzerk

berkerk2600.jpg

 

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

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

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

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

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

 

 

Atari 800 Berzerk

 berkerk800.jpg

 

 

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

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

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

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

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

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

 

2600 Marauder

 marauder2600.jpg

 

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

 

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

 

Atari 800 Marauder

 

marauder800.jpg

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

 

K-RAZY Shootout

 

krazyshootout800.jpg

 

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

 

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

 

My Retro Gone Berserk game.

 

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

 

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

 

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

 

This site is protected by Comment SPAM Wiper.