Atari 2600

Alright, I’m exhausted. I want to keep coding but my brain isn’t working anymore. Still having a hard time switching my sleep over. I spent a lot of time just sitting and thinking today about how I want to go about handling the monsters, their graphics, movement, behaviours, and where/when they should pop up. I think I have a good idea how to go about it. I’m really running out of variables to work with so Im trying to be careful with this.

Since I’m so tired, I’m putting the code up for today a bit sooner than I would normally. But as of right now one monster does appear in the rooms that he is suppose to appear in. He also starts walking in one direction (forever) looping from one side of the screen to the other. Walking straight through walls because I haven’t coded the collision detection for him yet. But this is a good start. Kind of an ugly place to leave the code, but I really can’t function anymore tonight lol. I got to get some sleep and maybe try again tomorrow night.

~Zombie out, Peace!

About a week ago I ordered the Harmony Cartridge from AtariAge so I can test my game out on actual hardware as I develop it. This is important because Atari emulation software is great but will be very forgiving to your code and tends to run your game a lot more smoothly than the actual system itself. So If I want to make an actual cartridge of this game, the Harmony Cartridge is a necessity for testing. However I did order the wrong one by accident :/ I purchased the original when I think I probably should have got the Harmony Encore.. I haven’t tested the original yet (because the Atari 2600 that I purchased on eBay hasn’t arrived) but I think since I am developing this game with the DPC+ kernel, I need the extra capabilities of the Encore cartridge for it to work correctly. (Update: I was wrong, you don’t need Encore for DPC+) So I went ahead and ordered that one as well just in case. I really want to be able to test this game as I go during my vacation. I don’t want to go too deep in code and realize later that I have to rewrite a bunch of it.

I successfully added a four directional sword in the game, much akin to the original Legend of Zelda for the NES. The Battle system will work the same way, where you can “fire” your sword ahead of you either up, down, left, or right. But not diagonally. However I also coded what I’ll call a Spear for now. This fires out of the player almost across the screen or until it hits a wall. This weapon can fire in all 8 Directions, so it is much better than the Sword that the player will start out with.

I’m not sure what I am going to do with the Spear in the game.. I might make it a separate item that you have to find and pick up along the way or just make you shoot your weapon when you have full health. Kind of like the Master Sword in Zelda. I’m not really sure yet. We’ll see when I start adding monsters.

As for the monsters, I think they are my next step. I just managed to shrink a bit more code in my Random Dungeon Generator bank, which gave me just enough room to add some random monster placement routines. So far, zero monsters will show up since I haven’t coded any, but at least now the Atari is setting placements in the dungeon for them. It understand where I want them.

I’m now on vacation, took a month off. I am dedicating the first two weeks of my vacation on both this project and trying to switch my sleep schedule over to sleeping at night. I’ve been a night shift worker for about 10 years now and find it extremely difficult to get my body use to sleeping at night and staying awake during the day. This first day I crashed around 4pm and my body woke me up around midnight, telling me I should start my day now. Makes for a good time to code however. There is something extremely relaxing about being alone with no distractions and coding until the sun comes up in the morning.

So, it was a productive night. Not a lot to say for this entry but everything went mostly smoothly. Only ran into one small bug but managed to crush it pretty quick. Tonight was all about expanding the dungeon. I made the graphic for the stairs and wrote the code to randomly place the stairs on the opposite side of the dungeon that the player began at. Also used a variable to keep track of the floor level the player is on and changed the dungeon colours of the walls as the player descends deeper.

I did notice that the randomness of the dungeons was quite bad. Almost each time I ran the game the dungeons would be very similar. Come to find out that the Atari is very poor at generating a random number by default. So, as suggested online, I just used a mix of multiplication and division with the default rand command to generate a more random number. The dungeons seem to be much more to my liking now.

The random dungeon generation code exists entirely in it’s own bank.. After “perfecting” it, I pretty much ran out of space in that bank. I went from 3923 bytes to 2 bytes remaining… This was not good because I had planned for more routines in this bank. So I went through the code and cleaned things up. With a trial and error method, I had discovered ways of shaving down the code and freeing up a couple hundred bytes! This is something I need to get good at if I hope to complete this rather large project.

