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

Progress Report

Irina + DynRPG plugins

I made some decent progress this month, although some of it was unplanned. I started out with the primary goal of implementing the playable character Irina. Her special ability would be a relatively easy one to make, and with her and Noab added to the game, we'd have one character of each element. :) Should make for a good point to release a new demo, right?

Irina's Paint ability was relatively easy to implement, although I did run into a few snags along the way. Most notably, I had to rethink how it would be animated. Originally I'd envisioned Irina going up to the target, much like with a weapon attack animation, waving her paintbrush at the air over the target, and bringing the status symbol for the condition she's attempting to inflict into being. However, there's a technical nuance that made this impractical: battle animations that involve a hero directly interacting with a target are aligned with the bottom of the target sprite, so that it looks like they're standing on the same ground, whereas battle animations for status effects are aligned with the top of the target sprite, since they're speech balloons that should appear above. I couldn't do both in a single animation. The solution I eventually settled on was to make an animation that Irina does from her regular position, creating the status symbol painting near herself and then wafting it toward the enemies in general. The targeted enemy then gets that symbol briefly shown over themself as a natural consequence of being inflicted with it (or shows the Miss symbol instead if the attack failed).

Irina's regular skills are mostly water-themed magic spells, so I was able to make heavy use of the RTP battle sprites and animations to create them. Some of them are almost straight uses of the original animations, merely shrinking the sprites and pulling them closer together to match the smaller-than-typical-for-RPG-Maker enemy sprites I'm using in this game. Others were a bit more original, like blowing up the wave animation to maximum size and having it gently move up from the bottom of the screen for the skill Waterlog. The RTP animations even motivated me to rename one of Irina's skills from Water Blast to Bubble Burst, simply so that I could use one animation for that and save another one for use in Fallon's Cold Splash skill. ;)

While I was working on the battle animations I was reminded of the necessity of making "reflected" versions of some of them. Since my highly custom battle system does pretty much everything through scripts, including battle animations, any battle animation that has any noticable left/right directionality and could be reflected will need a separate version, because RPG Maker 2003 doesn't allow scripters to access its built-in mirroring capability. ...BUT CAN WE MAKE IT DO THAT? 8o After a little investigation, I determined that DynRPG does have access to the data flag which determines whether a given battle animation is mirrored. So I set about making a plugin to give scripters the ability to make use of that. It was a little trickier than I'd first envisioned; DynRPG doesn't have a callback to alert the plugin when a battle animation is starting, so I had to check every frame for whether an animation is being played and keep careful track of when one starts and ends. Then I noticed the first frame of a given animation wasn't getting mirrored, so I had to switch to using the onDrawBattler callback instead of the onFrame callback. There was also some difficulty with frames occasionally being skipped which I had to account for. x.x But in the end I cranked out the DynAnimationMirror plugin, and I expect it'll save me a good amount of time in the long run.

So, I got Irina set up, and it was looking like I might actually be able to release a new demo by the end of the month. :D But since I now had more characters than would fit in a party, I needed a new system: a way for the player to choose which characters they use in the quest (I was using hard-coded switches for my own testing). So I added a new map where the player can pick up little markers and place them on the heroes they want to use. That was also a little trickier than it first appeared -- what happens when the player tries to place a marker on a hero that already has a marker, for example? But I finally got that working properly...yesterday. I could have tried to throw together a demo release today before making this post, but I probably shouldn't rush it...especially since I ran into an actual game-crashing bug while testing this morning. X) And the new equipment-deterioration system could make the game kinda unplayable since there's currently not much way to acquire new weapons. e.ea

Oh, and I also updated the DynParams plugin with a new comment command that lists the currently waiting parameters, because I introduced a new bug while working on the hero-choosing system that turned out to be caused by unused parameters. Busy month.

Game Design

More weapons?

