The What-Iffers in: Final Fancy

The What-Iffers in: Final Fancy was an entry for RPG Maker Web's Indie Game Maker Contest 2017. The basic idea was to make a game using any engine of the RPG Maker series within the span of one month. I was intrigued enough by the concept to put aside my longer-term projects and give it a go. Here's a breakdown of what went right with the project, what didn't go so well, and what it might lead to in the future.

What Went Right

Keeping the Scope Small

I knew from the get-go this would have to be a pretty small game. Even still, there were things which I pondered early on, but decided to cut. If you've played the game, you've probably noticed that two of the heroes, namely Shemri and Aubrey, move faster than the other two. This came from...well, really it came from the fact that those two characters are good runners in my mind, and I wanted the game to reflect that. X) A case of the story dictating the gameplay, which is not generally a good practice. Anyway, originally I was trying to come up with such secondary characteristics for all of the characters, and to distribute them in a balanced way such that each hero shared a characteristic with one other. The main other one I'd thought of was to make only John and Shemri capable of pushing boulders, since they're physically stronger characters than Aubrey and Cherry. But I couldn't come up with compelling attributes to share between Cherry and Aubrey or Cherry and John. Aubrey and Cherry can both work magical devices? John and Cherry can both magically block against hazards? I'd have to think up a different main ability for John if I used that last one, and the blocking would have to become a passive ability. So after a while spent pondering, I made the call to just forget about giving everybody shared attributes. I allowed everybody to push boulders, but I still did give Shemri and Aubrey higher speed, which I think is good for the design. That little extra zippiness helps Aubrey and Shemri use their main abilities effectively, and balance between heroes isn't a strictly necessary thing.

I also pondered making more types of enemies, and letting players kill them in various ways. That possibly would've fed into the secondary attributes thing -- John and Shemri could've been able to deal more direct damage than Aubrey and Cherry, for example, and Aubrey and Cherry could've had some measure of resistance against magical attacks. But that would start turning the game into a tactical combat game, possibly even something that would need to be turn-based instead of direct-action. It might have been a good game, but not one I could make all on my own in less than a month.

Getting RPG Maker MV

I didn't have RPG Maker MV when the contest started, and I didn't think I'd strictly need it. After all, the game I was envisioning didn't need anything that couldn't be done in RPG Maker VX Ace. But after doing some experimental eventing, I determined that I wouldn't be able to achieve some of the effects I wanted without going into plugins...and as long as I was doing that, I figured, I might as well make the plugins be JavaScript. JavaScript is a much more popular language than Ruby, after all, so it would be more valuable to be able to add that to my resume.

So I ponied up the cash for the Humble Bundle (again, not that I can complain since it was still less than the base price of the software and gave me a few games I didn't have before to boot) and downloaded MV. For the most part, it doesn't seem terribly different from VX Ace, although I'm not an expert on either. I definitely like the character generator of MV more, the 3/4s view of faces is far easier on the eyes than the uncanny straight-on one VX Ace has. I suppose that's probably just a matter of the source images used, but as someone who doesn't have the artistic skill to make my own (and if I had probably wouldn't have had time for it in this context), I greatly appreciated it. There's also the fact that MV's deployment options are much more flexible, including the ability to run it the game in a web browser. You get some delays on music that way as the browser downloads the big sound files, but still, when people can try your game with a single click, without the psychological barrier of having to download it and unzip it to their hard drive, that's gold for a game developer.

Using Available Resources

