Notebook

Updates on all of my latest projects

Making an Atari game – Day 19

I managed to free up even more space today by changing how I placed monsters in a room. This should hopefully give me the space needed to create an endboss.

The "Master Sword"
The “Master Sword”

Once I cleaned that code up I started work on adding the “Master Sword”. This is what I decided on turning the spear into that I talked about earlier. I created the pixel art for it and decided to place it somewhere on the early floors for now. I also gave it a new room to sit in. I find it makes it feel a lot more important than how I originally had it where it was just lying on the floor in any random hallway. 

Once I placed the sword in the game I figured I should put the Win Game princess in there somewhere. Since the game really needs to be beatable, I figured I shouldn’t save the princess for last or I might end up running out of space somewhere. For now the princess is sitting in a copy of the “Master Sword” room. But if by the time I am finished this and there is enough room I may create a different one for her.

As of right now, it just takes damage off the player when he touches the princess lol. This is because she is just a copy of an enemy sprite. But it does check for collision and for now I am going to leave it where it is. I am hoping I’ll be able to add a win game graphic in bank 2 along with the title screen and game over screen. I’m really not sure how much space those full screen graphics will take up. So again, I guess I just have to wait and see. 

Making an Atari game – Day 18

Tracking magic missile
Tracking magic missile

Now I was thinking about how in Yar’s Revenge there is a little tractor beam/missile like object that follows you around the screen at a very slow crawl as you are trying to take out the main enemy. I always found that dynamic fun, and since it might be too tight to try and have separate types of monsters in the same room together, I didn’t think it would be all that hard to have a tracking missile object in some of the rooms. Which it wasn’t really. It was a pretty easy add to the game and made a huge difference in how fun it is.

Since the beginning I wanted to have trap rooms, where all the doors will close once the player enters the room. This proved to be rather difficult. It’s kind of a long story but I was using the pfpixel command to turn the pixels on and off to open and close the doors. However, for all four doors, that required 24 pfpixel commands, which ate away far too many cycles. I could put a drawscreen command in between drawing the doors, but that made entering a room very ugly. So I went on a search online for a quicker way to draw pixels to the screen. I originally thought I could just change the bits in the variables for the Playfield but that proved to be futile. Then I found the pfhline (Playfield horizontal line) and pfvline (Playfield vertical line) commands. I’ve seen these before but didn’t think to even try them at first because I couldn’t see how drawing a horizontal or vertical line would be any quicker than just changing the pixels. I was wrong. It’s a lot faster and takes a lot less space. What took 24 lines only takes 8 lines now. 

So now I have trap rooms plus more space for something extra later in that bank. The trap rooms will close all doors when you enter a room if there are monsters in it. Once you kill the monsters and collect the treasure, then the doors will open again. Works very much like how Zelda’s dungeon rooms do it. That’s kinda what I was going for.

Adding the Tracking missile and the trap rooms made a pretty big difference in how interesting this game/dungeon feels.

Making an Atari game – Day 17

It's dangerous to go alone! Take this.
It’s dangerous to go alone! Take this.

I Added a sword on the ground in the first room that the player must pick up before he/she is able to attack anything

I Added two new item drops. A chicken leg that will restore health to 100% and a Mario like mushroom that will give the player an extra life

Ugly brown beast
Ugly brown beast

I Added more monster types (graphics). Two scorpions (red and blue), two “beasts” (brown and purple), two more “mummies” (now there is blue, green, and black). This has filled that bank full. I may change some of these monsters later, I don’t really like the beast graphics. Might turn them into bats. I would also like to add a dragon that actually chases the player if there is enough space later. Was thinking about using bank 2 (which holds the sound effects and title screens) for more monster graphics if there is any space in there left over.