I'm running pretty low on well-established design aspects of the game to talk about, so this month I'm just going to mull over something I've been pondering lately: sooner or later the game is probably going to need more weapons. e.ea I don't just mean the game as it's currently presented in the available demo, where each hero starts with a single weapon (and in Link's case, a shield) and they use just that. I mean I'll have to fill things out a bit further than I have planned so far. Right now my design documents hold ideas for new, stronger weapons that can be found in the various locations that will be visited. For example, in the oriental-style land of Yamakage, longsword wielders will be able to find katana, dagger wielders will be able to find butterfly knives, etc. It's actually a little sparse as-is; most weapon types only have a single extra weapon to be found in each land beyond Hyrule, if even that (Yamakage currently has no axe-type weapon, for example). I came up with the planned weapons waaaaaaay back towards when I first started this project.

Besides just having a bit of variety, the main reason I've been thinking lately I'll need some more weapons is so that enemies can drop cheap ones. Right now all weapons have decent durability, lasting for 20 uses (in my development version that is, equipment deterioration is a feature I haven't released in a demo yet). If I have enemies frequently drop weapons like that, equipment deterioration won't mean much because the player will always have more stock than they can use anyway. However, if most enemies drop lower-quality weapons, with both less power and less durability (I'm thinking 5 uses), suddenly we have a meaningful economy. Should you keep your strongest weapons equipped all the time, or use up the junky ones on weaker foes, even if it means taking an extra hit or two, to make it less likely you'll shatter your good sword in the middle of a boss fight? What if there's a shop in the quest, is it worth selling all your accumulated low-tier weapons for one high-tier weapon? If Shemri is in the party, should you just use the junk weapons as fodder for her Throw ability, or meticulously use them to the point of breaking first?

This would also allow me to match the weapons more organically with the enemies fictionally. Breath of the Wild did this with bokoblins and moblins using primitive weapons of wood and bone, lizalfos being more likely to have actual metal (but still comparatively shoddy) blades, guardian robots having special forerunner tech weapons, etc. I could occasionally even have the enemies themselves become weapons after defeated -- for example, deku babas become deku sticks -- although mechanically the only difference there is that you can't disarm the enemy during combat.

The downside, of course, is that more weapons means more work. X) I'll have to create animations for each hero capable of using a given weapon, sometimes more than once since some special skills involve weapon usage. It should be relatively easy copy-paste-modify work on the whole, but it's not non-existent. Also, while I did leave some room in the game database for expanding weapons, it's not that much -- just 10 total weapons of each type. That felt like plenty when I was only planning on around 5 weapons of each type at most, but I could easily exceed that if I'm making weapons out of monster parts and the like. If I have to rearrange the item database to make more room, I'll have to be very careful to update anything affected. I've already been burned before by that sort of thing, even though I do my best to use variable values instead of direct references to database stuff.

Progress Report

Noab's skills

Progress was fairly slow again this month. In addition to the Satisfactory run with my brother taking up most evenings, I was sick for about a week and a half near the start of the month.

What I did manage to get done was finishing Noab's skills. This was mainly a matter of creating animations. Graphics are far from my strong suit, but making them does tend to go a lot faster than coding. The biggest one was Goron Roll, which involved Noab curling into a ball and doing a spin-up, then blasting forward through one row of enemies and off the screen, then returning through the other row of enemies and finally skidding to a halt. I'd like to make a GIF to show it off, but I've never had any luck recording RPG Maker 2003 games, and similar trouble with other things -- I think it probably has something to do with my graphics card. e.e

Game Design

Character spotlight: Rizzen



Rizzen is the last of the legacy characters I mentioned who won't be one of the main heroes and may not be playable period. I sorta hate to do that since his player was the one who pointed out to me the existence of RPG Maker 2003, but he's long gone from the Triforce MUCK/Zelda RPG scene. That, and the character of Rizzen ended up dead. X) Including Rizzen now would make the story relationship between Forgotten Gates and its role-playing community of origin quite stretched -- for example, Rizzen died before Aubrey and Fallon even met.

Rizzen as a character was...a little hard to describe. He was an impetuous loner, sort of an anti-hero type. He sided with the good guys, but he was always doing things his own way and getting into trouble. He viewed Aubrey as a naive kid who needed protection and steering, and he often got into arguments with Shemri.

In Forgotten Gates, the plan was for Rizzen to be a jack-of-all-stats with a lean towards offense. He dual-wielded short swords, a style which none of the current playable characters use. His element was Fire, making him strong against Forest and Shadow and weak against Water and Spirit, and his regular skills had a dragon theme.