As mentioned above, I don't have much talent for making graphical resources, so I was stuck using what I had, mainly the RPG Maker MV RTP. This limited what the game could become, of course, but it also informed it. For example, the main reason fireballs are used in the game is because the fireball graphic is the best thing I could find for a projectile object. I struggled to find an object to shoot the fireballs; initially I had envisioned some sort of turret or a wall column with an opening, but I couldn't find anything like that. So I settled for the Ifrit monster graphic from VX Ace. It looked a little funny being dragged into MV since the VX Ace uses a smaller tile size, but the shrimpiness (and commonness) is easily accepted if I call it a fire imp instead of Ifrit. ;) Similarly (although inversely in some ways), the ice golems in Final Fancy are quite obviously your basic slime monsters in appearance, a fact which I lampshaded in dialogue when they were first introduced. I just needed an obstacle that could be removed by Cherry's fireball ability; I'd initially thought of briar patches, but I couldn't find anything like that, so I made it a monster that was vulnerable to fire. I'm glad I did, too; it led me to making it not only an obstacle, but a hazard (stepping within one space of an active ice golem is instant death), which in turn made possible one of the game's most devious and memorable puzzles. >) The takeaway is, if you run up against a wall in development, it may be better to go sideways than to try to break through it.

Learning JavaScript

As mentioned above, the main reason I got MV was so that the time and effort put into this project would teach me something about JavaScript as opposed to Ruby. I certainly did learn a decent bit about the tricks and pitfalls of JavaScript over the weeks I spent hammering out the game's systems. Unfortunately what I did doesn't match too strongly with what JavaScript is usually used for, which is web-based applications with lots of GUI stuff, but at least I can now tell prospective employers that I have worked in JavaScript before.

What Went Wrong

Not Much Relation to Parody Source

I billed Final Fancy as a parody of the Final Fantasy series, but in the end there aren't actually many references to Final Fantasy. Mainly there's just the fact that there are four Heroes of Light with character classes of the sort you might see in a Final Fantasy game. You might say that Final Fancy is more a parody of fantasy RPGs in general, and even there the time spent poking fun at things is comparatively small.

A big part of the reason for this is that, as mentioned above in Using Available Resources, I didn't have the time (or the talent for that matter) to create any original resources. If I'd wanted to reference moogles, or cactuars, or any of the other things Final Fantasy fans would recognize, I'd need to make drawings of them, quite possibly even animations.

All this isn't to say I wish I'd tried to parody Final Fantasy more; that would've resulted in not completing the game in time for the contest deadline, if ever. I guess what I'm saying is that perhaps I shouldn't have referenced Final Fantasy at all. But then, I don't think I would've gone for the game concept at all if I hadn't had something specific to shoot for, so maybe the fact that I missed that mark doesn't matter so much in the broad scheme of things. X)

Not Enough Research Into Available Plugins and Documentation

It turns out the MV helpfiles don't include much to get plugin makers started. In order to make a JavaScript plugin for MV, it's not enough to understand JavaScript; you have to know what JavaScript functions are available to interact with the MV system. I spent a lot of time trying to get a clue about this simply by studying the base JavaScript libraries that MV runs on.

Much later, I found a thread on the RPG Maker Web forum that specifically lists the most commonly needed JavaScript function calls. I'd missed it before because it wasn't in the MV tutorials board, nor the JavaScript learning board, but the general MV support board. That helped significantly once I had it, although it wasn't as complete as I'd hoped, and it did contain at least one code snippet that didn't work as advertised. I think whoever put it in there copy-pasted it from the base library without checking to make sure it worked in another context.

I also didn't do as much research into existing plugins as I should've. I found a site (linked to from RPG Maker Web) that attempts to be a master list of all publicly available MV plugins, and it has HUNDREDS, so obviously I can't be wasting my time looking through all of those, right? :P But I should've remembered that Yanfly is famous for providing generally-useful plugins and looked him up sooner than I did. It might have saved me a bit of time wrestling with stuff like how to stop the player from moving while I reset the stage.

No "Hello World" Starting Point

Related to the above trouble with finding documentation, I didn't really have a solid "Hello World" basis to my plugin-making efforts. For those not familiar, a "Hello World" program is a bare-bones simple program that does only what is necessary to show some message, traditionally "Hello World". Making such a program allows you to prove that you have a working program, because it shows the thing you expected to see. From there, you can expand the program in chunks to do what you really want, stopping to test it in increments to make sure it's still working.

