Friday, May 13, 2016

Optimizing space, adding a switch.

Thanks to the nice folks at AtariAge, I got some feedback, mostly about various bugs, which have been cleaned up.  Now I'm trying to power through and add the rest of the content. Which is tricky, because I just don't have that much space left.

The biggest area of concern right now is enemies.  My space left in the bank where I store enemy data is small. Just a couple hundred bytes.  And I needed to add definitions for at LEAST 3 more enemies (bosses for the next 3 dungeons). And hopefully, another 3 or so more general enemies, so the 2nd half of the game isn't completely boring.

The first order of business was to read through the existing enemy definition code, and start optimizing. The first few enemy functions were unnecessarily huge. The amount of code for the slime and toady were just silly. I managed to compact it all a little bit, and squeezed in the 3 boss monsters.

Without much space left, the next 2 enemies were just palette/graphic swaps with more HP/Damage of previous enemies.

But one thing I wanted to add in dungeon 3 was a switch that controlled doors. How could I manage that with only about 10 bytes left?  I'm handling it like an enemy (it's a non-player object, and enemies are the only things I have in that category). The first hurdle was that my index that points to the enemy definition overflowed.

I have my enemies laid out in a big block of data, one after another:
EnemyDefSlime
    .byte #<SlimeFrame0
    .byte #>SlimeFrame0             
    .byte #<SlimeFrame1
    .byte #>SlimeFrame1             
    .byte #8                        ;sprite height
    .byte #$86                      ;color
    .byte #<EnemySlimeUpdate
    .byte #>EnemySlimeUpdate
    .byte #1                        ;hp
    .byte #1                        ;damage
    .byte #ENEMY_SIZE_NORMAL


EnemyDefGreenSlime
    .byte #&lt;SlimeFrame0
    .byte #>SlimeFrame0             
    .byte #&lt;SlimeFrame1
    .byte #>SlimeFrame1             
    .byte #8                        ;sprite height
    .byte #$D8                      ;color
    .byte #<EnemyGreenSlimeUpdate
    .byte #>EnemyGreenSlimeUpdate
    .byte #1                        ;hp
    .byte #1                        ;damage
    .byte #ENEMY_SIZE_NORMAL

