• Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Progress Report

Triforce Guard ability

This month's progress has been mainly about getting Zelda's Triforce Guard ability to work. As a reminder, it works similarly to Celes's Runic ability in Final Fantasy VI; Triforce Guard absorbs the next purely magical attack made by the enemy and gives the mana used to perform it to Zelda. I'd decided to implement a general counter system and make Triforce Guard part of that, which I did...but it still needed some special code for the unique traits of the ability. At any rate, after much coding and debugging, the counter system in general and Triforce Guard in particular seem to be working (although I wouldn't be surprised if more bugs crop up when I implement more counters).

Game Design

Character spotlight: Xu



Xu is a mage who weaves her spells primarily with her lyre. She was the leader of the Resistance against Ganondorf, and has many connections with both the royalty of Hyrule and the more common folk who stood with her in defense of their land. Since that time she's settled down with a blacksmith named Einion and started a family, although as with Aubrey and Fallon, the game is set in a time before any of their kids came along.

In Forgotten Gates, Xu is a Squishy Wizard type, second only to Zelda amongst the main playable characters in magical oomph. Her element is Spirit, making her strong against Light and Fire, weak against Water and Shadow, and neutral against Forest. Offensively, though, she can take advantage of any elemental weakness the enemy might have, thanks to a trio of spells that deal damage of the Fire, Water, and Forest elements (the in-character justification being that she summons spirits of these elements). She only has two of those spells at level 1, however, and her Spirit-element spells tend to be more powerful at base.

Xu's special ability is Song, which is inspired by Mog's Dance ability in Final Fantasy 6. Like Dance, Song allows a category related to an element to be chosen (in this case the songs of the Six Sages), but the precise spell which results from this is random. Also, Song can change the terrain on which the battle is taking place. In FF6 this had very little mechanical effect, just that the ability had a 50% chance of failure the first time if the terrain didn't already match the dance being attempted. In FG, terrain boosts the power of elemental skills, so being able to switch the terrain has a strong tactical importance. I think I may make it such that Song only switches the terrain and has no immediate spell if Xu uses a song that doesn't match the terrain, rather than giving it a failure chance. I worry slightly that players who don't bother with tutorials will think that's all the Song ability does, though, and never try using the song that matches the terrain because that would be a waste of a turn. Another difference from Dance that I'm pondering is not forcing Xu to continue playing the song for the remainder of the battle.

Progress Report

Logging system

This has been a busy month in ordinary life, so I haven't made as much progress in Forgotten Gates as I would've liked. The counter-action system is about halfway done, I would say. I've established the data class for holding counters in code, the spreadsheet page for generating their data, and the function for pulling the data into the plugin. Now I need to actually work it into the combat system.

I've also made my debug logging system a bit more sophisticated (C++ talk ahead, those not into that can skip the rest). Originally I just had a file pointer open and a couple of general patterns for pushing stuff into the file. Then I got the idea of having indents according to how many levels deep into functions the code was, so I updated all the function start and function end logging to do that. But it turned out I made a mistake and the indent didn't shrink as much as it should when a function ended, which meant I had a bunch of stuff to re-edit. e.ea All it really would've taken was a find/replace on a couple of files, but at that point I decided I should "work smarter, not harder" about this.

So I did some research on C++ logging libraries. You'd think there'd be plenty of those, and there are, but the ones I encountered didn't help much in my case. The first that caught my interest was Log for C++ (log4c++ for short), which is modeled after Log4j, an industry-standard Java logging library. Unfortunately log4cpp can't just be dropped into a project, it has to be compiled, using the same C++ compiler as your project. It didn't seem to like the particular compiler used by DynRPG (and DynRPG has to be picky about it because it's a hack of memory addresses in RPG_RT.exe). I also tried Easylogging++, and with that one I was able to get it working with the default configuration, but for some reason it had trouble when I tried a custom configuration.

At any rate, these libraries didn't have the indenting trick I wanted, so I figured I'd have to write a simple logging class of my own. I ran into an issue while trying to write functions for that class, though: functions need to know what type of variables are being given to them as arguments. Up until then I'd been using statements like
*ofDebug << debugIndent << "Current value: " << value;
and that worked great because the << operator could handle pretty much any kind of variable without fuss. Even if all my function really did was a single line of code similar to that, I would have to turn the message into a single string before passing it in, or something of that nature.

