Notebook

Updates on all of my latest game development

Making an Atari game – Day 24

My first (ugly) attempt at a title screen
My first (ugly) attempt at a title screen

I have played around with using the Title Screen Kernal however I found it just took up too much space that I wasn’t willing to give to it. I thought I would mention also that when I ran one of the example title screens from the kernal (The colour by flicker example with Yoshi), it really messed with the display on my MacBook. Even after I shutdown Stella, I could still see Yoshi burned into the screen of my Mac. This freaked me out quite a bit. I tried everything to get rid of it. Rebooted several times and nothing seemed to be working. Thought I really damaged my computer for a bit, but I think all it took was time? I shut the Mac down for a while and after a couple hours when I opened it back up, Yoshi was finally gone. Thank god for that, but the experience has kind of scared me away from color by flicker. So I decided to code my own simple title screen which I am really happy with how it turned out. Also created a little intro sequence for when the player starts the game, the player will walk over towards the entrance to the Catacomb and begin to walk inside it. Perfect.

The start of the title design
The start of the title design
The finished title screen
The finished title screen

Not a bad looking title screen for not using the title screen kernel, if I can toot my own horn for a moment lol. The number 1 on the screen there is the selection of game variations. I plan on having 3 but I’ll talk more about that later.

I also fixed a bug where the game would crash and reset on the actual 2600 hardware when the player entered the exit room with the ladder in it. It was caused by incorrectly using the “return” command with the draw player subroutine. Once I added the Title Screen intro sequence, this bug was born. This is when I changed the subroutine to execute a return command instead of a goto statement because I needed it to send the computer back to the title sequence when called instead of the main game loop as usual. This caused a nested return sequence that needed to be fixed. This bug could never be replicated during the emulation,  Stella seems a bit more forgiving with nested return commands.

Making an Atari game – Day 23

 I fixed a bug where the death smoke that appears when you kill a monster would actually hurt you if you the player walked into it. Kind of not really a bug, just something I didn’t take account for until now. This would suck and wouldn’t make sense. So now when the player collides with an enemy, it checks to see if the enemy is displaying it’s death cloud or not before it takes hit points away from the player.

Just a quick list of the other things I did today:

  • Rearanged enemy swarms (The order the enemies appear throughout the dungeon)
  • Wrote down appropriate enemy stats (Just in planning, not in actual code yet)
  • Took out random Dragon, made Dragon the Endboss. Found I wasn’t going to have room for both random Dragons and multiple Endbosses so I compromised and made the Dragon the Endboss.
  • Put the Dragon on floors 8, 16, 24, and 32
  • I changed how enemy speed works. Made it only increase by significant amount every 8 levels
  • I want to make an Ultra Sword that will allow you to shoot even when health is low

Making an Atari game – Day 22

It’s funny, everytime I plan on working on one thing, when I get into coding I end up working on something unrelated. I didn’t end up going near the Endboss code today. I always thought the game would be a little better if the dungeon had at least some locked doors and keys. This may sometimes force the player to backtrack through places he/she may have ran through or explore more of the floor they may have missed. I was thinking I wouldn’t have room for keys and locks but kind of thought of a better alternative tonight. I decided to make a locked cellar door, which would randomly appear on some floors where the ladder to the next floor should be. I then made a pulley switch that is placed somewhere else on the same floor. This Switch will swing either left or right, depending where it is when the player hits it. If the switch is pointing towards the right, then the locked cellar door will disappear, revealing the ladder. If the switch is pointing to the left then the door will be locked.

It’s kind of a basic but neat little system. I’ve never really coded a switch before in a game that when activated, it then effects something in a completely different room. Was kind of fun and simple, not much code required and in the long run I think it was a better solution to having keys.

I also placed the Princess on the 32nd floor (thinking that might be a good spot to end this game). Then I started to work on sound effects a bit. I added my first real in game sound, which is the sound effect that plays when a monster takes damage. Im not great with sound effects yet and don’t have a full understanding of it so this might take a bit of time and research if I want this game to sound half decent. Since this game will be a long one. I want to make sure that none of the sound effects will become annoying over time.

[Edit: Two hours later] – Okay, the sound effects don’t appear to be as difficult as I originally thought, thankfully. I took a quick look at some example source code and played with “The bB Music and Sound Data Creation Toy” on Random Terrain and just through some quick trial and error really, I managed to come up with roughly the kind of sounds I was picturing in my head for this. I wanted a Mario coin like sound. I think I came kind of close to that. I adjusted the enemy damage sound to be more satisfying when you hit them. Created a nice higher pitched sound for when you get an item like meat to gain health. Also got a new sound effect for when you pick up the two Swords. And lastly, I made a small little woosh sound for when you swing and miss with your sword. I’m pretty happy with that. Only other sounds I need to make is a sound effect when the player reaches a ladder and another one for when the player takes damage.

