Notebook

Updates on all of my latest projects

Making an Atari game – Day 4 (and 5)

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.

Room with no exits (Bug)
Room with no exits (Bug)

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

Up, right, and down corridor

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 🙂

Making an Atari game – Day 3

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

Collision prevention
Buttery smooth collision prevention

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.

Making an Atari game – Day 2

Using my iPad to design sprites

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.

128 NTSC Colour Palette
104 PAL Colour Palette

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

First shot of in game player character
The player character in a corridor

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.

Making an Atari game – Day 1

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.

Day1 Progress shot
First thing I got the Atari to display with the Stella Emulator

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.

Walls with four doors
Four doors with variables

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.

The Atari Video Computer System / 2600

Atari Video Computer System / 2600
Atari Video Computer System / 2600

CPU: 6507 (modified 6502 microprocessor)
RAM: 128 Bytes
ROM: 4K max
CPU Clock: 1.19 MHz
Graphics Clock: 1.19 MHz

This is the Atari, this is my Atari. I still remember when I was maybe five or six years old, sitting on the floor in my neighbour’s basement, with video game cartridges spread out around the system. I was looking at which one I should try, and I seen it. The amazing artwork for Yar’s Revenge caught my eye. I threw it in and thought the game was incredible. You actually got to be that robotic fly that was depicted on the cartridge art. I loved every second of it and I wanted to make my own.

But who knew how to make one? Who could show me? I asked my older brother how video games were made. He told me they were programmed with complicated computer code. Well, we had a computer… A Commodore 64C.. I asked him if he knew how to make one? No.. Did he know anyone who knew how to program? He said he would ask his teacher at school, Mr. Williams, he was pretty sure he knew at least something about programming. However, that was to no avail. This was a time before the internet. It wasn’t as simple as googling “How to make a game”. Those were very different times.

I obsessed over this, I really wanted to make a game. I remember sitting in class, drawing out different game ideas, and game levels. I had a little Atari catalog with the game Adventure in it. I never played that game at the time but the artwork, screenshot, and marketing description had me hooked. I sat down with a pencil and paper and drew up what I imagined that game could be, or what I would make that game.

Now let’s jump ahead to September 10th 2018. I was programming my dream game, an RPG on my Mac (which will probably take years to finish) when I happened to come across AtariAge.com. I saw all these homebrew games being made and sold for the old system. I began feeling nostalgic and started thinking back about how badly I wanted to have my own cartridge as a kid. I thought how cool it would be to actually do it now. Now that I have the ability and resources to do so. How psyched my five year old self would be if I could go back in time and tell him, you did it dude, you made one!

So I decided to put down the RPG for a moment and attempt to create my first Atari game. I set a goal to learn and code the game in 30 days. I wasn’t sure if this was even achievable but it was something to strive for.

I found the RandomTerrain.com site, which had a ton of good information on batari Basic. A high-level programming language that was developed for the Atari. This would make it a bit quicker and easier to reach this 30 day goal. I figured I could design most of the game in batari and anything I couldn’t accomplish in this language I could just do in 6502 assembly.

I work 12 hour night shifts, so I don’t have a lot of free time to spend on this project. I tended to spend 12 hours on any day off I could spare within the next six months on this project.

Each day I would write a journal of what I had accomplished that night to keep track of my goals. I wasn’t really sure if I was ever going to share this journal but since I did finally complete a game I thought I would go ahead and post them as I work on developing the artwork for the cartridge label, game box, and manual.

The game I decided to attempt to create is a Rogue-lite, Randomly Generated Dungeon Crawl, Hack and Slash, Adventure game. This game is called Deepstone Catacomb and starting tomorrow morning, I will post Day 1 on this daily blog of my development process.