Fortunately I recalled that C++ supports a somewhat more arcane method for this sort of thing: function-like macros. I haven't really had much use for them before, but they came in handy here. Basically I was able to define a pattern such that the pre-compiler will literally substitute in something along the lines of the above code whenever it sees
LOG_OUTPUT("Current value: " << value);
and then the compiler will work with that instead. Since it's a literal hard-code substitution there's no worries about the types of variables used or how many pieces go into the message. I made similar macros for starting and ending functions which not only write the function name to the debug file, but take care of increasing or decreasing the indent. Now if I decide to change how they work, I don't have to change the code in dozens of places, just one.

Game Design

Disposable equipment

One of the things I've pondered as a mechanic for Forgotten Gates is disposable equipment. It's a lesser-used but still not-unheard-of mechanic for RPGs: as you make use of a weapon, armor, or other piece of equipment, it becomes dulled, battered, or otherwise unusable. Some games will gradually decrease the effectiveness of the equipment as it is used, and perhaps allow the player to repair it to full strength periodically. Others simply give a piece of equipment a limited number of uses, and when it's used up, it's gone. Fire Emblem is a decently well-known game series that uses this mechanic, and apparently the latest Zelda game, Breath of the Wild, also follows this paradigm. (I know, I know, I'm making a Zelda fan game and I haven't played BotW yet? How shameful.)

There are several reasons why disposable equipment might be a good fit for Forgotten Gates. Stealing weapons from enemies or simply receiving them as item drops when they die is one of the game's existing features. If weapons are imperishable, then it might feel good the first time you acquire a particular weapon, and to a lesser degree again until you get enough for all the heroes who can wield it, but after that getting more of it would just be market fodder. If weapons are an expendable resource, though, then gaining more of them has more meaning. It allows me to be more generous with weapon drops, instead of making it a lucky event that could take beating just one monster or dozens. It also has some interplay with Shemri's Throw ability which I mentioned last time. Players would be a lot more willing to Throw weapons if they would inevitably lose them to deterioration anyway, and they'd get to feel clever for Throwing weapons that only have one or two uses left.

An argument could be made that disposable equipment meshes well also with the unusual "reset levels with every quest" rule I'm planning on too. I'm not entirely sure yet whether equipment should be carried over from one quest to another. At the very least, any quests that are one-off challenges having nothing to do with the plot should likely have their own specially defined starting equipment and further equipment to be found during the course of the quest. That being the case, it would be easier to design the challenges around extra equipment being a temporary boost, rather than a permanent one which lasts for the remainder of the quest. The latter could make finding and acquiring the extra equipment early on too critical of a need.

All this sounds great when discussed from a pure design standpoint, but there's a huge technical problem: RM2K3's item system isn't built to accomodate equipment deterioration. There are several ways I can think of to deal with this problem, all of them having significant disadvantages.

  • Use "skill scrolls". I say RM2K3 isn't built for equipment deterioration, but it does have one built-in feature that's similar. Skill scrolls, which are items that invoke a certain skill when used, can be set to have up to five uses. That's not a whole lot, but depending on the frequency of weapon drops/finds, it might be workable. However, skill scrolls can't be equipped, just used, so they wouldn't contribute to passive attributes like defensive stats. Also, the player would have to choose their weapon to attack with every time by looking into the item menu. Very awkward.
  • Treat the number of items in the inventory as the number of uses available. This would take a little under-the-hood manipulation, but it wouldn't be too hard to subtract one from the inventory count of a piece of equipment every time it's used. That way, having 10 swords in the inventory doesn't "mean" having literally 10 swords, it means having 10 uses left of your sword. The trouble there is, there's nothing stopping the player from equipping that "same" sword to multiple different heroes. It's also wierd for the Throw ability. If using a weapon normally costs 1 weapon too, why wouldn't you use Throw as much as possible? I could make it so that Throw uses a higher count of the weapon, but then it would just feel like a more expensive version of a basic attack.

  • Make equipment breakage a random event. This is a less intuitive solution, but it's one of the easiest to implement. If equipment simply has a chance of breaking every time it's used, there's no need to keep track of how many uses are left. The downside is, a run of bad luck could leave a player very low on equipment, and a shiny new toy could break on the first use. I could mitigate this somewhat by providing another type of item, more common than the weapons themselves, that can be used to repair broken equipment, but it would still leave the player cursing the RNG on occasion. There also wouldn't be times when the player knows they're close to using up a weapon and thus are encouraged to Throw it.

  • Implement a custom item system. At the end of the day, I can do nearly anything with DynRPG, so if I want a system which tracks the durability of each individual weapon in the inventory, then Link's cap, I can make it! I could even get really fancy with it and turn item storage into a mini-game, where the player has to arrange items of different sizes and shapes into a limited space in their backpack. "This axe only has a few uses left and it's an awkward shape, so I guess I'll toss it in favor of keeping these potions I just found," etc. That would really start to evoke a spirit of Rogue-like resource management, although it could be an irksome distraction from the main meat of the gameplay. Regardless of the exact details, though, the big problem with a custom item system would be that it's a TON OF WORK to implement! I'd have to create an entirely new menu system that's available both inside and outside of battle. I'd have to replace the equipping menu too, since it normally relies on the built-in inventory. All in all it seems a lot of effort and delay for a small mechanical gain that a lot of players may not even like.