There doesn’t seem to be too much more to do on the coding side of this game.. All that I can see that is left is:

  • Create an EndBoss (possible multiple, if I can squeeze them in there?)
  • Create a nice (hopefully) bitmapped title screen (Game Over & Win screen if there is room)
  • Sit down and think of what monsters to keep, disregard, and replace. Also think about how I want to place them throughout all of the floors to keep a nice steady increasing challenge.
  • Oh also, that dragon I made.. I would like to do something with him. Maybe make him a bit smaller, or turn him into something else completely. Another flying creature, so he can fly through obstacles in the room and make a b-line straight for the player. I also want to give him 3 or more hitpoints to kill. Overall just make him work better and appear more throughout the dungeon.

And I think that is it on the coding front?? Of course I will have to go through and polish things where I can and add PAL support, or create a separate PAL file. But yeah. I feel like I’m on track to hitting my 30 Day goal. I’m soon going to have finished my first Atari 2600 video game! 😮 I’m beyond excited about this 😀

Making an Atari game – Day 21

I Worked on making the enemies move a little smoother and Fixed 2 bugs.

  • The 1st bug, the player would randomly lose a hitpoint when he/she walked into some rooms.

What was happening was when you walk into a room, the player is sent to the opposite side of the screen and the next room would be drawn. However, the enemy sprites weren’t relocated out of the way before the next drawscreen command. This would cause a collision with the player and the (seemingly invisible) enemy, and the player would lose a hitpoint.

  • 2nd Bug, The cloud of “smoke” would disappear waaaay too fast after you killed an enemy.

I have saved a separate file every time I make a major change to the code. Right now I am on file number 40. I didn’t notice when the enemy death animation broke, so I went back and found the last working version on file 15. The reason it broke was because of the way I draw multiple enemies by sharing sprites. Basically, once I added more than one enemy to the game, the death animation ended in a single frame (a blink of an eye). The reason is because when the program calls the death animation to be drawn, it draws it for the current dying enemy. But then the program calls the draw monsters routine, which draws all 3 monster sprites at once before the death animation was finished animating. This was replacing the enemy death animation because all 3 are sharing the same sprites. It was kind of complicated trying to fix this one but I eventually did and added in a bit more frames before the animation ended to make it last a little longer on the screen. Just enough time that it feels satisfying to me to kill a monster and see them disappear in a white cloud. I tend to obsessively play and adjust over and over until things feel just right to me.

I added Enemy tracking. Now I can pick and choose which enemies I would like to be more intelligent. If the Track Player variable is set to 1 on the enemy, then that enemy will constantly walk towards the player in the room. Makes the game a little more challenging when all three Monsters are attempting to swarm the player.

Designed a new EndBoss Lair that I am hoping to use for multiple EndBosses. Right now the lair sits on the seventh floor in the third room up. Then the princess is in the floor just below it. This will all change though, once I start play testing and try to design the actual game to be more fun and structured. Right now everything feels very random and out of place. It’s like I have all kinds of working pieces, they just aren’t all fitting in with each other nicely yet.

This whole project feels like putting together a large puzzle. It’s like a puzzle that you make and at the same time have to solve yourself. That is pretty much all it is. It’s a fun puzzle to put together for me, which will hopefully turn out to be a fun game for you.

Next I think I would really like to work on making an Endboss… I also need to get some sound effects going too. I have the driver all made and just kind of sitting there. Need to start experimenting with creating the sounds I want this game to have. I think that will make a huge difference in the feeling of this whole project.

It’s getting close to Christmas however, which leaves me with less free time to work on this. (Update: keep in mind, these are notes that I wrote while I was writing this game back in December of 2018)

Making an Atari game – Day 20

When I originally set out to do this project. I was thinking that it might take me around 30 days to complete. That was just a rough guess, not knowing anything about the Atari yet. Now I’m just sitting here by my girlfriend and just said to her that I can’t believe this is Day 20. Only 10 more days and I might actually make it.

Haha, kinda early to say cause anything can happen, but I am so far along now that I think I could actually have the code completed by then. That is really exciting.

Today I kind of took it easy and tinkered around with the code a bit, which was kind of a nice and relaxing night. Nothing too strenuous on the brain but very happy with what has been added.

So far I had a bunch of monsters coded into the game, different graphics and such. But if I played the game it would only ever show one of those monsters through every room and every floor. The one type of monster. If I wanted to see the other ones I would have to change a variable’s value in the code and then compile and run it again.

So tonight I finally got all the monster types roaming around the dungeon in a specific order. Some kind of look better/uglier than others but they are all there. I think I’m going to sit down next and kind of plan out what monster graphics I want to keep, which ones I should replace with something a little better, and what the best order of appearance should be for each one during gameplay.

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.