Right now I need to work on monster speeds. Whenever I increase the speed of the monster movement (for deeper levels in the dungeon) they will sometimes overlap a wall by a couple pixels. They don’t get stuck or anything, it just looks kind of ugly to me. I need to adjust the collision detection to match the movement speed. Which is a bit confusing with fixed point integers. But that’s where I’m going to try to throw most of my effort at next.

I have so many plans for feature I want to add, like all Atari programmers, but am struggling for free space and variables at every turn. I am really hoping there will be enough room for multiple (with palette switching) end bosses or at least one. I would also like to add a random treasure room. But have a feeling that will be a little much. I think I am going to have to make a list of priorities of features and start working my way down because I know a lot of them will not make the cut. The most important on that list will be a princess to save. So once I figure out the monster speed/collision problem, I should really make sure to add a princess at the bottom floor to win the game.

Making an Atari game – Day 16

I added a rudimentary sound driver after reading the Random Terrain information on it. Not too bad, it works so far. Just need to check it on the real system to make sure everything still runs smoothly.

I went around the code a bit and polished things up some. Made the score gradually scroll up when you get points rather than just showing the new score instantly. Just more fun to display it that way.

Starting room
Starting room

In the entire game, I was using a total of 5 sprites and using the rest as extra variables. I wanted to free up some variables so I decided to eliminate the 5th sprite, and have it interchangeable with sprite 4 instead. Sprite 4 was always just the dungeon/floor entrance sprite (kind of a cross in a circle, shown above). Sprite 5 was always a ladder to go down a floor. Since they were both never being used at the same time anyway, now I just switch sprite 4 back and forth between the entrance and exit when needed. This gives me four more extra variables that I can use for whatever: player5x, player5y, NUSIZ5, player5height.

I think I already have a plan for 3 of them. I think I am going to use them as item drop labels. So when you clear a room, instead of just coins appearing for each monster killed, sometimes more items will be dropped, like something for increasing health, stronger sword, or an extra life. 

Making an Atari game – Day 15

The monsters can now shoot. This wasn’t too difficult to implement either. They use the “ball” sprite in the Atari for the bullets. Only one can appear on the screen at any given time (unless I allow flicker), so only one monster can shoot at a time. However one thing I may have to account for later is that sometimes when the player enters a room, if the monster happens to appear kind of in front of the player and looking in his direction, he will shoot at him instantly. This would feel very unfair in the game. So to counter this I think I may add a clock variable later to the game which keeps ticking every frame kind of behind the scenes. Then when you enter a room, all the monsters will check the clock and if 2 or 3 seconds have gone by since the player first entered the room then (and only until then) they are allowed to fire at the player. 

Collecting animating coins
Collecting animating coins

I have added coins in the dungeon to collect. Once you clear a room of monsters, coins will be randomly placed for the player to collect. What I originally planned was once you killed all the monsters, the coins would appear in the middle of the room. Not moving or anything, just sitting there. But something kind of unexpected happened. Because I am basically using the monster sprites and turning them into coins, I forgot to turn the monster movement off. So when I tested the code out and killed all the monsters in the room, all the coins randomly appeared but also started moving randomly around the room. They were using the Monster’s walking code and I kind of liked it. It made it a bit more fun to chase after the coins that were sliding around. So I kept that “bug”. To make it a tad bit more interesting, I may also have them disappear after a given amount of seconds when I add that clock variable. This way the player kind of has to be quick in collecting the coins. I am running dangerously low on variables at this point. Im probably going to have to look for ways of reusing some in “smart” ways in order to finish this project.

Another bug found that I decided to remove was, since the coins behaved like monsters, they also shot at the player. This was obviously ridiculous and easy to fix but funny to find.

At this point Im starting to get excited about sound effects. So far this game has been very very silent. But collecting the coins kind of triggered my brain to the need of high pitched sound effect. I want it to sound fun to collect the coins like the sound in a Mario game. So I looked up the sound effect for coin collecting in Mario on YouTube and then I opened up an Atari sound emulator in my browser and played around with it until I found something similar to see if it can be done. It’s close enough to my liking. Still Not in the game yet, but just wanted to make sure that kind of sound was possible on this system.

