Positive Progress

In keeping with the positive spirit of progress, here are a few more things I've accomplished on my RPG lately:

1) I think I've filled out one of my character's skill lists - with a full window of 16 skills - which is a big (albeit early) step toward conceptual completion (and it's pushing me toward completing the other characters' skill lists). I've also pulled off a neat little trick in the course of implementing some of those skills - using states, and a plugin to change the default Attack command that appears in battle. I'm aiming for some amount of variety across the seven playable characters in my game - I don't want them all to feel the same. I haven't worked out all the details yet - because they're narrative characters (like in FFIV) and not figureheads (like in FFI) - but I'm hoping to give the player some choice in the ultimate lineup of their final team.

This particular character is an archer, and I don't want to spoil all the surprises, but her fighting style is heavily influenced by the Ranger profession in Guild Wars. I've successfully implemented a couple of "stances", and a few "preparations" (e.g., poison arrow, fire arrow). Instead of one-off special attacks, these are technically states that can be applied to temporarily modify this character's regular attack for a limited number of turns. It's a fun way to fight, and it gives her a unique playing style that hasn't been duplicated by any other characters in my game so far.

2) As irreversibly enmeshed into the MV iteration of RPG Maker as I am now, I could still rant at length about the things that irritate me about it, mostly tied to its dedication to mobile gaming - which requires streaming resources, and often results in sloppy gameplay, with the tradeoff of having to live with either a lot of jerkiness or loading screens. Thankfully, the Preload Manager + WebAudioCache combination of plugins has solved (to an acceptable extent) the BGM Delay issue I was having; although there is still no (and will probably never be) a solution to the not-so-"instantaneous" map transfer delay problem that's been particularly hounding progress on my other game, Ascension.

But I was becoming frustrated with even the regular screen fade transitions, when I loaded up VX Ace, and having used MV exclusively for a long time, the consistency and reliability of the smooth transitions in the older program absolutely amazed me. After some testing, I discovered that out of the box, MV's post-transition screen fadeins are often jerky, while using the Preload Manager (which is mandatory for syncing the BGMs in your game) causes the transition to pause a little bit between maps while the game does its loady thing. But what's annoying is that the game doesn't actually pause, it just hangs for about half a second, and then, as if trying to catch up, completely skips the fadein more often than not.

Perhaps a casual player wouldn't even notice it, but as a developer and lead tester, it began to drive me crazy. Is it too much to ask for a program that doesn't look buggy when you play it? Anyway, I found a workaround, even if it meant redoing all the map transfers in my game. In case you're interested, all you have to do is give up on the fade that's built in to the Map Transfer event command. Use a manual Fadeout before the transfer, and a Fadein after, but stick a 30 frame Wait command between the transfer and the Fadein to give the game time to catch up, before it moves on to the fade. Give it a try. The result is consistent and reliable fades. As somebody with OCD, it makes me much happier.

3) In my game, I have two skills planned that are based on the Warp and Exit spells from the first Final Fantasy. The difference between them is that Warp will send you back one floor, while Exit will send you all the way to the start of the dungeon you're in. They're good "quick escape" skills, also useful as a way to transport the player out of a dungeon once it's completed, without having to backtrack all the way to the entrance, and in lieu of thematically-appropriate dungeon-end teleports (as encountered in some dungeons in Final Fantasy). And, in the spirit of Dragon Quest's inclusion of skills that are useful outside of battle, I also want them available as shortcuts for use in towns and potentially on the World Map as well.

The Exit skill was easy enough to implement, by storing map and location info in variables every time the player enters (or exits) a town or dungeon. The Warp skill was a little trickier, however, as it needs to trigger on each floor, and I also want the player to be able to "stack" warps to travel multiple floors (if they have the resource points) - so the game needs to remember where the player has been and in what order. And rather than allocating a specific number of variables, I figured it would be more versatile to resort to storing an array inside a game variable, like I did in the course of implementing my Wardrobe Manager - although it involves more trial and error since I have to access the contents of the variable using script calls. But it's working!

4) On the subject of clever implementations involving skills useful outside of battle (although these ones are directly related to battle), I've just completed another challenge. One of the foundational skills in my game is a skill called Hunt, which gives the player the ability to force a random encounter (provided one is possible on whatever tile the player is standing on). This may not sound like the funnest skill, but I intend for it to dovetail with my game's encounter system - I'm just not sure exactly how...yet. In any case, it can be used to save the ambitious player time and embarrassment walking around in circles, should they want to fight enemies to boost their characters' levels, or collect special item drops.

Anyway, I have a couple of other skills planned that are in that family, one of which is directly inspired by the Repel skill from Dragon Quest, which reduces the random encounter rate (in that game, primarily to avoid wasting time fighting enemies below your level). But the one I'm most excited about is the one I've just programmed, which is a "Bait" skill. In many Final Fantasys, there are certain rare enemy encounters - especially in late-game dungeons - that promise valuable rewards for the persistent adventurer. The prestige awarded by these encounters (going all the way back to WarMech, if not earlier) makes them alluring, but I've never been fond of having to play the odds.

To wit, the best player could walk up and down the bridge in Sky Castle, battle 60 troops of enemies, and not encounter WarMech once, all on account of bad luck. This might be justifiable in a multiplayer online game, where you have a sort of players' economy, but at a certain point you have to just throw your hands up and say, "come on, already!" That's why, although I think these encounters should still be earned (which is why the Bait skill will be a late-game acquisition), I think there should be a point where the game says, "ok, you've earned this." And that's where Bait comes in.

Bait works just like Hunt - by forcefully initiating a random encounter - but not before performing a tricky bit of code math. I already had to add in some new functions related to the game's back-end encounter variables for the Hunt skill, in order to determine when the Hunt skill should be able to be used. But for Bait, I went even further, by taking the list of applicable encounters on any given tile (as determined by the developer on the map properties) and reversing the probability "weights" of each troop, so that when you initiate the next encounter, the common enemies will become rare, and the rare enemies will become common. You'll have to excuse me if I think that's just brilliant! And it works! Hey, I'm pretty excited.

(Now, if I could just pick up the slack in the mapping department...)