The Legend of Zelda: Forgotten Gates

Yay, RMN's up again! And very good timing for me. I finally got version 0.3.0 of The Legend of Zelda: Forgotten Gates released LAST NIGHT. X) In addition to bugfixes, I decided to add some features like the ability to customize random or replay quests, a shop room so players can buy fresh weapons (particularly important for the first story quest since there's only two heroes chewing through the monsters and few of the monsters drop weapons), and instructions about status conditions. All of these features were relatively quick individually, but added together with the huge time bite from family hang-outs the week of Christmas (which was of course very much worthwhile), they nearly made me miss the soft deadline of end-of-month again.

BUT, it's out there, and more importantly, it's a pretty decent 'vertical slice' of what the game as a whole should be like. 8D That means most of the work from here on should be production (drawing sprites and making animations, laying out dungeons, writing dialogue, etc.) moreso than infrastructure (programming, systems work, etc.). I should hopefully be able to do releases a lot more often as a consequence, say every month or three -- we'll see how it goes.

Note: this post was intended for 2024-11-01, but RMN being down for an extended period prevented posting until now.

This month I finished up my rewrite of the high-level outline for the story's first arc, which ended up giving me some interesting ideas for mechanical uniquenesses in some of the early quests. :) Then I got to work on actually implementing the first quest. Naturally, this involved meeting up against some hurdles I'd only vaguely anticipated before. The main one was how to run cutscenes during a quest. Normally in RM2K3 you can just make whatever events you like and put scripting into one or more of them to make a scene play out, but since FG uses one BIG map full of one-screen rooms for all of the quests, I have to do things in a more modular way.

I eventually came up with the idea of having a variable holding the reference number of a common event used for special happenings in the current quest. I can set the variable to whatever it needs to be at the start of a quest, then call the common event at occasions when I might want to do something, like the start of the quest, the first time the player enters a particular room, or when a particular win condition has been fulfilled. In vanilla RM2K3 that would require having a bunch of conditional branches to call the right common event (or making the special handler events map events), but thanks to my first-created-and-still-favorite plugin DynParams, I can just call a common event by variable reference. ^.^ It took a while to get everything working right due to little details in my dungeon managing code that were easy to overlook when setting up a pre-constructed dungeon and a weird bug that interfered with text messages when skippable event movements were involved, but I finally managed to get the first quest working with a starting and an ending cutscene. I still intend to add some more cutscenes, and I should also work on a proper 'hub world' for entering individual quests.

Note: this post was intended for 2024-09-01, but RMN being down for an extended period prevented posting until now.

This month I decided to add a new chipset (the set of tiles which are used to make maps) to Forgotten Gates. Where the existing chipset I've been using is for a forest environment like the Lost Woods, this new one is for fields. Each chipset (at least the ones intended for use in the random dungeon system) has to be functionally more or less the same -- consistent in which tiles are walkable space, which are walls, etc. Also, there have to be six different walkable tile types, one for each of the magic elements in the combat system, although I'm purposely trying to vary which tile is associated with which element from one chipset to another. I was able to use rips from A Link to the Past pretty heavily, so this chipset at least didn't turn out too difficult. I did have to make a few original bits, though.

A few of the tile types make use of RM2K3's built-in animation capability, which is usually used for 'water' tiles. In the forest chipset, I ended up actually making all of them appear static -- I may go back and improve some of them eventually. In the field chipset, the LttP rips provided me with an easy animated option in the form of bouncing flowers (why they bounce who can say, but it looks cool). When I tried them, I discovered a problem I hadn't noticed before: when two different types of 'water' tiles are placed next to each other, they appear to meld together instead of having edges between them. That makes sense if they're actually depicting water (like an ocean tile with a whirlpool next to it), but it wasn't correct for my purposes, where the animated tiles are supposed to be distinct types of ground. :/a For a while I thought I'd have to make a design rule that the animated tiles can't be placed next to each other and remake any existing rooms which break this rule, but then I remembered a hack I'd accidentally discovered a while ago. It turns out that if you use the map editor's area select-and-move tool on some tiles, they won't change the appearance of their edges to match the way they'd be drawn if you placed them the ordinary way. :o So I was able to draw the animated tiles in the midst of non-animated ones, then move them to where they're needed. B)

Each of the walkable tile types also needs a corresponding battle background. I mostly make the battle backgrounds by copy-pasting the actual tiles into a base background, so that wasn't too difficult. The animated tile set me off on another unexpected improvement campaign. Since battle backgrounds are static, I couldn't really have the flowers bouncing in that...OR COULD I? +.+ It occurred to me that if I used the 'frames' battle background type, and made the back frame a moving swathe of the animated tile in its various states, then I could make them appear animated by having a static front frame with holes showing through to the back. :D

So I gave that a try, but it turned out there was a problem: the maximum movement of the frames normally allowed is 8 pixels on each axis, but the tiles are 16x16 pixels. So it was DynRPG to the rescue once again! I updated the DynDatabaseOverride plugin to allow changing the frame movement speed (and everything else about Terrain data while I was at it) so that I could set it to something outside the bounds allowed by the RM2K3 database editor. It turned out that when the frame movement is set to something above 8, instead of adding to it, it doubles -- so setting it to 9 makes it move 16 pixels, 10 makes it move 32 pixels, etc. Fortunately that works just fine for my purposes, and I was able to achieve the animation I wanted.

Note: this post was intended for 2024-05-01, but RMN being down for an extended period prevented posting until now.

This month felt pleasantly productive after so long working on just coming up with battle banter. X) I finished up John's quips, then implemented the effect of the Reflect status condition (a little embarrassing that it's been in the game for so long without doing what it's supposed to), added an 'X status' system (battlers inflicted with a status will also receive immunity to further infliction of that status for a number of turns), and did some general bugfixes. I also began the somewhat tedious process of transferring the text for any Show Message and Show Choice commands to a data file that's imported at game start. In the unlikely event anyone ever wants to translate this game, that will make their job easier, since they don't have to go hunting through the database and maps for all the commands with text in them. I have to do so now to effect this change of course, but it should be relatively easy at this stage. X)

This has been a slow month for progress. I've basically just come up with battle banter for almost 3 of the heroes. The big one this time has been Arumarg, because he can transform into five other characters with his Mask ability. Each of those characters only has one special skill, but they all need banter for the basic actions -- Fight (which has 5 variations on its own), Defend, Look, and just skipping a turn due to status ailments. Come to think of it, maybe I should add even MORE variations to Fight depending on whether the characters have statuses like Blind or Mighty or Weak. X) On the plus side, doing this has forced me to come up with names for the characters Arumarg morphs into -- up until now most of them have just been 'Arumarg Kokiri form', etc.