Actually, on the 6502, this is a pretty inefficient way of laying out data, which I'll talk about another data. But anyway, for each room, I store an index of which enemy type we're dealing with (ie #0 for slime, 1 for Green Slime). Then I multiply that number by 11 (the number of bytes per enemy), add it to the address of EnemyDefSlime, and we have the address of our enemy definition.

But the switch was my 24th enemy. 24 times 11 is 264. (do you see where I'm going with this?) The 8 bit number I used to track the index overflowed.  

Well, I really didn't want to switch to a 16 bit number for this (math beyond 8 bits is a hassle on the 6502), so I ended doing a one-off hack, and hardcoding a special case for #24 to just go to the right definition.

The update code for the switch was tiny, and I managed to squeeze it in by doing another optimization pass at my other enemies.  But now I needed to add code in the door handler to open/close the doors based on my switch.  But my bank that handled that logic was also full. So I ended up moving a bunch of code to my kernel/graphics bank to free up space in my main bank.

Long story short (too late), I got it working. I have exactly 0 bytes of space remaining in my allocated enemy area, and 1 byte left in my main bank.  I still have 200 bytes of space in the graphic bank and the room definitions bank, so there's a TINY bit of wiggle room left.

But not much.  Let's hope I don't find any other bugs, or come up with any other crazy things that I feel I need to add.


Edit: Oh no, I just realized that I forgot to actually implement the power increase that happens when you find the power ring item. That would only be about 5 bytes, but it needs to be in the main bank. Sigh.

Tuesday, May 3, 2016

Looking for feedback

I've posted a build of Anguna on AtariAge, with most of the code of the game finished, and about 1/2 the world done.  At this point, I'm looking for people to try it and give feedback. Does it work? Is it fun?  Are there major issues with it?



If you have time and an Atari emulator, let me know what you think. Thanks!

Monday, April 18, 2016

Prepping for 1/2-finished demo

As far as I can think of, I've finished all of the major features of the game now, so mostly what's left is mapping out new rooms, and making new enemies.  I've finished the entire eastern-half of the world map (including dungeons 1 and 2), and so my next goal is to get it all cleaned up, and post another demo on AtariAge to try to get feedback from the fellow Atari nerds.

This week I've been trying to clean up the most obvious bugs, so I can then go back and do some actual play-through tests myself. (I've played through the first dungeon a number of times, but haven't yet played through all the content that I have in sequence -- I just change the starting room to whatever room I'm currently working on).

Things on my radar this week for fixing:

  • When you die, it should automatically select "continue" instead of "start" on the title, so you don't inadvertently start over.
  • Right now, the mechanism for restarting in whatever respawn location you've reached doesn't work - you always start in the first starting room
  • Based on some feedback on AtariAge, I made the first blue slimes a little easier, and made all enemies have a minor "bounce-back" when you attack them.
  • From all y'all's feedback, I've added experience and level-ups. Right now, it's simply based on the average of the enemy's HP and attack power, so I don't have to add another stat for each enemy.


There's still a few minor things: some glitchy stuff where the ball object gets displayed on the title screen, the subscreen doesn't work right when you're in a dark room, etc. I think I can get those hammered out in the next few days so I can start seriously testing!

SPOILER ALERT!
Here's my world map so far.
(Other than the 6 right-most rooms that I haven't bothered to screenshot yet) 

Saturday, April 16, 2016

Deadly Towers

After talking about Deadly Towers a couple weeks ago, I decided to try that game again. Like Super Pitfall, I've always been intrigued by this game. It was no fun to play, simply painful. But I always felt a sense of mystery and adventure from the large sprawling world that seemed to be hiding behind the misery of actual gameplay.

So using my trusty emulator on my phone, complete with save-state cheating, I decided I needed to play through the game to see if the game-behind-the-game was any good.

Unlike Super Pitfall, this game wasn't 100% horrible once you understood it. It was just mostly horrible.

Anyone who's played the game knows how frustratingly hard it is. There's usually tons of enemies on the screen at once, and one or two hits will either kill you or knock you back off a cliff where you die. To make it worse, there are invisible warps all over the place that take you to these vast dungeons filled with tons of featureless rooms (each dungeon is a 16x16 maze of death), many of which are packed with enemies that literally kill you the second you step inside. When I was younger, I thought these were secret warps to a later hard part of the game. I didn't realize they were just stupid nonsense.

This is what you have to explore if you step on the wrong patch of ground.
Really, you might as well just hit the reset button instead.


Well, it turns out if you use a map to avoid the dungeons, and carefully go get all the right powerups in the right order, the game is playable. (getting most of the powerups involves stepping on other invisible warp spaces)  The vast world really isn't very vast, or interesting. By the end of the game your armor is good enough that you don't die instantly.  But at that point, there's not much to do but hack your way through all the enemies. There's 10 or so bosses, but most of them are basically the same thing, and require very little effort. It's not as horrible as it seems at first, but it just never gets fun.

That being said, this game could have been fun if:
1. The dungeons didn't exist.
2. All the secret spaces weren't secret, but were visible warps
3. The difficulty curve wasn't stupid. Make the character a lot stronger at the beginning, and the monsters harder at the end.
4. I give up, I don't think all those things would fix it. It wouldn't be known for being so terrible if they fixed those, but I'm not sure it would actually be any fun.  I'm tired of thinking about this game. I'll stop now.

Wednesday, April 13, 2016

Experience!

Thanks for the comments, all.

Sounds like my everyone likes the idea of leaving in the XP/levels. Like Rob said, I'll have to play with the tuning, I definitely don't want grinding to be necessary.

Right now, the only random drops are meat (hp restore) and arrows (once you have the bow, the way to get more arrows is by picking up drops).  The idea of randomly dropping significant powerups sounds really tempting, but I'm not sure that it will work nicely into the system of persistent state that I've built so far. I'll have to think about it.

Right now, the direction I'll plan on going with it is that max HP is determined by your level and experience, and attack/defense is determined by which pre-set powerups you've found. But you never know, I may end up changing it after all.


Monday, April 11, 2016

Experience?

Ok, I need feedback from all 2 of you people that read this.

In GBA Anguna, you were motivated to fight enemies as you explored the overworld, because they dropped money, and you needed money.

In Atari Anguna, there's no money. I just don't have the ROM space for shops. I'm toying with the idea of replacing it with experience/level-ups. You get enough experience, your max HP goes up a level.

The advantage is that it motivates you to fight your way through the overworld instead of just running past everything.

The disadvantage is that it encourages/allows grinding, which I hate.

Opinions?

Friday, April 1, 2016

Is it fun?

This week I ran into the same introspective question that I hit multiple times with Robo-Ninja: Is this game going to be any fun?

It's just really hard to tell, as the developer. I'm way too closely attached to every minute detail to have any idea if this game is remotely fun to play.  I'm pretty sure that's what happened with Deadly Towers.  The only explanation I can come up with is that they didn't get outside input to tell them how bad their game was, and they were too close to see it.  I really don't want to make the next Deadly Towers.


NES Anguna

Well, I had a little bit of time still, while Frankengraphics is finishing up her game Project Blue, to have a little downtime on Halcyon, s...