The Legend of Zelda: Forgotten Gates

Well, I've done character spotlights for all of the playable characters, even the guest party member Six Sages and the legacy characters who probably won't be in the game's plot...so I guess it's time to roll out some NPCs. We'll start with the three main villains the good guys will be pursuing and clashing with. Interestingly, I came up with these villains specifically for the Forgotten Gates game, but I ended up playing them as antagonist characters on Triforce MUCK/Zelda RPG as well. X) Here's the first one: Dorjan, the wizzrobe.



While having complex motivations and sympathetic traits in a villain character can be very interesting, sometimes it works great to have a guy who is just all-around bad. Dorjan is that kind of villain -- an uncomplicated and unapologetic evil dude out to amass power for himself and use it to inflict misery and death on others. That said, his snarky and self-aggrandizing approach to villainy makes him a lot more entertaining than just some spooky ominous threat. He's derisive of less powerful beings, he treats his undead minions like an abusive boss would his employees, and he regards living beings as 'life-ist'. As some of you may have guessed, Dorjan's personality is inspired in no small part by Black Mage from 8-Bit Theater. ;) Also, so far whenever Dorjan has made a major appearance, I've managed to have him and his minions do a spoof of some popular song, like This Is Halloween from A Nightmare Before Christmas and Still Alive from Portal. ;) I'll have to try and work something like that into the game.

TL;DR warning, this post's going to be more of a development history ramble than strictly a design discussion. I do have a useful tidbit of technical advice for those who want to include complex map event movement control in their RPG Maker games, though. Feel free to skip down to the last paragraph for that.

Making a system for monsters that actually move around and display behaviors before combat starts was one of the more intricate challenges in this game. RPG Tsukuru 2003's events are very much geared toward individual behaviors listed in their own scripting. What I needed was ways to make a small set of events look and behave differently depending on which monsters are supposed to be in a given room, which is randomly generated.

Originally I managed this by having a common event for each possible monster type which would move the monster map events in their desired behavior. Of course, that's just the 50,000-foot view; the details of this system were rather intricate. Each possible monster (a maximum of 6 in my system) had to have variables and switches controlling where they were in their behavior patterns and whether they were still busy executing a movement or ready for the next thing. And because the Move Event command couldn't be fed variable values to determine which event is being moved or which switches to change as part of movements, there had to be 6 versions of every Move Event command.

To top it all off, I needed a big common event to set up variables and switches and then call the appropriate monster behavior common events, checking as often as parallel processing would permit which ones were ready to be called. This was not only clunky and hard to maintain, it strained the limits of the system to keep up with. I ended up having to do tricks like giving monsters 3 and 4 a little wait time before activating and 5 and 6 a little more than that, so that the monsters wouldn't all be asking to do their behaviors at once. Even there, I worried that the system would become unmanageable as the list of monsters grew -- after all, I was having to run through an enormous number of Conditional Branch commands to determine which monster behavior common event to call.

Well, eventually I learned about DynRPG and wrote the DynParams plugin, hallelujah. X) That streamlined a great deal about the event scripting. Which map event to move and switch to change? Just write the Move Event command as if I'm moving the first monster map event, then overwrite its parameters to adjust to the one I really want. Which monster behavior common event to call? Calculate the event number and slap it over the Call Event's parameter, bye-bye huge list of Conditional Branches. The monster movements ran more smoothly and were much easier to maintain after this change.

Still, it was far from perfect. There was noticable lag, especially when the maximum of 6 monsters were present and one of the more complicated behaviors was in use. It was especially bad when first entering a room; the game would hang up for a second or so, and when it finally gave a visible update, the monsters would be in different positions than they started, maybe even having gotten as far as touching the hero event.

What got me started on another overhaul of the system was a bug I couldn't seem to squash in the deku scrub monster behavior. I found that for some reason, the nut spat by monster 1 would sometimes fail to crumble when it hit an obstacle, and subsequently just sit there. I was able to determine that a switch wasn't getting changed like it was supposed to (or maybe, it was getting changed again before the appropriate code ran), but I couldn't figure out why. So I decided to give a try to a significantly different approach: implementing monster behaviors in a DynRPG plugin.

I'm not going to get much into the nitty-gritty of reimplementing monster map event behaviors in DynRPG. A lot of the basic concepts were essentially the same, just written in C++ instead of RT2K3 scripting -- which, on top of executing faster, did allow me to be a bit more elegant about it, what with having access to more than just basic RT2K3 variables and switches. I still had to work with a DynRPG-internal version of the RT2K3 Move Event command, which turned out to have a little bug which caused me to back-burner the effort for quite a while. Eventually that got worked out, though, and now I've caught up with all the monster behaviors I had in the game, reimplemented in DynRPG. The mysterious deku scrub nut bug does seem to have been fixed by the switch, and everything runs faster and smoother now. :) Even the room-entry lag has almost disappeared, although that may depend partly on the computer you're running the game on.

