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!
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.
About a week ago I ordered the Harmony Cartridge from AtariAge so I can test my game out on actual hardware as I develop it. This is important because Atari emulation software is great but will be very forgiving to your code and tends to run your game a lot more smoothly than the actual system itself. So If I want to make an actual cartridge of this game, the Harmony Cartridge is a necessity for testing. However I did order the wrong one by accident :/ I purchased the original when I think I probably should have got the Harmony Encore.. I haven’t tested the original yet (because the Atari 2600 that I purchased on eBay hasn’t arrived) but I think since I am developing this game with the DPC+ kernel, I need the extra capabilities of the Encore cartridge for it to work correctly. (Update: I was wrong, you don’t need Encore for DPC+) So I went ahead and ordered that one as well just in case. I really want to be able to test this game as I go during my vacation. I don’t want to go too deep in code and realize later that I have to rewrite a bunch of it.
I successfully added a four directional sword in the game, much akin to the original Legend of Zelda for the NES. The Battle system will work the same way, where you can “fire” your sword ahead of you either up, down, left, or right. But not diagonally. However I also coded what I’ll call a Spear for now. This fires out of the player almost across the screen or until it hits a wall. This weapon can fire in all 8 Directions, so it is much better than the Sword that the player will start out with.
I’m not sure what I am going to do with the Spear in the game.. I might make it a separate item that you have to find and pick up along the way or just make you shoot your weapon when you have full health. Kind of like the Master Sword in Zelda. I’m not really sure yet. We’ll see when I start adding monsters.
As for the monsters, I think they are my next step. I just managed to shrink a bit more code in my Random Dungeon Generator bank, which gave me just enough room to add some random monster placement routines. So far, zero monsters will show up since I haven’t coded any, but at least now the Atari is setting placements in the dungeon for them. It understand where I want them.
I’m now on vacation, took a month off. I am dedicating the first two weeks of my vacation on both this project and trying to switch my sleep schedule over to sleeping at night. I’ve been a night shift worker for about 10 years now and find it extremely difficult to get my body use to sleeping at night and staying awake during the day. This first day I crashed around 4pm and my body woke me up around midnight, telling me I should start my day now. Makes for a good time to code however. There is something extremely relaxing about being alone with no distractions and coding until the sun comes up in the morning.
So, it was a productive night. Not a lot to say for this entry but everything went mostly smoothly. Only ran into one small bug but managed to crush it pretty quick. Tonight was all about expanding the dungeon. I made the graphic for the stairs and wrote the code to randomly place the stairs on the opposite side of the dungeon that the player began at. Also used a variable to keep track of the floor level the player is on and changed the dungeon colours of the walls as the player descends deeper.
I did notice that the randomness of the dungeons was quite bad. Almost each time I ran the game the dungeons would be very similar. Come to find out that the Atari is very poor at generating a random number by default. So, as suggested online, I just used a mix of multiplication and division with the default rand command to generate a more random number. The dungeons seem to be much more to my liking now.
The random dungeon generation code exists entirely in it’s own bank.. After “perfecting” it, I pretty much ran out of space in that bank. I went from 3923 bytes to 2 bytes remaining… This was not good because I had planned for more routines in this bank. So I went through the code and cleaned things up. With a trial and error method, I had discovered ways of shaving down the code and freeing up a couple hundred bytes! This is something I need to get good at if I hope to complete this rather large project.
As for the bug, I noticed that every time you got to the 13th floor (Coincidently unlucky 13), the player graphic would behave strangely. The left and right animation graphics would kind of flip back and forth and there seemed to be an unpredictable room jump when ever you walked through a doorway on that floor. It was a very random weird bug, but was easy to reproduce. Just had to get to the 13th floor. Every time, without fail, there it was.
I had a feeling it had something to do with how I was handling the bank switching and variables. But after I did a quick search online about variable handling in batari, it said something about strange things happening if there are too many nested subroutines in the code. Sure enough, that’s what it was. I went through my code, got rid of the nested subroutines and bam! The bug was gone.
As it stands I can basically make this dungeon as deep as I want. Each floor is randomly generated over the data of the previous floor as the player enters it. This means the player will not be able to return to the previous floor (because it no longer exists) but also frees me to create a very large dungeon (Basically infinite). The way I will build the game will make it really unnecessary to return to the last floor, so this isn’t a big sacrifice. I kind of want this to be a longish game, with a clear ending for an Atari game. So I will decide for sure how deep the dungeon should go once all the gameplay mechanics are built in and I give it a run-through. But I’m thinking a floor number like 32,48, or 64.. Just because.. You know, those numbers, computer nerd. Feels right. But literally the floors could go on forever if I wanted them too.