I’m a little worried about the sound code. With the Atari I basically have to code my own sound driver. This is something I know nothing about, I’m not sure how many variables it will take and I’m down to my last few. I’m really hoping it won’t be too difficult. I only have one bank left that is virtually unused, which I kind of always planned to use for the sound driver and title screen/menu and ending/winning screen. That “should” be enough space for all of that. Just hoping that when I call another bank for the sound effects it doesn’t go over my 262 cycle count.

Making an Atari game – Day 14

I’ve been noticing a glitch that the monsters would show their death graphic when entering a room for a split second if the player just killed that exact corresponding monster in the last room that he or she was in. This was a simple fix. I just made all the monsters appear completely black when the player first enters the room for a single frame before the bank is called to draw what the monsters are actually suppose to look like. (Update: This was a sloppy way to “fix” this, I did it the right way later)

player in a corridor with a monster

I was running out of space again so I readjusted alot of code into different banks and changed different bank calls. I also got rid of a very bad screen jump/flicker bug. It always ran smooth in the Stella emulator, but if I ran the game on actual Atari 2600 hardware, sometimes the whole screen would jump around when entering a new room. The reason for this was I was sometimes going over my 262 cycle limit. Say the player walked up into a door to the North, but was also entering it diagonally by going North-East. This would run a bit more code then it normally would to walk through a door because it was running the collision detection for the North and for the East as the player was also walking through the door and loading the next room. Just that little bit of extra code was too much for the Atari and would cause the screen to jump a bit. This was very ugly and bothered me a lot. I really wanted to fix it for a while now but everything I tried wasn’t working and seemed like it might not be possible. What I ended up doing was made the code check the player’s x and y position when near a doorway, and if it was just a couple pixels from the door then it would ignore the diagonal code and just go straight through the door. This saved cycles by avoiding cycle heavy collision detection that was not necessary when traveling through a doorway.

One thing I am really pleased and excited about is I added a running ability to the player. I haven’t decided yet if the player will always be able to run or maybe have a hidden item like Boots or some type of suit that will allow him to move a lot quicker. For now though you have the ability from the start. If you hold in the fire button for two seconds the player will begin to run until you let go of the fire button. This was a bit more complicated then it sounds. I had to learn about 4.4 and 8.8 fixed point integers on the Random Terrain website and adjust how the player’s overall movement and collision detection worked so that they would work properly with the fixed point integers. When I switched to the fixed point to handle movement, the collision detection hit the bucket because the numbers were no longer solid integers anymore, they were floats. But now that I got that figured out, the game I find is a lot more fun to play and it will make it easier and quicker to run through rooms that the player has already cleared.

Now that I have complete understanding of Fixed point integers, I need to go into how the monster movement and collision works and implement the fixed point in there. This will allow me to have much more precision on monster’s speeds the deeper the player goes down the dungeon. This will make the game much more challenging and fun as the player gets better at the game mechanics.

I’ve worked on this game for about 14 days now, teaching myself how to code for Atari and writing the game as I go along. Each day I usually spent around 12 hours of researching and coding. So according to that I have spent about 168 hours on this game so far! That doesn’t actually sound half bad to me, considering I can see the finish line over the horizon. Very exciting stuff 🙂

Making an Atari game – Day 13

Graph paper dungeon
My graph paper dungeon guide

In order to fix the monster spawning code I decided to draw out the dungeon room on graph paper to make it a lot easier for me to visualize and know the exact pixels of where a monster should and shouldn’t appear randomly in any given room.

Seeing my dungeon drawn out on graph paper really brings me back…

Now the monsters shouldn’t ever spawn on a wall at all anymore. I changed the way the spawning was handled completely so now the Atari checks which room type the player has entered and calls a corresponding spawning subroutine for that specific type of room.

