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

Progress Report

Still here!

It's been a year since I've posted any updates for this project, so I'd like to give a quick signal that yes, it's still on my to-do list and I have every intention of completing it...eventually. X) It will probably take years more, maybe even decades, but I haven't forgotten it (no pun on the title intended).

Last time I posted, I said that I was back-burnering Forgotten Gates in order to focus on rebooting a role-playing community I was in charge of. That effort has been largely abandoned because it became clear that not enough people were interested in participating. It ultimately doesn't matter if you have a great role-playing system or a huge, detailed virtual world, what's most important for a role-playing community is PEOPLE, writing stories together. Besides, as it happens, some of the players from that community had already established an alternate version of it, so in a sense that's the reboot.

Despite what I say about the community of people being the most important thing and the fact that I've scrubbed the overall project, I'm still working on something that I started from it: a Unity application to implement a role-playing system I invented. I call it the Awesome-Sauce Conflict Resolution System, and it's a relatively small ruleset inspired by the Prose-Descriptive Qualities System by Atomic Sock Monkey Press. There are probably better frameworks than Unity for it, especially if you want to incorporate the story-writing along with the dice-rolling and have a persistent world instead of session-based, but I want to complete this application if only for what I'm learning by doing it. I got stuck for quite a while on the details of how to send network messages between game instances -- the networking tutorial on the Unity website is geared toward their automatic system for keeping elementary variables and physics objects synchronized for simple action games -- but I'm finally past that hurdle and building up steam again. I'll probably post the ASCRS app here on RMN when I'm done with it, if only for other game devs to have an example of how to do certain things (not that my work is a perfect standard to go by, but I do try to make it structured).

In news that is perhaps more relevant to FG, Triforce MUCK, the role-playing community from which the characters and setting of FG are drawn, has had a rebirth of its own! After a long period of being offline due to the expense of renting server space to run a MUCK, the person in charge hit upon the idea of using a Slack group instead, and renaming it Zelda RPG. Slack is actually a pretty good environment for a role-playing community. People can chat in real-time on one channel, post "poses" (the RP term for the bits of story showing each character's actions in the current situation) on another channel, and scenes can proceed either as rapidly as the players can write when all involved are present and paying attention, or a round of poses every day or so as players come home, catch up on what's happening, and respond with their character's reaction. And it's free. :) It's also capable of taking written commands through plugins, which some enterprising members have used to allow pulling of text information from a wiki where we write character pages and such, and doing dice rolls. I've actually run a couple of scenes there that made use of the ASCRS (just the ruleset, not the Unity application), and people seemed to enjoy it. If you're interested in checking it out, here's the Zelda RPG website.

One other thing I might as well mention: there was another project that grabbed my time for a bit last year. In October of 2017, RPG Maker Web ran the Indie Game Maker Contest 2017, and I decided to throw my hat in since I was between jobs at the time. The result was a teamwork action-puzzle game called The What-Iffers in: Final Fancy. In some ways it has a similar story premise to Forgotten Gates: a group of role-players weave a story in one of their favorite game worlds, and you come along to watch their shenanigans both in- and out-of-character. Whereas FG uses other players' characters (with permission), however, in The What-Iffers I exclusively star my own personal characters and portray them as if each has a separate player in real life. I have some vague hope of turning this into a commercially viable series of parody games, so of course I can't be using other folks' characters in it. ;) Check it out if you've got a free hour or so -- halibabica seemed to like it well enough for what it is.

Game Design

Character spotlight: Arumarg

Arumarg is a guard in the royal army of Hyrule. He takes his job seriously enough to have saved up and bought himself extra armor, which occasionally causes people to mistake him for a full-fledged knight. Not surprisingly, Arumarg is a thoroughly good-guy character, protecting and serving the populace with humble strength. He has a particular bit of history with Shemri, whom he carried to safety on his horse after she broke an ankle in an especially fierce fight with a certain lizalfos. Because of this incident, Shemri considers herself in life-debt to Arumarg, and is on the lookout for opportunities to save his life in return.

In Forgotten Gates, Arumarg is a physical tank character. His element is Light, making him strong against Water and Shadow, weak against Forest and Spirit, and neutral to Fire. Wielding sword and shield, he can take plenty of punishment and dish out a fair bit in return, although his low agility means he doesn't get as many opportunities to hit back as some other fighters. His skills are almost entirely physical as well, including a stunning shield bash and a disarming strike. The only half-exception is Light Blade, an attack which imbues his sword with Light magic for extra damage.

Arumarg's special ability is Mask, based on the concept of The Legend of Zelda: Majora's Mask. Throughout the adventure, Arumarg will acquire masks which contain the spirits of ancient heroes, one for each of the main races of Hyrule (besides Hylian, which Arumarg himself already is). By putting on a mask, Arumarg will channel one of those heroes and undergo an instant class change, including a shift to a different element and a special weapon. These new forms will have limited skillsets -- possibly just the basic Fight and a plain elemental attack spell -- but they'll allow Arumarg to adapt to the needs of any encounter.

Progress Report

Slow month

This month I have accomplished almost nothing for Forgotten Gates. All I did was turn Mituni's portrait of Arumarg into a faceset image, which you'll see in the design post after this. The reason for my lack of progress is that I've been devoting my time to a different project: the rebooting of a role-playing community of which I am in charge. It's fallen to virtually non-existent levels of in-character activity, so we decided if there's ever a time for a change, it's now.