As a note, I've talked about this mainly in regard to weapons, but there's no reason it can't apply to shields, armor, headgear, and accessories as well. Doesn't necessarily mean it should, though. Accessories especially I could imagine being very irksome to have to replace, although if they could be repaired it might not be so bad.

So what are your thoughts? Does managing equipment as a limited resource appeal to you, or would you rather just keep your stuff for the rest of the game once you acquire it? If you do want breakable equipment, do you have a preference amongst the above methods of implementation, or can you think of another way it might be done?

Progress Report

Counter-actions

This month I finished extracting that sub-function I spoke of last time, and I squashed some bugs that cropped up because of the change. Then I started implementing some of the more unusual, edge-case abilities in the game. Link has a Pot Smash ability which on top of dealing damage can result in a random resource drop. There's also his Spin Slash, which involves charging up for a maximum of three turns and then unleashing upon the foes. Those are done and working in the game now.

My next priority is Zelda's Triforce Guard special ability, which absorbs any single magic attack made against her party. In order to do that, though, I'm taking a step back and writing a more general counter-action subsystem. The idea is to have a list of all currently active counter-actions, and whenever an action is taken, check whether it triggers any counter-actions. I'm a little worried about the possibility of multiple counter-actions interfering with each other. For example, if a particular battler both has an active trap that stops someone from attacking them, and is equipped with a weapon that gives them a chance to disarm their attacker, how is it resolved when they're attacked? For now, I'm thinking the number of counter-actions in the game will be small enough that I can manage sorting this out with hard-coded logic, but if the amount grows and gets more complex I may have to figure out some sort of priority system for them.

Game Design

Character spotlight: Shemri



Shemri is another of my own characters. She started as a stoic renegade of the Gerudo clan, opposed not only to Ganondorf's rule, but to the thieving and xenophobic culture the Gerudo have had for generations. I like doing characters that are subversions of their race, but what I didn't know back when I made Shemri is that her premise echoes a certain character infamous for inspiring overused copycat characters amongst role-players. X) Anyway, Shemri left the clan at an early age to live as a huntress, aided by her feline companion Sheikah. She naturally became a part of the resistance against Ganondorf when that sprang up, and after the Gerudo Remnant resettled in Gerudo Fortress, Shemri wound up second-in-command to Nabooru. Things have gone a lot further than Shemri had dared hope they would in her lifetime toward restoring the honor of the Gerudo...although she still struggles to keep them, including their illustrious leader, from having wandering fingers toward others' purses. -.-; Old habits die hard.

In Forgotten Gates, Shemri is a physical glass cannon, very high in speed and attack, but low in everything else. She wields polearms, which are the most diverse class of weaponry in terms of possible damage types--blunt staffs, stabbing spears, chopping poleaxes, and even slashing glaives are included. Shemri's element is Shadow, making her strong against Forest and Spirit, but weak against Light and Fire. Shemri's skills revolve almost entirely around inflicting status conditions on the enemy, from a nerve strike to paralyze a foe to opening a dark rift to swallow and instantly KO the entire enemy side (although of course most enemies have a decent chance of resisting KO moves individually). As a little extra bonus, anytime Shemri takes a hit, there is a chance her cat Sheikah will make a counter-attack.