Since I didn't know how to make an MV plugin show a message, or affect the game in any other noticeable way, I couldn't really make a "Hello World". So I ended up writing a lot of code in the meantime based on a vague understanding of how things should work, and when I finally reached a point where I thought I had something that ought to produce a noticeable effect, it failed to work. The really aggravating part of all this is that JavaScript (at least in the context I was using it for) seems to fail more silently than most languages. If there's an error that makes the script senseless to the interpreter, it doesn't tell you that, it just completely ignores the script and goes on its merry way. It wasn't until I tried "commenting out" huge swathes of code that I was able to make the game respond to my plugin at all, and from there I narrowed it down to find the errors.

By the way, in my searches for answers about various MV plugin matters, I did eventually run across a very handy command for showing messages:

window.alert("message here");

Always Thoroughly Test Your Final Deployment

I was rushing to get the game completed in time for the contest deadline. The last three stages and the ending cutscene were all done on the same day, plus various little tweaks that I thought worth doing under the circumstances. When I finally got the game to a state I was willing to call "done" for contest entry at least, it was 2 AM in my timezone, and this was the day Daylight Savings Time had ended to boot. There was still nearly an hour before the actual deadline, but I decided it would be unwise to tempt disaster by putting off my submission. Besides, I wanted to get to bed. :P

Well, turns out I should've at least played through the game once more while the upload was going. =.= I did start the deployed version up to make sure it worked, but I didn't go far into it. If I had, I would've soon discovered that it crashed due to a missing animation, and the sound files which were used by my plugin had also not been included in the deployment. Instead, I found out the day after, when it was too late to resubmit, that the version I'd put out was defective. I was able to sort of work around this by putting a working version on my personal web server and linking to it on itch.io game page for Final Fancy, but in accordance with the rules of the contest, Final Fancy was disqualified. It hardly matters, I'm sure it wouldn't have come anywhere close to winning anything...although I'm also sure there were some people who downloaded the defective version without seeing the other link, hit the crash, and tossed any interest in the game.

What Does the Future Hold?

As implied by the composite title, The What-Iffers in: Final Fancy is intended as the first in a series of games. The basic idea is to parody some famous game, but make the gameplay different if possible. I'd really enjoy making a tactics game based on Team Fortress 2, which I could call Team Fortification 2.9. ;) That would take a minimum of 9 characters though, ideally a few more, and I'd like to introduce new characters to the series gradually. It would also be a challenge to write the AI for such a game. Another idea I like is making a noirish parody of Super Mario Bros. in the playstyle of Ace Attorney. X) Imagine "Pauline" (it would actually be one of my characters dressed to reference her of course) cast as the sultry and mysterious lady client, and "Luigi" as the hard-boiled detective haunted by his brother's disappearance. And he would have Tourette syndrome that causes him to occasionally shout things that rhyme with "OBJECTION!" XD Unfortunately I don't have more than the theme for this so far, and for a detective story, plot (especially the matter of how the crime was accomplished and how to give the player just enough info about it to take the next step) is extremely important. Also, for a visual novel-style game, quality illustrations are very important, so that's a project I'd have to tackle with the help of a competent artist.

That last bit is a critical consideration for nearly any game I might attempt. The main reason I chose to parody Final Fantasy with my first What-Iffers game is because it made it possible to match RPG Maker MV's graphical resources with the theme. I think probably the next thing I might attempt is a Star Fox parody, which I could call Star Furs (amazingly, nobody seems to have grabbed this name already). Since Star Fox was a pioneer 3D game with extremely simple models, I could get away with making crude graphics myself and say it's to reference the classic look. ;) And if The What-Iffers ever takes off into a commercial series, I could remake it with better graphics and call it Star Furs 64. XD As far as gameplay, I'm thinking of a top-down shoot-'em-up, which admittedly isn't too different from the game it's parodying, essentially they're just the 2D and 3D sides of the same coin. I think it could be sufficiently unique if I threw in an original mechanic, though, like...your team flies in formation around you and you control the formation with the right control stick, or something. It'll take prototyping to work out.