There's one important general-use RPG Maker trick I wanted to highlight in this post; it made my movements system possible from the start and is still necessary in my DynRPG-implemented version of it. If you want to have a map event do some movements and then detect when it's done so that you can give it further instructions, the best way I've found is to turn ON a switch to indicate it's currently moving, then include a step in the movement pattern that turns that switch OFF (probably at or near the end). It may work better for your purposes to do it the other way around (switch OFF while moving and ON to indicate it's done), but that's the way it's currently working for me. With this setup, the switch gets changed when the movement is finished. You'll probably want to use the "Ignore Impossible Moves" option in most cases -- changing a switch value is never impossible, so your event will just skip stuff like moving to a spot that's blocked.

Darunia is the Sage of Fire and chief ("Big Brother" as they call him) of the Gorons. He's a serious, manly-man type of leader, although he also has a boisterous side and a surprising love of music and dance. He made Link an honorary Goron Brother after he cleared the King Dodongo out of the caverns where the Gorons obtained their food, and resisted Ganondorf's rule during his seven-year reign of terror.

In Forgotten Gates, Darunia wades into battle swinging his tribe's most treasured weapon, the Megaton Hammer. Quite naturally for a Goron, Darunia is a physical tank fighter, emphasizing durability and raw strength. Being one of the Six Sages, he does still have decent mystical power, but he's the lowest amongst them at it.

Something I've been pondering lately is whether it's worthwhile to keep the capability to dual-wield weapons in the game. e.ea It presents a bit of a balancing problem. Simply put, the ability to do two attacks in a single turn is REALLY POWERFUL. No duh, right? X) That's double damage output! Why would you ever pass that up?!

Now, there are some other factors involved, of course. The weapons that can be dual-wielded are short, literally single-handed weapons by definition. That gives me a good excuse to set their damage relatively low, and unlike in standard RPG Maker games, Forgotten Gates weapons don't just simply add a bonus to the wielder's stats -- they control what proportion of the stats are actually used. If I want to, I can set the single-handed weapons' attack power to half or even less of what the analagous two-handed weapons' power would be -- that way, their damage per turn will still be lower than their counterparts' even though they're attacking twice.

However, there's also the targets' defense to consider. Hitting twice means that the defense is applied twice as well. For example, suppose a hero could use two weapons that deal 6 damage each, or one weapon that deals 10 damage. 6 X 2 = 12, and that's more than 10, so two weapons is better, right? But if the enemy absorbs 3 damage in defense for each hit, that would result in (6 - 3) X 2 = 6 for the two weapons and 10 - 3 = 7 for the one weapon. Right now very few enemies have strong enough defense for this sort of thing to matter, but that will probably change, and that's a good thing -- it gives players a reason to switch up their tactics in response to the situation. But it also creates a tricky design space, where I have to make sure the numbers line up with one more thing. Are there monsters that have enough defense to make the weaker weapons extremely ineffective, maybe even totally unable to inflict damage? And is that true of all the heroes who can use these weapons, or just the weaker ones?

Originally I had a couple of heroes planned (Rizzen and Drakler) who would dual-wield short swords, but they're now both relegated to 'legacy character' status and may not make it into the final game at all. That leaves the only dual-wielders those who have the choice between double daggers or a bow and arrows. Most of them are toward the lower end on the attack stat spectrum, yet as things currently stand, they outstrip their single-wielding compatriots in damage per time when they dual-wield. I'll have to either seriously nerf daggers or boost most other things to make the weak attackers, y'know, weak. c.c

The other major option, of course, would be to cut dual-wielding out of the game entirely. That would make balancing easier, but it would also make the choice between dagger or bow and arrows much less meaningful. It would probably also feel immersion-breaking and/or unfairly restrictive for some players -- "Why can't I use a dagger in each hand, huh?" :P I don't see a way to mitigate these issues, so it'd essentially be a price paid in game quality for simplicity of development.

For now, I think I'm going to keep dual-wielding, with the understanding that I could cut it out later if need be. Balance is a secondary concern at this stage, something to keep an eye on and adjust roughly to keep things fun, but not spend a lot of effort tuning. The factors going into it are going to change as I add more mechanics, after all.

Yay update! Here are the changes:

• Added playable heroes Noab and Irina.
• Added system for equipment breaking after a number of uses.
  
• Added ability to switch equipment mid-battle.