Shemri's special ability is Throw, which works very similarly to the ability of the same name in Final Fantasy 6. Any unequipped weapon in the inventory can be hurled at an enemy for a powerful hit, at the cost of losing said weapon. Naturally this is a fairly steep price to pay, unless the player is frequently picking up weapons they otherwise have no use for. I'm hoping they often will be, but there are some technical hurdles for that, which I'll probably be discussing in next month's design post. There can also be items whose sole use is to be expended with this ability, like shuriken and grenades.

As an aside, implementing this special ability in vanilla RM2K3 was painful and clunky. X) It involved a jury-rigged menu system in which a message box is displayed showing one weapon from the inventory at a time, with options to go to the next one, the previous one, or use this one. Now with DynRPG, I'm planning to reimplement this as a skill subset containing a skill for every possible weapon to be thrown. In between each battler action, the battle plugin will check the current inventory and add or remove those skills from Shemri according to what weapons are there, and maybe even change the names of the skills to show how many of each weapon is available.

Progress Report

Code rearrangements

Still working on that combat plugin. This month I hit a point where I decided to rearrange some code, taking part of the function that resolves battle actions and turning it into a smaller function that calculates the effect of a skill on a single target. I'd had an inkling when I was first writing the resolve action function that I was probably going to want to break it down further, but I had trouble figuring out exactly how at the time and decided to just move forward. Extracting the sub-function hasn't been easy either. I've twice deleted parts that I shouldn't have by accident. The first time I was able to get around it because I made the changes on a thumb-drive copy, and I got the old code back from my hard drive. The second time I'd already synchronized the thumb drive with the hard drive. I should be able to retrieve an older version from my online backup service, but for some reason it's currently unavailable. Well, that's what I get for not using a version control system.

Game Design

Enemy AI

One of the benefits of doing an entirely custom combat system is that you can control what actions enemies will take in combat. RM2K3's built-in enemy behavior system is pretty limited, providing only a few controls for deciding to take one action over another. If you were determined enough, you could probably build a system in RM2K3 scripting which runs in between each battle action and sets switches to control the upcoming enemy action, but it would be very messy. In Forgotten Gates, the built-in behavior of the enemies is always "Do nothing", and I use scripting to decide what the enemy's action should be and then simulate the effects (show a battle animation, deal damage, etc.).

In the currently available demo of FG, there is a limited amount of actual intelligence to the enemies' action choices. There's a script event which calculates a tactical value for each possible action, then chooses one randomly with the more valuable ones being more likely. It takes into account things like how much damage would be dealt, what status conditions might be inflicted and whether the target already has them, the probability of missing, etc. As it currently stands, this leads to enemies that largely fight to win, albeit in a short-sighted way. If you've played the demo and run into a group of lizalfos, for example, you might have noticed that their opening move is almost always to spend most of their mana on a Fire Breath attack, because dealing damage to your entire party is a high-value tactical choice. Whether that makes the game more fun than simple random action choices is a matter which depends on both the preferences of the individual player and on the other balance choices of the game as a whole. I would argue that at the very least, this predictability that the enemies will likely choose the most difficult action for the player to deal with allows the designer to balance the game around that scenario, while simple randomness can cause the occasional total party kill in a game balanced around enemies' long-term average choices being easier for the player.

At any rate, the tactical greedy algorithm with weighted randomness has always been intended as just the core of my enemy AI, which I plan to build upon. The enemy behavior shouldn't just be to always try for a win as if they were controlled by a human opponent, they should behave in interesting and flavorful ways. I want to have enemies take into consideration things like what they and their comrades have done recently, what has happened to them (an enemy panicking and making a bad choice is certainly an option), and possibly even having special interactions between certain kinds of enemies. On top of that, the current narrator should have some influence on enemy behavior, with one narrator liking enemies to go for status debuffs, another preferring high-damage magic, etc. This will all be significantly easier now that I'm redoing the combat plugin in a DynRPG plugin; I'll have unlimited variable space to work with and the ability to work in an object-oriented fashion. A while ago I read a Gamasutra article (which I can't seem to find now, oh well) which mentioned graph editing programs like yEd can be used to create behavior trees and export them to a text-based file that can be easily read by other programs. Considering the success I've had using data exported from Excel for my combat plugin, that may be a useful avenue to explore for my enemy AI.

