Jump to content





Here comes Santa Claus...

Posted by , 13 December 2005 · 587 views

2600 Game Development Reindeer Rescue
AS MANY OF YOU are probably aware, I have been working on the AA Holiday Cart for the past month or so. I was keeping this a secret up until I was positive that I was going to get it done; but here's a condensed history of its development.

The new game is titled Reindeer Rescue, and it is based on the demo I wrote about a year ago called Running Man.

As I mentioned to Manuel a couple of days ago, it has been interesting going back to the very first thing I ever wrote for the 2600 - I think if I was starting from scratch to write Reindeer Rescue today, I would quickly abandon the project because I would not believe that I could write a kernel to do what I want.

Specifically, the scrolling part of the kernel. First, let me explain briefly:
The bottom half of the play area of the screen has 8 bands of horizontally scrolling playfield and two sprites. One sprite (Santa) can move freely throughout this area and is a multicolored sprite; every line of this sprite can be a different color.
The other sprite is restricted to fitting inside the bottom band and is a single color.Each scrolling playfield band can be a different height.

At the time, I had no qualms about writing a separate minikernel for each scrolling band - which means that this section of the kernel, about 60 scanlines, is 1K of code!

If I were writing it now I would try very very hard to get the whole 60 scanlines in a single loop - and I think, ultimately, would decide that it couldn't be done without some kind of compromise (striping playfield, flicker, something).

Anyway. I don't know if that makes any sense, but it was very interesting to look back at my first 2600 code. :)

I ended up rewriting just about everything except the kernel, actually. The only major changes I made to the kernel were to rewrite the sprite-drawing code to use illegal opcodes (dcp), and to squeeze in line-by-line color changes of Santa all the way to the floor (previously, the runner's color couldn't change during the bottom band). This allowed Santa to have black boots, instead of running in his socks. :D

This was an extremely rushed development! I didn't really start modifying the original demo until I heard back from Al that he wanted me to go ahead with this; after the Philly vgXpo. So I pretty much wrote all of it in a month :o

Which explains why I was still making changes and testing things this morning. :roll:

Also explains why the code is so sloppy and why I never got any other sound effects in except for Santa running and jumping. And when you get points. I really wanted to get a couple of squawks, roars, and zzzzaps in there (the code for playing sound effects is in there, but never gets called and there is no sound effects data to play if it did get called). Oh well. Maybe someone can hack some stuff in there someday. :ponder:

By far the trickiest part was handling collisions. There were a couple of big issues:
1) When I began development (mid-November) it was possible to back into the scrolling playfield. This was a problem because I didn't have an easy way to tell if you hit playfield from the front or the back, so I always moved you backwards if you touched playfield. This meant, though, that if you backed into the playfield it sucked you backwards and through whatever you touched! Not good. Eventual solution was to check the RAM locations where I stored the playfield data to see if there was a block of playfield behind you before I let you move backwards.
2) Because Santa leaves the ground completely in his running animation, it is possible, though difficult, to move Santa so that he ends up sticking his boots into middle of a playfield block. The picture below will hopefully help explain what I'm talking about: on the left, Santa is in a frame of animation where his feet would normally be off the ground, but his feet are flat on the ground. The right side shows what happens when his frame of animation changes to one where normally his feet would be flat on the ground: they are drawn below the ground.
Attached Image
This is a problem because it looks really weird to make a jump and it looks like you cleared it when suddenly the game behaves like you hit a playfield block and pushes you way back. This was very tricky to fix. In a brilliant move, since I hadn't seen the problem crop up at all since I changed from the running man animation to the running santa animation, I assumed/pretended that it had magically fixed itself. Well, what do you know, Nathan discovered that it did, indeed happen. And he discovered it last Saturday. So I was up very late on Sunday fixing this problem; what I ended up doing was changing the sprite images of Santa with his feet off the ground - I added a horizontal bar on the lowest line, so that even when his boots were off the ground, there was still a piece of sprite to collide with the playfield and prevent Santa from sticking his boots into the ground. The real trick was that I didn't want this bar to show up on screen, so it needed to be the same color as the background. That would be easy, except that there are 4 different background colors throughout the game, there isn't time to change colors dynamically during the kernel, which necessitated 9 new color tables for Santa! And each of these 23-byte tables needed to be a certain distance from the front and back of a page, plus I had already used up all the open spots for graphics data in the bank with the kernel. Fortunately, there was room in the bank to stick pieces of the kernel, so now the kernel jumps from place to place inside bank 1 like a crazed frog. Those were the biggest pain in the neck to solve but there were plenty more just like it. Alrighty; this post has gone on long enough. I'll close with an overview of where things are in the ROM:
Bank 1: Code that runs on poweron: clears registers, RAM, and TIA, and sets stack pointer. Initial setup stuff. VSYNC and the vertical retrace portion of the display, though this mostly calls subroutines that are in other banks.The play area of the kernel. Everywhere that Santa can go is drawn in this bank. Also, the portion of the title screen that draws Santa and the reindeer is in this bank. See the diagram:
Attached Image
Everything inside the red line is drawn in bank 1. All the graphics that go inside there are in bank 1.

