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.