I also added code to allow the player to kill all the monsters in the room, it was quick and sloppy code for now that I will probably come back to next time and clean it up a bit to save some space. But just to test it out, it’s actually starting to feel a bit more game like and is really fun running through all the rooms and killing all the monsters.

I’ve been running out of space in many banks at once and am worried how I am going to pull off creating more than one monster with different behaviours. Things are getting tight and I am hoping I can come up with a way of rearranging things in separate banks yet again.

Making an Atari game – Day 12 – Let there be three!

Three monsters per room!!
Three monsters per room!!

I did some rearranging of the code that handles the monsters again. Made it a lot more logical and organized. I also added Three monsters to a room! That was exciting. Also, I managed to make it so they didn’t take turns walking around!!! Now they all move around at all times and it’s smooth! It’s kind of a cool work around to how I was trying to do it before. The main game looping code before was trying to handle the movements and collision detection of all the monsters, all at once. This caused things to slow to a crawl. What I decided to do was actually still make them take turns in a way but a lot faster way of doing it so that it is unnoticeable to the player.

What I decided to do was count the frames that are drawn each second. So during the first frame I would handle Monster 1, the second frame I would handle Monster 2, and the third frame I would handle Monster 3. This happens at a blink of an eye when the game runs at 60 frames per second. So when you are playing, it really does appear that each monster is moving at the exact same time at a good speed.

Also, I really want this game to look polished and professional as possible. I want it to be as pleasing to the eye as the Atari will allow it to be (and that I am capable of). So that means NO FLICKER. I really don’t want to have flicker in my game. I remember finding the flicker kind of distracting as a kid and back then I didn’t really know what it was. Kinda made objects look somewhat ghost like.

So in order to prevent flicker from occurring on the sprites, I decided to write some code in that would stop the monsters from crossing each other’s horizontal path line. They all move at random and are free to move anywhere in the room as they please, but now they will just turn around instead of crossing each other when moving up and down. This actually worked out very well. I really like how clean it looks now without all that flicker. The gameplay shouldn’t be harmed as well, and might even keep the monsters spaced out a bit in the room more often, which would have them guarding more room space. This should work out to the game’s advantage.

Another thing I decided to do, because after adding all three monsters to the room, it was making some horrible collision glitches. So I rewrote the collision detection, yet again. (All these rewrites are learning experiences, a great way to learn. Trial and error!) The monsters were often getting stuck in walls and blocks in the room. So I figured out a pretty good way of giving them the same smooth collision prevention as I gave the player. This should eliminate all collision glitches and sticky walls that the monsters were experiencing.

The last thing I managed to do today isn’t as exciting as the rest but what I definitely spent the most time on, was reducing the amount of cycles the game would run at. On an NTSC television, I only have 262 cycles to play with and I noticed I was going over that limit every now and then. Mostly during the dungeon maze generation process and whenever the player would move from one room to another. This would cause the cycles to jump. I’ll spare you with the many hours of boring detail here but so far I seemed to have fixed this. Mostly by eliminating how many calls I was making to randomly generate a number. That must use up a ton of cycles, since I read on the Random Terrain site that it should only ever be called once per loop if possible. I was doing it all over the place. Too many cycles can cause things as serious as the game crashing, or as annoying as making the screen jump around very jaggedly. So I have it solved for now but as I add more code, I can see how this will always be something I will be battling from here on out as things get more complicated. 

But over all, Three Monsters are in a room! Thats the big step and I think it looks great. I did try four but I feel like that was pushing it, because of how much detail I want to code into each monster, space limitations, and frame rates. I don’t think I really need any more than three at a time really for a game like this. The rooms are small enough that three can give the player a challenge, and when magic missiles eventually gets coded in, then there will be all kinds of things the player will have to keep an eye on and dodge around the dungeon.

Good stuff. Next I plan on adjusting the monster spawning code to make it more polished and fix some of the glitches I have seen there.