Notebook

Updates on all of my latest projects

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.

Making an Atari game – Day 11

Two monsters
Two monsters

I added one extra monster to the room. So there are now two walking around, bumping into things, however I had found that the game would slow to a crawl if I had them both moving at the same time. After a lot of messing around and thinking about how to handle this I had decided maybe to make them take turns from walking and standing in place. So when Monster 1 is walking around randomly, Monster 2 is standing still and vice versa. This works and brought the speed back. Admittedly it’s a solution, but maybe not the “best” solution. I need to think of a better way if I want to also have more than two monsters in a room. I thought maybe to make it a bit more challenging, I could have the monsters shoot at the player while they are not moving around. I don’t know, we’ll see. I would really like it if all monsters in the room were walking around at all times.

Making an Atari game – Day 10

Last night I had a dream about how I should be coding the part of the engine that handles all of the enemies in the game. After waking up and thinking about it, I thought it was actually a good idea. That has never happened before. So I spent some of the day implementing it and adjusting where in the code the enemy movements are handled. I had them in the Main Game loop in Bank 3 but was quickly running out of space in that bank. So I shifted them all over into Bank 5, which is the same bank that handles the part of the code that places the enemies in the rooms when you first enter them (Enemy spawn code). So it kind of makes more sense to have this there and have the code more organized.

I also put in place holders for enemy characteristics… Basically, variables that I can adjust later for each enemy that will determine whether they just walk randomly, chase the player, have multiple hit points, and whether they have a weapon to attack with. I also added the code that allows the player to hit the enemy, take a hitpoint away from him/her, and animate the enemy getting hit and/or dying. I originally thought the animation was only going to be temporary just to test it out but I ended up liking it on the first go. It was a lot of fun to kill the enemies over and over and see their flashing/disappearing animation. So I guess I’m going to just keep it as is.

Next I think I might start adding multiple enemies per room instead of just the one? I’m hoping to have at least 3 if the variables will be available for it.

Harmony Cartridge

Harmony Cartridge
Harmony Cartridge

The Harmony cartridge came in and I got to play test my game on an actual Atari 2600 System!! On T.V.! I didn’t do any coding today but wanted to write about playing. My girlfriend and I took turns “playing” my prototype. Even though there is not much actual gameplay yet, this was a blast! And a big step into achieving this little dream of mine. Seeing my creation on T.V. although not yet finished has been something I have always wanted to do since I was a kid and first played an Atari system. I remember playing Yar’s Revenge in my neighbours basement. The cover art on the cartridge is what sucked me in and got me to try it out. It was amazing. The fun we had playing that little game, I knew instantly that I wanted to make my own. I didn’t think it could be too hard. I use to draw out my own video game maps at recess on paper as a kid.

First time playing my game on a television

Now this many years later and finally being able to see my little project come to life on an actual Atari system on an actual television. I have to say, it felt really really good and has me excited and motivated even more to complete this. The finish line is in sight. 😁

Making an Atari game – Day 9

I managed to add the collision detection into the first (and so far only) monster in the room. At first I tried to give him the same collision prevention/detection that I gave the player but found the code was too large and I was running out of space on that bank. This would mean less monsters (maybe only one) in the current room. That would suck. So I scrapped that code and started fresh.

I gave the monster more of a collision detection and then snap back code. It isn’t as pretty but I might be able to tweak it later to have it unnoticeable or looking smooth. I’m not sure what the collision detection is going to be like when I put more than one monster in the room because the other sprites will be virtual sprites… I’ve been reading that when a collision happens to the original sprite, the Atari won’t recognize the collisions on the other virtual sprites. The highest sprite on the screen is the only one that can detect it’s collision at any given time. So I’ll have to code around this limitation. The AI might have to be coded around this.

Another thing I decided was important to code was to make sure whichever door that the player has entered in the room, that a monster does not spawn right in front of the player. So far the monster could spawn anywhere in the room (even walls). But when playing I found it natural to just charge into a room, so it would be frustrating if monsters would spawn right in front of the doorway every now and then and instantly take some health from you without giving you some time to react. Now they will spawn at least 24 pixels ahead of the player or further.

The one thing I am trying hard to avoid is Flicker. The Atari is only capable of drawing two sprites on a horizontal line on the screen. Player0, which is the Player character and Player1, which would be the first monster in this case. If any other virtual sprite (which is a copy of Player1, the Monster) crosses the same horizontal line on the screen as these sprites, then the sprites must take turns being drawn each frame. This causes the flicker look in a lot of Atari games. Most notably, Atari’s version of Pacman. I would like to avoid this from happening as much as possible.

However I did find a flicker bug. The only monster in the room would flicker but only on any floor lower down than the 3rd floor. Come to find out I put some “place holder” code in for the other monsters in the room which would appear after floor 3, that I forgot about. These monsters don’t have graphics yet, so they were being placed in the room without me knowing they were there lol. This would cause the only monster to flicker in that room as he walked past the invisible (Ghost) monsters. I was really confused by this until I found my placeholder code for monsters 2 and 3. Pretty dumb mistake. But hey, it’s working now and so far no flicker! 

Making an Atari game – Day 8

First monster placement
First monster placement

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!