Of course, in all this I have to be careful that I don't wind up creating some intricate masterpiece of AI that's no fun to play against. X) Or almost as bad, no more fun than a simple random AI, which would mean I just wasted my time making it. A Gamasutra article about why designers should learn animation gave me this quote from Emily Short:

"It’s pointless to simulate anything in AI that you don’t also have a plan for communicating to the player - otherwise they don't see how clever you're being or (worse) what is actually sophisticated behaviour winds up looking like a bug."

In my case, I'm hoping to communicate to the player through literal tells: enemies will occasionally say things or the narrator will describe them doing things that hint at their next combat action. But, that's a topic for a separate blog post. ;)

Progress Report

Bugs, bugs and skill data

More bug squashing this month as I try out more skills and wind up finding things that don't work quite right. I wrestled for a very long time with the game crashing whenever a status condition wore off, with an error message that script had referenced a condition which does not exist. Weirdly, the exact point in code where this happened changed depending on things like message boxes I added to try and pinpoint what was going on. I still don't know exactly what the problem was, but I was able to prevent it by using RM2K3 scripting to remove expired status conditions instead of directly changing them within the combat plugin. My best guess is that changing the battlers' conditions in DynRPG threw off some internal system of RM2K3.

Another less mysterious bug cropped up when I tested Zelda's Eternal Wisdom skill, which gives the Bright condition to the whole party. Turns out whole-party-targeting skills didn't work right if the party has empty slots. Took me a little while to figure out the problem and fix it, but not nearly as long as the other bug.

One other big thing I managed this month was updating the skill data in both the RM2K3 database and the Excel spreadsheet I use according to the changes needed for the combat plugin. I'd been doing this on a case-by-case basis until now, since I hadn't fully figured out what the changes needed to be. Unfortunately I'd often forget to update something before testing a skill, leading to bug hunts that turned out to be merely faulty data. X) Since I seem to have the changes figured out pretty solidly now, I decided to update everything to prevent further troubles of that sort, even though I'll likely have to update them again at some point.

Game Design

Character spotlight: Deccus



Deccus lost his parents to war at an early age, and his grandfather, a knight of Hyrule, passed away before Deccus hit his teens. Deccus found himself out on the streets after that, and turned to thievery to survive. Later on he managed to apply those skills to a somewhat less dishonorable profession: treasure hunting. Despite his checkered past, Deccus became a valued member of the Resistance against Ganondorf, and today is considered a respectable merchant (who primarily sells curiosities he "liberated" from dungeons).

In Forgotten Gates, Deccus is a very well-balanced character with no outstanding strengths or weaknesses, although the fact that he wields a sword and shield for weaponry tends to give him an effective boost in defense at the cost of versatility. His element is Forest, making him strong against Light and Water, but weak against Fire and Shadow. His skills revolve mainly around status conditions, either buffing his allies or hampering his enemies. He does have one spell called Canopy Storm causing widespread Forest damage to all enemies, and a Bamboo Trap intercepting the next direct physical attack made against him.

Deccus's special ability is Steal. It's pretty much what you'd expect, especially if you're familiar with such from the Final Fantasy series: he targets a single enemy, and has a chance to steal an item from them, with the probability of success and type of item depending on the enemy. Just to make it a little more interesting, though, I invented a related mechanic: disarms. Certain enemies can be disarmed of their weapon(s) when Deccus steals from them, essentially weakening them. There are a couple other ways to disarm an enemy besides Deccus's Steal ability, but Steal is a relatively consistent and cheap (no mana cost) way of doing it, plus you get a weapon with it.

As a side note, you would not believe the hocus-pocus I had to go through to implement disarms in vanilla RM2K3. X) It involved having the disarmed versions of enemies present but hidden, and switching to them when the enemy is disarmed. This meant anything I did to the regular version (damage, mana consumption, etc.) had to be done to the disarmed version as well, and I had to check which version is visible when doing things like battle animations. Also, since RM2K3 allows a maximum of 8 enemies in a combat, I could manage a maximum of 4 disarmable enemies, and if there were that many there couldn't be any non-disarmable enemies. Now, thanks to DynRPG and the DynBattlerChange plugin I made, I can simply transform an enemy on command.