Of course, you didn't come here to hear about some other project, so here's what it means for FG. I'll probably devote very little time to FG until my role-playing community is back up and running on at least a basic level, since I can expect to accomplish that goal within a reasonable time-frame and it benefits others when it's done. I'll probably also put this blog on hiatus until I have stuff to report again. My apologies to anyone who looks forward to my posts, if such there are.

Game Design

Matching concepts to elements

One design problem I've been chewing on is how to decide which of the game's six canonical elements different enemies are associated with. We're going to need to know the elemental rock-paper-scissors of Forgotten Gates for this discussion, so here they are for reference:

Light beats Water and Shadow
Forest beats Light and Water
Fire beats Forest and Shadow
Water beats Fire and Spirit
Shadow beats Forest and Spirit
Spirit beats Light and Fire

For some enemies, the choice of element is quite obvious. An enemy that's constantly on fire, like a Torch Slug, should have Fire as their element. A plant enemy should have Forest. An aquatic enemy should have Water (with maybe a few exceptions like the electric jellyfish Biri). A great many of the standard enemies in the Zelda series are spooky undead, which puts them squarely in the Shadow category.

The other elements are a little harder to find enemies for. There aren't many enemies in Zelda lore strongly associated with Light...but if you associate Lightning with it, that gives you a few options, like the aforementioned Biri. Spirit is a tough category too. Ghosts are an obvious choice, and to pad it out a bit (as well as give Spirit magic something more physical to work with), I've chosen to associate Spirit with Air, so flying enemies would likely have Spirit as their element pretty often.

I've already let slip a little in that last paragraph what the tricky part of all this is: shoe-horning enemies associated with other concepts into the strict six elements. Light and Lightning/Electricity are not the same, but they're close enough for my purposes...probably. Spirit and Air is more of a stretch. And there are some concepts which create some rather interesting difficulties.

The best example is probably the concept of Ice. At first glance, you'd think, big deal, just lump it in with the Water element. Ice IS Water, after all! But then you start to think about the elemental interactions if Ice = Water. Light beats Ice? Okay, that's believable enough, it shines right through the Ice. Forest beats Ice? Hmmm, not quite so sensible, a good frost is usually rather unhealthy for plants. Ice beats Fire? Whoa, wait, maybe offensively that would work (a dusting of snow would tend to weaken a fire sure enough), but defensively, Ice should be weak to Fire.

There are several approaches I can think of to resolve this conundrum.

  • Simply don't use enemies associated with concepts that are difficult for my elemental wheel. I don't like this solution because it rules out too many cool and iconic Zelda enemies, and c'mon, any Zelda game past the NES era has to have at least one ice dungeon in it, right? ;)
  • Give particular enemies defensive weaknesses and strengths that do not match the elemental wheel. This actually would not be too difficult programmatically; my system is already set up to specify each enemy's exact vulnerability to each of the six elements. I could simply set an Ice enemy to be weak against Fire, strong against Forest, and whatever else makes sense. I could not, however, make an Ice attack be strong against a Forest target, because the target would treat it as Water. This approach also means the player winds up having to learn a lot of exception cases to the typical rules.
  • Expand the list of canonical elements. If there actually was an Ice element distinct from Water, then I could make it work as sensibly expected both offensively and defensively. The more elements there are, though, the more complex and hard to balance things become. Besides, the current elemental wheel is based on the powers of the Six Sages, an important theme in the source game.
  • Match the concept to the canonical element which gives the most sensible interactions, regardless of whether it's the most intuitive match. With the example of Ice, we definitely want it to be weak against Fire, which means it should be associated with either Forest or Shadow. If Ice = Forest, then Ice beats Light and Water, is beaten by Fire and Shadow, and is neutral toward Spirit. Not the most sensible matchups. If Ice = Shadow, then Ice beats Forest and Spirit, is beaten by Light and Fire, and is neutral toward Water. Actually, that's not bad...and there are some intuitive reasons for the association. Shadow and undeath are somewhat associated with cold, and we've all heard of black ice, right? n.n; Of course, that's only one concept rectified.

Despite the awkwardness of it, I'm leaning toward that last solution. The main other concept I can think of that would have to be linked with an element is Rock/Earth. Originally I was figuring on lumping that with Shadow, since Rock creatures might often be found in caves, which are dark. Going by elemental interactions, though, it doesn't make that much sense for Rock to be weak against Light or Fire, and it would make a certain amount of sense for it to be weak to Water. So how about Spirit? That's strong against Light and Fire, which makes sense, and weak against Water, which also makes sense...Rock being weak to Shadow is a little more of a toss-up, but if Shadow is associated with Ice/Cold, it makes a certain amount of sense. Rock being neutral to Forest is also a toss-up. You might actually expect Rock to be strong against Forest, as plants don't grow well in rocky soil...although some plants do thrive on rocks, and can split them with their roots over time. Earth definitely ought to be weak against Forest, but I think there are a lot more Zelda enemies formed of hard Rock than loose Earth.

And finally, you occasionally run into enemies that don't easily associate with any of the canonical elements. Take Wolfos for example. They live in the Forest, but the only elemental interaction of Forest which makes much of sense for them is Fire (burn that shaggy pelt!), and even that is a little weak. Moblins are a similar story. For these cases, I may well consider them non-elemental, and give them neutral interaction with all of the elements.

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


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.
Pages: first 123456 next last