Rizzen's special ability was called Blade Combo, and it worked very similarly to Sabin's Blitz from Final Fantasy 6. The player would input one of several possible predetermined arrow key combinations, and if successful, it would trigger an associated technique, anything from a simple but strong single attack to an energy wave to stealing MP from a foe. The logistics of animations on this would be rather tricky, since Rizzen might have any type of short sword in EACH hand. X) I suspect I could manage it with some DynRPG magic, but I'm loathe to spend the time and effort for a character who'd only be available in non-story extra quests at best.

Progress Report

Noab's Tactics and DynBattlerChange update

I had another month with not as much progress as I'd have liked, though I did make some. My excuse this time is that my brother got me Satisfactory for Christmas and has been pinging me nearly every evening to continue our shared run in the game. Gotta make time for family, right? ;)

Another, more respectable reason is that I ran into some unplanned work on the project. I started out trying to implement the playable character Noab, beginning with his Tactics ability. The basic mechanics of it didn't take super-long, but I had trouble thinking of a good way to show to the player that the hero chosen by the Tactics ability was intercepting enemy attacks aimed at other heroes. So I asked for ideas on an unofficial RM2K3 Discord server. I mentioned that Final Fantasy 6 showed something much like what I wanted by having heroes literally move in front of each other to take hits, but that wouldn't be possible even with DynRPG, as I had discovered when making my DynBattlerChange plugin.

...Or would it? Cherry (the creator of DynRPG) pointed out that it is possible to change the locations of actors during a battle. So I went back to fiddle with DynBattlerChange, and of course Cherry was right. I'm not sure why I thought before that it didn't work; maybe it's because I was using the actor's database values for starting position and just didn't realize there were also variables in DynRPG for their current positioning mid-battle. Anyway, I spent a good amount of time updating and rereleasing DynBattlerChange. I not only changed it to be able to reposition actors in mid-battle, I added the ability to work with the actors by their party spot instead of their database ID and commands for checking what the current positions of actors and enemies are.

After that, I of course finished implementing Tactics by having the chosen hero moved forward slightly while targeted and moving them in front of whatever other hero would otherwise be hit by a given enemy attack. That in itself turned out to be a fair bit of work -- I had to add tracking for who the original target was for any given battle effect and update all the heroes' positions every turn according to whether they're the current Tactics target. Then I got through some of Noab's more ordinary skills.

Game Design

Witch Maple and getting rid of excess equipment

I recently implemented an equipment deterioration system which relies on a subset of the inventory set aside to represent single pieces of equipment -- weapons, shields, armor, etc. -- each with their own amount of remaining durability. Just this month I tackled the problem of what to do when the player overflows this subset by acquiring too much equipment. It's not something I expect to happen often in regular gameplay, but it does have to be handled when it crops up. When the equipment is bought from a shop, the solution isn't terribly complicated: just inform the player by how much they went over the limit, refund all the equipment-type items they bought, and let them redo their purchase from there if they wish. It's a little inconvenient to be sure, but I think it's good enough for a fangame working within the limits of RM2K3.

It turns out there's another situation that's not quite as easy to deal with, though: when the player acquires too much equipment through a non-shop situation, such as an enemy dropping equipment as loot or finding it in a treasure chest. In a game like Breath of the Wild, the player would just leave the new stuff on the ground or in the chest, and if they wanted to they could drop other stuff from their inventory to make room. RM2K3, however, actually provides no mechanism in the menu system for disposing of unwanted inventory. I could rig a system for cycling through the equipment one item at a time and asking the player if they wanted to drop it, but it would be clunky and arduous for both me and the player.

Just when I was starting to write up a description of my problem to ask for brainstorming in the Game Design & Development forum, another solution occurred to me. The Open Shop command in RM2K3 provides a sell-only option, so I could use that as a way to let the player dump unwanted equipment. They'd also be able to dump other stuff, but that seemed like an acceptable downside -- it wouldn't kill the player's chances in most situations even if they did get rid of some potions and stuff, and I could show a message explaining to the player that the idea here is they need to get rid of some EQUIPMENT. Problem solved!