Bank 2: The routine that scrolls the playfield plus all the level data. Also all the subroutines called during the vertical retrace are in this bank: Updating Santa's energy, reading the console switches, updating the score, moving the non-player-controlled objects, the subroutine that sets up a new level, and a kernel preparation subroutine.

Bank 3: This was originally going to be a bank for just music and sound effects. It ended up with those routines, and their data, plus all of the overscan. The overscan is where I deal with collisions, move Santa, play music, and process most of the game's internal logic, like checking death conditions, doing whatever needs to be done when you beat a level, etc. The kernel for the part of the screen above the red box in the diagram above is also in this bank, and the graphics for this part of the screen are here as well.

Bank 4: All other assorted kernels and pieces of kernels are here: the title screen kernel, the game over kernel, the game-winning kernel, plus the kernel for the area below the red box in the diagram above. Since all of those kernels make heavy use of 48-pixel-wide bitmaps, all the data for those bitmaps is here as well as a subroutine to display 48-pixel-wide bitmaps.




This sounds like a very nice little game, particularly with all of those sprite graphics by Nathan. Unfortunately I just bought all of the homebrews that I wanted at the vgXpo, so I will have to wait for you to post a binary at some point to see it in action, or until I can afford some of the other titles!

I think you are rather brave to go back to your old code like that - I recently had a look at the Hunchy source code (my first game) and it was not a pretty sight! I would probably be tempted to redo everything from scratch, rather than work through the issues. I'm also amazed that you managed to pull it together in such a short time period. I find that I always need a lot of "thinking time" between bouts of coding, just to figure out how best to tackle the problems. I am still thinking about the falling-tiles problem in PoP while you have written an entire game!

Chris
  • Report

This sounds like a very nice little game, particularly with all of those sprite graphics by Nathan.  Unfortunately I just bought all of the homebrews that I wanted at the vgXpo, so I will have to wait for you to post a binary at some point to see it in action, or until I can afford some of the other titles!

I think you are rather brave to go back to your old code like that - I recently had a look at the Hunchy source code (my first game) and it was not a pretty sight!  I would probably be tempted to redo everything from scratch, rather than work through the issues.  I'm also amazed that you managed to pull it together in such a short time period.  I find that I always need a lot of "thinking time" between bouts of coding, just to figure out how best to tackle the problems.  I am still thinking about the falling-tiles problem in PoP while you have written an entire game!

Chris

Incidentally, I probably will post the final binaries sometime later this month, unless Al objects (and I don't think he will). Probably close to Christmas day. ;)

And yeah...some of that stuff was just plain ugly. The first half a week of coding was expanding the binary to 8K (later became 16K) and rewriting certain parts that were poorly written.

Speaking of Hunchy - before I started work on Reindeer Rescue, I spent an hour or two trying to hack Hunchy into a Frosty The Snowman game. :)

I didn't get too far; just far enough to run into a few problems and put it on hold. ;)
  • Report

I think you are rather brave to go back to your old code like that - I recently had a look at the Hunchy source code (my first game) and it was not a pretty sight!

The Strat-O-Gems kernel dates back to 1994. I added a couple of undefined opcodes to free up cycles to stick in some other stuff (probably not really needed) but I actually posted a copy awhile back.

When I did that kernel, I didn't understand how the divide-by modes of the RIOT worked; I'd figured I'd have to use cycle and scan-line counting to keep track of vertical position while doing all the game computations (which would have been an absolute nightmare!) so I dropped the project. I also deliberately made things off-center to get the timings right, which is odd since the timings work just fine with everything centered perfectly.
  • Report
Impressive that you wrote it in such a short time, Bob. I can hardly wait to play it.

Chris, Are you sure you don't want a copy? You won't get a chance later. I'm sure you can buy it with your royalties if you haven't spent them already. (It is offered alone for $25.)
  • Report
Yeah, c'mon Chris. You know you want a copy. :)
  • Report

Yeah, c'mon Chris. You know you want a copy. ;)


You guys are twisting my arm! I suppose I will just add it to the ever-increasing credit card bill and worry about it in the new year :)

Chris
  • Report

I suppose I will just add it to the ever-increasing credit card bill and worry about it in the new year :)


That's the holiday spirit! ;)
  • Report
Hi there!

Yeah, c'mon Chris. You know you want a copy. ;)

You guys are twisting my arm! I suppose I will just add it to the ever-increasing credit card bill and worry about it in the new year ;)


Maybe you want to ask Al if there are *cough* ...special conditions for homebrewers... :)

Greetings,
Manuel
  • Report
You're braver than me. When I enhanced Skeleton to Skeleton+ I tried to avoid even thinking about making changes to the kernel. (The kernel for Skeleton is also split into mutliple bands, although for different reasons.) I'm sure if I went back now I'd find all kinds of optimizations.

I also had similar issues with where to stick chunks of data when I enhanced Skeleton. You do interesting things when space gets tight.
  • Report

You're braver than me.  When I enhanced Skeleton to Skeleton+ I tried to avoid even thinking about making changes to the kernel.

The changes weren't completely necessary, but I think they made it a much better game. I'll make another entry today or tomorrow talking about the how the game works a little more.

I just today made the "final" bugfixes on the game - the routine to see if your score was a new high score was buggy, plus a few other minor things.
  • Report