As for the bug, I noticed that every time you got to the 13th floor (Coincidently unlucky 13), the player graphic would behave strangely. The left and right animation graphics would kind of flip back and forth and there seemed to be an unpredictable room jump when ever you walked through a doorway on that floor. It was a very random weird bug, but was easy to reproduce. Just had to get to the 13th floor. Every time, without fail, there it was.

I had a feeling it had something to do with how I was handling the bank switching and variables. But after I did a quick search online about variable handling in batari, it said something about strange things happening if there are too many nested subroutines in the code. Sure enough, that’s what it was. I went through my code, got rid of the nested subroutines and bam! The bug was gone.

As it stands I can basically make this dungeon as deep as I want. Each floor is randomly generated over the data of the previous floor as the player enters it. This means the player will not be able to return to the previous floor (because it no longer exists) but also frees me to create a very large dungeon (Basically infinite). The way I will build the game will make it really unnecessary to return to the last floor, so this isn’t a big sacrifice. I kind of want this to be a longish game, with a clear ending for an Atari game. So I will decide for sure how deep the dungeon should go once all the gameplay mechanics are built in and I give it a run-through. But I’m thinking a floor number like 32,48, or 64.. Just because.. You know, those numbers, computer nerd. Feels right. But literally the floors could go on forever if I wanted them too.

Found the Easter Egg! Was kind of tricky, even following tutorials online. Those Duck Dragons gave us a challenge. But we finally got to see it on skill level 3.

If you haven’t, I highly suggest looking up interviews of Warren Robinett on YouTube… While you’re at it, David Crane and Howard Scott Warshaw as well. Hours and hours of stuff on there.

I can’t believe it! I’ve had the worst bug I have ever dealt with in my code. Just spent roughly 24 hours (12 hours each day) trying to figure out what went wrong and of course it was something really stupid that I just kept looking over. 😐

First, I decided on a way I wanted to code the random dungeon generator. Something very simple that wouldn’t take too many cycles for the Atari to handle. I remember reading once a long time ago how Richard Garriott (Lord British, creator of the Ultima series) wrote the random dungeon generator for his first release Akalabeth on the Apple II. I decided that was the way to go because it wouldn’t take that many loops of randomly generating numbers. So basically, every floor is a set of Rooms (or corridors which are basically the same as Rooms with narrow walls). This makes up a 4×4 grid. The game will choose a location for the player to start along either the top, left, right, or bottom, edge of the map. Then it will place the exit (a ladder down to the next floor) on the opposite side of the maze.

Once I randomly generated the data I needed for the layout of the floor, I had to start connecting the rooms and corridors with doorways, in order to test out the code. This was simple enough. If the player was going far enough to right side of the screen, there must be a doorway there, so change the X and Y location of the player’s current corresponding room and then change the player’s X location to the other side of the screen. Do the same for the top and bottom of the screen, only adjusting the Y locations, and bam. Just had to adjust the number a bit so the doorways weren’t too picky and pixel perfect on how far in the player had to walk into them to enter the next room. I really want this games movement to be smooth and feel right. So far I’m very happy with the collision detections and how the player feels as he walks and animates around the rooms. Moving room to room now works.

However, after a few tests I notice “the bug”. This was brutal trying to solve, I can’t stress that enough, lol. To try to explain the bug: Basically the map layout is a 4×4 grid right? So 0 to 3 for the x values and 0 to 3 for the y values. Well, I noticed that if there ended up being a room at the 1,1 location or a room at the 1,3 location, they would have a room exit off the map, which would send the player to a room with no exits if he walked into it. Also, depending on what direction the player entered the room, this would seem to change where the exits would be placed in the room. I went through all of the code with (what I thought) was a fine toothed comb trying to see where the numbers didn’t add up. I got to the point where I thought there must be a bug in Stella. I actually thought for a second that it couldn’t be me, Stella must be doing something wrong! lol… Nope.. For 24 hours over the span of two days, I adjusted things, tested it. Adjusted something else, tested it. Pulled my hair out etc… Then it came to me when I was starring at the code that decides what rooms/corridors to choose… There wasn’t something that was written wrong in the code, there was something missing from the code completely! When designing all the corridors, I forgot when there is two exits in a corridor, there is more possible direction of exits than just up and down, or left and right….

