Well, after quite some time, I managed to do a few things, but not as much as I'd hoped. So, again, sorry for the wait.
First, I had to put the "on-the-fly modification of Overworld Tiles" on the ice, because frankly, I struggled too much with it, and I had to go do something else before going crazy. Also, I think the idea was cool on paper, but the end result was relatively meh. I may return back to the problem later, but I'd give more chances to the Custom Tiles idea, which I already made work in the past. The other thing I feared is lag. I didn't experience any of it, as far as I can tell, but it could become laggy if too much work is needed every frame. It does produce a noticeably longer delay on the loading transition, but that is not important. All in all, I'll spend my time on more essential things.
Speaking of that, I spent already too much time on a new concept that existed in Zelda 1 : Trap Doors. I'm not sure if it's the correct name, because in real life, a trap door should be on the floor, right? But that's not the case. I'm talking about doors that shut behind you. Zelda 1 had them in spades, and you had to do something to make them open again, like killing all enemies or pushing a block. Some of these doors could not even be reopened, like a one-way entrance. Anyway, I also worked too much on that one, but even though it's not finished, I'm on my way to make it completely functional and make it work anywhere I want.
It looks like this :
https://www.youtube.com/watch?v=yzZA85urhgA
I created my own data format to give every room the possibility to have either no door, one on the left, one on the right, or both. When you enter a room, there are a few frames where Link moves, but the player doesn't have full control of him. During these few frames, the code I wrote checks if the room has doors, and if it does, it draws one block every other frame, at the position desired. For now, the position is hard-coded, so if the ground is at another level, we will need to have provisions for that. I used the "Breakable Block" sound, which is played for 5 consecutive frames. I think it sounds good for a door, but it could easily be changed to something else. I initially tried the "Fire" sound, but I thought it was too subtle and quiet.
Not shown on the video is the equivalent for the Right Trap Door, which is a bit more complicated to code, because of the fact that Areas can have different widths, from 1 to 4 screens. So we have to use this information, conveniently stored in $D1, to select the correct position for drawing the tiles.
The major difficulty comes from the fact that we have to do two kinds of drawing when we want to change anything in the background, and that's applicable in every side-scrolling areas. The terrain in Level Data is made of blocks, 2x2 tiles. Each screen has 0xD0 tiles. Up to 4 screens. When you want to change something, you need to manually draw the 4 tiles that compose the block, AND you have to change the underlying block data. If you only draw the tiles, you will see the result, assuming the drawing occurs on screen and not in the "scrolling buffer", but as soon as you leave far enough, the tile will be erased by the scrolling mechanism, so when you come back, the old tile will be drawn again, because you didn't change the block data. On the other hand, if you only change the block data, and the tile is within the viewport, you will see no instant change, but when you go far enough and come back, the tile will be drawn as your changes dictated. And as if it was not enough, you also have to do some more math and bit manipulation to change the palette. That last one, I didn't do yet with my Trap Door mechanism, as the video demonstrates at the end. I draw blocks that are normally teal colored, but because the background color is set to grayscale, the instant drawing shows the tile in the wrong color. However, when I come back, the tile is redrawn using its natural color.
Confused much?
Anyway, there is more work to do, because to reopen the doors, you will need to kill all enemies in the room. The custom data I created will also contain an enemy counter, and every time you kill an enemy, this counter will decrease by one. Once the counter reaches zero, the doors will open. I think this mechanism will create a brand new dynamic in palaces (and maybe other places, who knows?) and force players to fight to the death to progress in the game. You will have to change the way you think about palace navigation.
So, what's left do do exactly?
- Make sure the Right Trap Doors work correctly, with all area widths.
- Make sure the custom data table has an enemy counter, and that some enemies (Elevator, for example) are "exempted" from the count.
- Make sure the door tiles have the correct color. If it reveals too hard to do, I could sacrifice this and just make sure the tiles have the same palette as the background.
- If time and motivation permit, add a third type of Trap Door (with the actual name), an horizontal one that blocks a hole in which you can fall.
Other than that, the name of the hack should contain
Dark Fortress. Maybe
Zelda II : Dark Fortress. Or maybe remove "Zelda" from the title, since she probably won't be part of the story at all. How about
Adventures of Link : Dark Fortress ? Or something else, if you have any ideas. I also started working on another Overworld Map, but I won't reveal each one of them, because I can't spoil everything. All I can say is that it will involve a very big mountain.
Also, I decided that the concept of lives are officially out. There will be several changes to make up for it. I'm not fixed on how many mechanisms will change, because each time the game has to be reprogrammed represents quite a challenge. A quick list: no more dolls, small heart items, no instant kill from falling into lava, restart from different places after death, more fairies, enemy damage balancing and reserve fairy.