While writing up the text for explaining this unusual situation, I thought of a way to make it a bit more fun and narratively sensible. Instead of explaining the system to the player directly and having the disposed equipment just disappear into the aether, I brought in the self-proclaimed "Great Witch Maple" from the Oracle games! Thanks to Mister Mike for his sprite rips, which I doctored up to match the style of Forgotten Gates:



When the player gets too much equipment, Maple floats down from the north to tell the heroes in her typical sassy fashion that they've hoarded too much equipment and it's lucky for them she's here to take some off their hands. Originally I was going to have her reset the player's money after the transaction so that it's really like they're just dropping the excess equipment, but that led to a difficulty with treasure chests: wouldn't the player be able to just leave the equipment in the chest in such a case? I tried to implement it that way until I remembered that the contents of the chest are randomly decided the moment the player opens them. e.e; That means the item they get will probably be different when they come back later. I almost went the extra mile to change that and record what the contents of each chest are when generating the dungeon, but then I figured, why not just have Maple pay for the equipment like a regular shop? :P Then I don't have to explain why she's not paying even though it looks like she is in the shop menu, and the player won't mind too much having to sell something from their overflowing inventory with no choice to just leave the new item and come back for it later.

Progress Report

Supporting systems for equipment deterioration

This month my work in Forgotten Gates has revolved around the equipment deterioration system I made last month. I mentioned in the previous progress post a laundry list of things that would need to be implemented: switching equipment mid-battle, reimplementing Shemri's Throw ability, preventing the player from buying too many equipment-type items from stores, and reworking DynWardrobe to play nicely with the equipment system. All those have been neatly tied up, although in the case of the Throw ability, I haven't fully implemented it, just set up the skill set which changes names according to the available equipment. There's one more area I'd forgotten to mention and which both caused me some trouble and gave me some fun: how to handle the player getting too much equipment through non-shop situations like enemy loot drops and treasure chests. I'm going to go into more detail about that in the design post right after this.

Game Design

Character spotlight: Ruto



Say hello to the princess of the Zora and Sage of Water! Ruto is best remembered for her bossy demeanor and usefulness as a switch weight and plot coupon throughout the Jabu-Jabu's Belly dungeon, and of course the subsequent uncomfortable joke at Link's expense of her deciding that she's his fiance. The character of Ruto has been passed to several players over the life of Triforce MUCK/Zelda RPG, some of whom I wasn't around for, so I can't speak to her entire history on there. My own experience was that she'd finally given up on Link and become a bit less flighty and more responsible, although she still had her eccentricities. I mainly interacted with her as a Zora character of my own named Adrian, who will probably be an NPC (and likely an adversary) in Forgotten Gates -- perhaps I'll do a spotlight of him in the future.

In Forgotten Gates, Ruto is comparatively jack-of-all-stats as the Six Sages go -- naturally they all have to have at least pretty good magic capability, and Ruto is no exception. Her element is of course Water, making her strong against Fire and Spirit, but weak against Light and Forest. She uses a trident which should look familiar to those who've played Breath of the Wild. ;) I was actually planning to make her a spear-wielder even before that came out, so that was a fortunate coincidence for me. On a side note, the process of creating the attack sprites for Ruto caused me to decide on a general change to the way spear attack sprites are drawn. Before they involved an awkward slight upward angle of holding; if I recall correctly, I made them that way back when I thought I'd be using RM2K3's weapon attack animations system, which involves smaller sprites. Now that I'm using battle animations for everything, I have more space in which to show the full length of a spear jabbing straight outward, which looks much more sensible. And in the case of the trident, trying to draw the symmetrical prongs on either side when the weapon was at a funky angle was a nightmare. X) I'll have to alter a few existing sprites to match this new style, but it shouldn't be terribly hard.

Progress Report

Equipment deterioration system

I didn't make as much progress in Forgotten Gates this month as usual. A large part of the reason for this is that I spent most of my free time for the first week playing Team Fortress 2 during their annual Halloween event. They have a mission system that rewards players for accomplishing tasks (mainly getting kills and other little objectives on the various special-event maps) with cosmetics and other items. But that's getting a little off-topic, the point is just that I had something of an excuse for being lazy and took it. X)