There is also, up and left, or up and right, or down and left, or down and right. So there were 6 possibilities in a random maze for the required corridor for any given location and I only coded two of them. So when the player entered a room that didn’t exist in code, the Atari had just drawn the last room the player came from. That room would usually have a doorway that shouldn’t exist. The doorway would then lead the player off the map.

Man did it feel good to finally figure that out. I can’t begin to explain how good that felt to finally get. The code is “perfect” now and I can move on to the next bit. But to celebrate, I’m going to relax with my girlfriend and maybe we’ll try and find the easter egg in the Atari game Adventure (Something I’ve never done myself). Should be fun 🙂

So I decided to take out the wall smashing code for now and work on the collision detection which has been bothering me. Remember that quick and dirty fix I did on Day 1? Well, I don’t like it. It’s just messy and not right.

I did a search online and found someone talking about collision ‘prevention’ on the AtariAge Forums. I never thought of this. This seems like it would be a lot better system. It might take up a bit more resources but should be worth it.

The difference between the two is that with collision ‘detection’ code, the collision with the wall has to happen and then you have to take the steps and send the player back to where he was before he collided with the wall. This was kind of glitchy, just knocking back the player. I mean it would kind of work but the player would stick to the walls at times, gave the walls kind of a sticky feel to them which isn’t very fun.

With collision prevention however, you just check a pixel ahead of the player in whatever direction it is heading. If there is a solid pixel (wall) there then don’t allow the player to move in that direction anymore. Sounds stupid simple and easy… However it took me all night to get it right. Trying to figure out where the Atari was placing the x and y location of my player sprite and checking all four corners of the player to make sure it could slide in between an 8 pixel wide opening. It was a lot of frustrating debugging… but….

I finally did it! Buttery smooth collision prevention! You can move that player all over the game world now, bumping into walls and gliding along side them and slipping through small openings, exactly how the player would expect it to behave. It feels so much cleaner, smooth, and fun. Really happy I decided to take the time to do this.

Next I think I might start working on what I originally planned to work on tonight. Making a random generated dungeon with multiple floors… I have an idea on how I should be able to pull this off.

I updated/upgraded the player character in a lot of ways. I got rid of the stupid smiley face temporary graphic I was using and messed around with drawing out plans for how I want the characters to look on my iPad. Of course there are a ton of limits when it comes to creating the graphics on the Atari. For one, you can only have one colour per horizontal line of the sprite. The black pixels you see above are transparent and will show whatever the current background colour is in the game. Also the player character can only be 8 pixels wide. It can have a height as large as I’d like though but I decided to keep that at 8 pixels as well, so all the characters in this game will have a uniform clean look to them. It just seems like they would fit better as a perfect square in this grid like world I’m attempting to create.

One thing I do find is Atari did have an impressive colour palette to work with for the time. 128 colours for NTSC shown above, and 104 for PAL

I also coded the animations and views of the player character from all sides. He now faces in the direction he is walking! I decided it would also be cool if he had the ability to bust down some walls inside the rooms. So I also managed to code that after a lot of trial and error. I am really happy with how it turned out though.

I really didn’t know how difficult this would be. I thought this would be a quick and easy little side project but man was I wrong. The Atari 2600 is a very challenging system to code for. You wouldn’t think so but there is so much to learn. You really need to know the ins and outs of the hardware in order to write the code for it. It’s a very quirky system to say the least.

That being said I think it was quite a productive first night of learning. I’ve been reading, coding, rereading what I just read, recoding what I just wrote, deleting, starting over, and finally within the last 2 hours of this 12 hour codespree I feel like I am getting the hang of it… Knock on wood.

I’m hoping to create a dungeon crawling, kind of a very lite Zelda type game. So far I have figure out how to create the first room, load it with walls. I’ve created variables that I can change on and off to create a door on each of the walls, if I want an opening in that direction or not. I’ll be able to use those variables later if I have enough space to create a map of the dungeon.

I also got some half-decent collision detection on my little smiley face player character. Might have to do some more tinkering there though to get it perfect. I had trouble with him getting kind of stuck along the side walls but kinda came up with a quick and dirty fix. However he still gets stuck on the middle obstical/wall things a little bit. It’s not easy. There isn’t a lot of space to work with on this old ancient legendary system.

Learning all of this gives me a lot more respect for the guys back in the 70s and 80s who single handedly developed for this system, in assembly! And managed to push the system to crazy heights beyond what it was really made for.