Atari 2600

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. 

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.

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)

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 🙂

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.

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.

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.

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.

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.

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

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!