What I did manage to accomplish this month was to start up a system for having equipment deteriorate and break as it's used. I mentioned I was thinking of doing this in a design blog post quite a while ago, including a comment afterward that described a new idea I had about how to implement it. The basic concept was that I would have multiple items in the database as redundant versions of the same type of equipment, and track how much durability each one has left via variables. Well, when I went to actually do this, I realized that the maximum 5000 items would be eaten up pretty quickly if all of the equipment items had even a fairly small number of redundant versions, like 10. e.ea A lot of the equipment items I had planned were just blank slots for now just in case I decided to add in new stuff, but still, it was cramped.

So I came up with a small variation on that idea: I set aside 100 item slots as breakable equipment of any type, and I wrote a system in my DynRPG plugin to transform those into different items as needed. That way, the player essentially has a sub-inventory of 100 equipment items separate from stuff like potions and common items. The equipment items have their name updated every time their durability changes to show to the player how many uses they have left -- for example, 'Short sword (17)'.

I said earlier I started up this system because there are still some supporting subsystems I have to implement. The basic idea already works: equipment items lose durability at relevant events (when a weapon is used to attack or provide a boost to a spell, when the actor takes a physical hit while holding a shield, etc.), and when they reach 0 durability, they 'break' and are removed. In order for that to be a fair mechanic, though, I need to let the player equip new weapons mid-battle. My plan is to have a skill subset called Equip with skills mirroring the equipment inventory, so that when an Equip skill is used the related item is switched into the actor's active equipment (could get a little tricky for dual-weapon actors, but I'm confident I can work it out). Shemri's Throw ability will work similarly when I get around to reimplementing her. Buying equipment from shops will also require some wrangling on my part to make sure the player can't buy more than their sub-inventory can hold (although I expect they won't often have enough cash on hand to make that a problem). Finally, I'm going to have to create a special version of my DynWardrobe plugin (or more accurately, absorb it into my special Forgotten Gates plugin) to display the correct shield when a shield-using actor defends, since the item database number no longer directly indicates what kind of shield it actually is.

Game Design

Random monster pools

This post is about a new system I just implemented in Forgotten Gates. I'd decided it was time to replace my old monster ID system, which was RM2K3 scripting that took the ID of a monster group and set some variables to the IDs of the monsters in that group. I wanted to do basically the same thing, but in my game's special DynRPG plugin so that I could more easily create and maintain the data about monster groups as spreadsheets instead of hard-coded scripting. It occurred to me, though, that this was a good opportunity to make the system a little more flexible.

What I did was essentially add another layer to the grouping data which I called random monster pools. A random monster pool is essentially a set of monster IDs, of any size I like, along with odds for each of the monsters in it. For example, I could have a pool with deku scrub at odds 100, stalchild at odds 100, and poe at odds 50, making the poe half as likely to be used as the deku scrub or stalchild. I'd generally expect to make these pools reflect different difficulty levels of monsters in a given quest, but I could use other distinctions if I wanted to, say damage-dealers and support monsters. Then, these pools allow me to define monster groups not as rigidly-defined monsters (i.e. 3 deku scrubs and 3 deku babas), but as random combos (i.e. 2 monsters from pool 1, 2 monsters from pool 2, and 2 monsters from pool 3).

Even with the small number of monsters I've created in the game so far, this random monster pool system has already thrown quite a nice bit of spice into the game. No longer are you always running up against the same familiar groups of monsters (which so far have mostly been X amount of the same monster), now you'll encounter varied groups and have to adjust your strategy. Which monster is the highest priority to take out or guard against? Should you spread your heroes' attacks in order to take advantage of different elemental weaknesses, or focus on one monster at a time? What synergies do the monsters' abilities create with each other? (For that last question, nothing much so far I'm afraid, although I'm hoping that will improve as I create more monsters and skills).

This new system is the main reason I decided to go ahead and release an update to the game's demo this month. Check out the downloads section if you're interested. :)
Pages: first prev 1234567891011 next last