Tuesday, February 16, 2016

Plugin: Terrain Battle Backs (MV)

The struggle to adapt my game to the latest version of RPG Maker continues, in spite of the frustrating limitations of developing a game inspired by classics that were designed for the desktop on a mobile platform.

You might remember my efforts at customizing the battle backgrounds automatically chosen based on terrain type on designated world maps in VX Ace, which I detailed in this post from two years ago (egads, has it really been that long?). That there isn't a built-in, user-friendly way to adjust these choices is one of those things in RPG Maker that amazes me.

Previously, I had opted to run a Parallel Process event on the world map to constantly check the tile ID (and thus, type of terrain) of the spot the player was standing on at any given time, in order to manually override the choice of battle background. It's a testament to how much has changed in the past couple of years that my first instinct this time around was to try and develop a scripted solution that modifies the way the backend code functions, instead.

So, I opened up the hood and jumped into the code. As a potentially relevant side note, MV is programmed in JavaScript. Trying to make sense of the tens of thousands of lines of code - and, particularly, trying to find the parts that do the stuff you want to modify - is no easy task. But I was able to track down the very function(s) that determine which battle background goes with which type of terrain. They are located (for reference) in rpg_sprites.js on lines 2530-2572. I'll copy them here:
Spriteset_Battle.prototype.terrainBattleback1Name = function(type) {
    switch (type) {
    case 24: case 25:
        return 'Wasteland';
    case 26: case 27:
        return 'DirtField';
    case 32: case 33:
        return 'Desert';
    case 34:
        return 'Lava1';
    case 35:
        return 'Lava2';
    case 40: case 41:
        return 'Snowfield';
    case 42:
        return 'Clouds';
    case 4: case 5:
        return 'PoisonSwamp';
    default:
        return null;
    }
};

Spriteset_Battle.prototype.terrainBattleback2Name = function(type) {
    switch (type) {
    case 20: case 21:
        return 'Forest';
    case 22: case 30: case 38:
        return 'Cliff';
    case 24: case 25: case 26: case 27:
        return 'Wasteland';
    case 32: case 33:
        return 'Desert';
    case 34: case 35:
        return 'Lava';
    case 40: case 41:
        return 'Snowfield';
    case 42:
        return 'Clouds';
    case 4: case 5:
        return 'PoisonSwamp';
    }
};
If you're not familiar with switch statements, they're basically extended conditionals, which check the value of a variable - each "case" basically tells the program "if this, then do that". The first thing you should note is that there are in fact two separate functions, corresponding to the two parts of the battle background - the bottom or ground section, and the top or wall section. This should be familiar to you if you've ever worked with the battle backgrounds, or looked at the associated image files that are named in these functions.

Another thing you might notice is the numbers that are being dealt with here. The function takes an argument (named "type") that, as you might guess, corresponds to the terrain-dependent tile ID, which is then evaluated in the switch statement. What's interesting is that these numbers are much smaller than the unwieldy tile IDs we dealt with before, which ran the gamut from 2048-4350. There's a rather obvious reason for this, that I must admit I discovered in an embarrassingly roundabout fashion. Those larger numbers are still relevant, as by using the Get Location Info event command, you'll find in-game that they haven't changed from VX Ace to MV. But for coding purposes, a little bit of math has been performed to make them more palatable. You can find that calculation in another function located on lines 5912-5915 of rpg_objects.js:
Game_Map.prototype.autotileType = function(x, y, z) {
    var tileId = this.tileId(x, y, z);
    return tileId >= 2048 ? Math.floor((tileId - 2048) / 48) : -1;
};
Basically, what this function does is take the tile ID corresponding to a location on the map determined by the x, y, and z (or layer level) coordinates, passed into the function as arguments. It then subtracts 2048 (since, I don't know why, but the IDs start at - and are thus offset by - a base value of 2048), and divides that number by 48. This makes sense because if you take the time to scrutinize, as I have, you'll find that there is a space of 48 numbers between each different type of terrain. These correspond to the various orientations of autotile placement which I have annotated in detail in my previous post for VX Ace.

But since choosing a battle background doesn't depend on whether you're standing on a "border" tile or a "center" tile (or what have you), you can essentially boil each set of 48 IDs down to a single terrain-dependent index. Which is exactly what the above calculation is doing (note also that if the tile ID doesn't fall into the expected range, the function returns a -1 instead, presumably for fallback purposes). Now, the thing that made me feel stupid for not realizing it sooner was the fact that, after you perform the calculation, what you're left with is nothing more than the placement index (starting at 0) of the tiles as they appear in the editor for the World_A tileset!

To illustrate, where we had this before:


We now have something much simpler (and more predictable!):


I'm not sure if this had crossed my mind before, but the indices (and the tile IDs they correspond to) are all unique. Meaning that, although they're stacked on either of two separate layers - so that a given tile can have both a Layer 1 ID and a Layer 2 ID - the numbers on either layer never overlap. So if you give me a number, I can tell you exactly what type of terrain it corresponds to without knowing whether it's a Layer 1 or a Layer 2 ID. Which, it turns out, is exactly what the functions with the long switch statements that I copied above are doing. So then, you might ask, are those functions evaluating Layer 1 or Layer 2 IDs? And how is that determined? Exploring the functions that call those two functions will answer those questions. You can find them in rpg_sprites.js at lines 2518-2528. Here they are:
Spriteset_Battle.prototype.normalBattleback1Name = function() {
    return (this.terrainBattleback1Name(this.autotileType(1)) ||
            this.terrainBattleback1Name(this.autotileType(0)) ||
            this.defaultBattleback1Name());
};

Spriteset_Battle.prototype.normalBattleback2Name = function() {
    return (this.terrainBattleback2Name(this.autotileType(1)) ||
            this.terrainBattleback2Name(this.autotileType(0)) ||
            this.defaultBattleback2Name());
};
As well as I can figure, these functions run when the game is trying to load a battle and determine which battle background to use. Again, you'll note that there are two separate functions, one for each half of the battle background. They each do essentially the same thing, however, which is to call the long switch functions we've already seen (hereafter referred to as "the terrainName function(s)") to determine which battle background to use based on the terrain corresponding to the index evaluated via the autotileType function (the one with the math that we examined above).

If you're paying attention, you'll note that here the function only takes a single argument, whereas before it took three. This is confusing, but the explanation for it is quite simple. The previous autotileType function belonged to the Game_Map class. But here, we're dealing with the Spriteset_Battle class, which has defined its own autotileType function. But before you throw your arms up in frustration, this local version of the function is nothing more than a shortcut to that other version, but with the x and y arguments already predetermined to be the player's x and y map coordinates. You can examine the function yourself. It is located in rpg_sprites.js at lines 2590-2592, which I will reproduce here:
Spriteset_Battle.prototype.autotileType = function(z) {
    return $gameMap.autotileType($gamePlayer.x, $gamePlayer.y, z);
};
So, returning to the normalBattlebackName functions (hereafter referred to as "the normalName function(s)"), when they call the terrainName functions, they're passing in an index corresponding to a tile ID at either the first or second layer, depending on whether the autotileType function is being passed a 0 or a 1 (note that since counters in programming usually start at 0, the 0 corresponds to Layer 1, and the 1 corresponds to Layer 2 - try not to get confused). There's something a little weird going on here, though, because each normalName function is trying to return the value of a call to the corresponding terrainName function (which would be the name of the battle background file associated with the given terrain), but it's tangled up in an OR operator ("||"). Let's take a closer look:
return (this.terrainBattleback1or2Name(this.autotileType(1)) ||
            this.terrainBattleback1or2Name(this.autotileType(0)) ||
            this.defaultBattleback1or2Name());
It took me a while to get a firm grasp on what exactly is going on here, even though it's largely intuitive. (Sometimes explicit instructions are helpful). For a detailed explanation of the behavior of JavaScript's OR operator, read this. Suffice to say, the operator responds not just to true/false evaluations, but also to the wishy-washy properties of truthiness/falsiness. Sounds messy, doesn't it?

I'm pretty confident, though, that what's going on in these normalName functions is that they're trying to call the corresponding terrainName function first with the Layer 2 ID (giving it precedence). If the tile the player is standing on has no Layer 2 ID (presumably resulting in a "falsey" value), then it calls the function instead using the Layer 1 ID. And then, if for some reason there's no Layer 1 ID either, it falls back to a default (calling a simple function that does nothing more than return the 'Grassland' battleback - whether top or bottom).

---------

Are you with me so far? Because here's where we get to start customizing things. Now that we know which indices correspond to which terrains (see the second image above), it would be a simple matter to just change the names of the battle backgrounds in those functions with the long switch statements, or even to add new cases to designate other battle backgrounds for terrains that the default function doesn't account for.

(Disclaimer: I don't advise changing the original JavaScript files that come packed in with the program. But if you copy the important functions into a new JavaScript file, and make your adjustments there, then you can add it in the same way you do with your other plugins (MV terminology for scripts), and add it to your game via the plugin manager. That way, if there are any problems in the future, you have the simple option of either turning off or getting rid of the plugin completely, and reverting to the game's default functionality).

But in the process of doing this, I hit a little snag, because I like to have a little bit more fine-tuned control over the choice of battle background depending not just on either the Layer 1 or Layer 2 ID, but in some cases the result of their combination. In different cases, the Layer 2 ID might take precedence, whereas in others, the Layer 1 ID will be more important. My way of dealing with this via the eventing solution I used in VX Ace was to simply handle both Layer IDs simultaneously and check them against each other. But the functions we're dealing with here only consider one ID at a time. So what to do?

I tried a few different ways to get around this limitation, but I ultimately decided to modify the function itself to actually take two arguments instead of just one - one for each of the first two Layer IDs. I checked through all the core scripts (Ctrl-F is your friend), to make sure I knew every place the terrainName functions were being called, so as to avoid any discrepancies in the code. And it turns out that the only time the functions come up is in those cases we've already explored here.

(Another disclaimer: if you use another plugin that attempts to use or modify these same functions, you may encounter problems. I'm only a beginner MV scripter right now, so I wouldn't know how to minimize that possibility, e.g. by aliasing or whatever. Feel free to add in some contingency code yourself if you know how to go about doing that).

So all I had to do was change the (type) part of the function to a (type1, type2), and then in the normalName functions where the terrainName functions are being called, replace the first part of the confusing OR evaluation (while preserving the default fallback), so as to call the terrainName function just once with both arguments - one that retrieves the autotileType for Layer 1, and one for Layer 2. This is what the modified functions look like:
Spriteset_Battle.prototype.normalBattleback1Name = function() {
    return (this.terrainBattleback1Name(this.autotileType(0),
            this.autotileType(1)) || this.defaultBattleback1Name());
};

Spriteset_Battle.prototype.normalBattleback2Name = function() {
    return (this.terrainBattleback2Name(this.autotileType(0),
            this.autotileType(1)) || this.defaultBattleback2Name());
};
All that was left then was to modify the terrainName functions, by manipulating the switch statement(s), and in my case, adding in a couple of extra if/else statements for better flow, to tie the proper battle backgrounds to the proper combination of terrains. Here's what I ended up with (although I may make some more fine-tuned adjustments in the future):
Spriteset_Battle.prototype.terrainBattleback1Name = function(type1, type2) {
    if (type2 === 29) {
        return 'Cobblestones2';
    } else if (type2 === 37) {
        return 'Cobblestones4';
    } else {
        switch (type1) {
        case 4: case 5:
            return 'PoisonSwamp';
        case 8:
            return 'Ship';
        case 10: case 40:
            return 'Snowfield';
        case 16: case 18:
            switch (type2) {
            case 17: case 19:
                return 'Meadow';
            case 20: case 21:
                return 'GrassMaze';
            default:
                return 'Grassland';
            }
        case 24: case 26:
            return 'Wasteland';
        case 32:
            if (type2 === 33) {
                return 'Desert';
            } else {
                return 'Sand';
            }
        case 34:
            if (type2 === 35) {
                return 'Lava2';
            } else {
                return 'Lava1';
            }
        case 42:
            return 'Clouds';
        default:
            return null;
        }
    }
};

Spriteset_Battle.prototype.terrainBattleback2Name = function(type1, type2) {
    if (type2 === 30 || type2 === 38 || type2 === 41 || type2 === 46) {
        return 'Cliff';
    } else if (type2 === 21 || type2 === 36 || type2 === 44) {
        return 'Forest1';
    } else {
        switch (type1) {
        case 4: case 5:
            return 'PoisonSwamp';
        case 8:
            return 'Bridge';
        case 10:
            return 'Snowfield';
        case 16: case 18:
            if (type2 === 20) {
                return 'GrassMaze';
            } else {
                return 'Grassland';
            }
        case 24: case 26:
            return 'Wasteland';
        case 32:
            if (type2 === 33) {
                return 'Desert';
            } else {
                return 'Sea';
            }
        case 34:
            return 'Lava';
        case 40:
            return 'Snowfield';
        case 42:
            return 'Clouds';
        }
    }
};
A couple of notes to help you understand what's going on here. In the first function, I used an overriding if statement to return the appropriate ground textures for map tiles that feature roads (indicated by a Layer 2 ID), no matter what Layer 1 terrain is involved (grass, desert, snow, etc.). The rest of the cases are pretty straightforward, except that I provided some alternatives such as a different lower background for plains (indicated by a Layer 1 ID) versus grassy plains (indicated by a Layer 2 ID), and a similar alternative for ashy wasteland versus cracked lavafield (the subtle difference between the Lava1 and Lava2 battle backgrounds).

In the second function, I've used another conditional to override the texture for any tiles that require the Cliff or Forest1 wall texture, since they tend to crop up over a number of different Layer 1 ID terrains. The rest of the switch statement is again pretty straightforward, although here you'll see that I've designated one of the two desert terrains as a "beach" (as opposed to a landlocked desert) by giving it the Sea wall texture instead of the usual Desert wall texture.

And that's pretty much it! Feel free to take these code snippets and play around with them to suit your purposes. I'd love to make a fully customizable plugin out of what I've done here, but I fear that the individual needs of each user will be so specific as to require a heavily personalized combination of conditionals. Come to think of it, that may be why the original programmers haven't already done it.

Just a few last notes. It should be mentioned that in these examples, I've replaced all of my MV image files with resized versions of the VX Ace graphics (because I like them better). So my filenames may not match yours (although many - but not all - of the battleback filenames have remained the same from VX Ace to MV). Make sure the names you use in your code match the filenames in your img/battlebacks folders (1 and 2), minus the file extensions.

On a related subject, if you want to change the default battle background for use while riding the ship, you'll find that in a separate pair of functions that are really simple to modify. Look for them in rpg_sprites.js at lines 2582-2588.

I don't know how or to what extent the solution I've come up with here will dovetail with an airship encounter system, as I haven't tackled that problem in the MV version of my game yet. But if I have anything to say about that in the future, you can be sure to find it here on this blog!

Saturday, December 12, 2015

BGM Delay

I haven't had a lot of time to work on my games in the past couple of months - much of my free time has been taken up by my ongoing X-Files marathon (nearing its end now, though), and December is a busy, stressful time for me (bah humbug and all that). But I had a little time this weekend, and ended up figuring out how to record a video of me playing RPG Maker so as to demonstrate one of the enduring problems I have with the new MV program. I'll copy the video and the description I wrote up for it here, so you can see for yourself (I used a blank project just for this video):


BGM Delay - A demonstration of the problem I have in RPG Maker MV with BGMs (Background Music) taking several seconds to load each and every time they're played. MEs (Music Effects) and SEs (Sound Effects) as well as BGS (Background Sounds - not tested here) all play instantly, but not BGMs, which is true during map transfers and also when the game first loads the title screen. That multiple second delay is very annoying and frankly unacceptable in a professional product.

There's a little discussion (although not nearly enough, if you ask me) over on the RPG Maker Web Forums about this problem and potential fixes, but so far I haven't come across a satisfactory solution. Frankly, I'm surprised the program shipped with this little bug, although the fact that it did gives me little hope for a competent fix. I've read some theories that would explain it away as an inevitable symptom of the program having been designed to stream games on the fly in web browsers and/or on mobile devices.

In other words, just another sacrifice of advancing technology (and the trend towards mobile internet). I so wish I could go back to using the superior engine of RPG Maker VX Ace, but I just can't give up the cross-platform support and the side-view battle system. It's a frustrating quandary.

Saturday, November 7, 2015

A New Demo

Alright. I still have mixed feelings about RPG Maker MV, but the excellent community at the RPG Maker Forums have provided an unofficial tool to resize graphic sheets from VX Ace in order to be compatible with MV (while reducing many of the inevitable flaws inherent in enlarging pixel graphics - the results are actually quite satisfactory, in my opinion). So that largely eliminates one of my biggest issues.

As such, I've been working on adapting my game Ascension to RPG Maker MV, building from the ground up - so I can apply all the updates I didn't get around to making on my last, aborted version. I'm taking advantage of the opportunity to learn the ins and outs of RPG Maker MV while working on a smaller and simpler project (Ascension), before I ultimately return to my RPG (Dragonfaith). So expect periodic updates.

To start with, I have finished up my first stage on Ascension, and so this will serve as a test run for deploying my game on a trial basis. I would appreciate anyone reading this and following my games to give it a download and try it out, and let me know how (if) it works. The first stage is very short, so it shouldn't be a huge time commitment. And for those of you who have played my game before, the stage looks a little bit different than the last time you saw it (I will be applying other changes to later stages as well).

Allow me to inform you of some of the most notable changes in the RPG Maker MV program, that you might notice as differing from when you played my game created with VX Ace:

* Graphical resolution - The first thing you'll probably notice is that the game looks bigger - the graphical resolution is 1.5x the size of VX Ace's graphics.

* Cross-platform support - From now on I'll be providing downloads for both Windows and Mac versions of my game. (Mobile versions are also supported, but I haven't played around with them yet, so I'll leave them out for the time being. There are also rumors that you can run games straight from web browsers, but I haven't looked into that yet, either. I'm going to start out with what I know, and go from there. Stay tuned for additional options in the future, maybe.)

* Mouse input - The new version of RPG Maker supports mouse input (and presumably touch input, in the case of mobile devices). I haven't changed my game to account for this (and I don't know that I will). I don't know to what extent it will change how my game is played. I don't intend for the user to use the mouse, as that's not how I've designed my game, but you can certainly try it out and let me know if and how it affects the way my game is played.

* No RTP - There is no RTP in RPG Maker MV, so every download is going to be the full project. This is conceptually simpler - you don't have to pre-download an extra game pack to play my games, but it also means that file sizes might be larger than they have been in the past. That's just the way it's going to be now. (By all means, feel free to delete older versions when you download the newest releases - I intend for you to do as much).

Without further ado, here is my first MV release:

Ascension: Chapter 1 - Limbo
Download (~90 MB): Windows | Mac [see sidebar for latest release]

Saturday, October 24, 2015

RPG Maker MV - A First Look

RPG Maker MV launched yesterday, and I already have it in my possession. I'll need to spend a lot more time with it to get familiar with all its features and learn its differences (and similarities) to RPG Maker VX Ace. But I wanted to report my preliminary impression of the program after just a cursory examination. I was very excited for this update to the RPG Maker program, namely due to some of its advertised improvements - mainly, the addition of of a side-view battle system, and cross-platform compatibility (including the alleged ability to embed games in a web browser). Now that I actually get to look at the program, there's one thing that has me a little concerned, and it's the graphics. They're spiffy enough, but they have a softer, more rounded, kind of a more cartoony look, that I'm not sure I like. This problem is as apparent with the battlers as anywhere. I should be happy with them, because some of the bonus resources include some much needed robot enemies, but they don't fill all the holes I need to be filled, and I'm just not sure I really like the style - even more so than before.

I was excited when I heard that they updated the character generator, but while those graphics look smooth, I have to say I don't like it as much as the old one. For one thing, the outfits don't look nearly as interesting - they're all samey, and tend not to have the distinctness of variation (e.g. heavy armor versus a school uniform versus a business suit versus a dress) that the last program had. And there doesn't appear to be the option to change the color of the characters' underwear (why? now everyone has to wear the same underwear?). The facial options are much more limited (it's possible that this may be expanded in the future, but until it is, there's not much I can do with it). And there are no "half-elf" ears (which were kinda important to my RPG) - it's either go all the way or bust. I was also hoping they'd maybe include a character generator for smaller-framed child characters, but no such luck.

Perhaps the most concerning graphical issue for me is that, in order to use the side-view battle system, you have to have a whole bunch of extra sprites for in-battle animations (fists raised, using a skill, getting hit, etc.). These are provided with the in-game actors, but I'm not sure I like them - in VX Ace, I made a point to use the character generator to create unique characters for my playable heroes, because I didn't want to just use cookie-cutter heroes as the stars in my game. The new character generator creates those battle animations for you, but again, I'm not sure I like the characters that the new character generator creates. It's a problem. I'm already toying with the idea of importing all the old graphics from VX Ace, in order to take advantage of the new engine (which undoubtedly has plenty of good things to be said about it - I just haven't delved that far into the program yet). But if I use the side-view battle system, which was very important to me, I'd have to manually add sprites that would seriously reduce the animations, and I just don't know how well that's going to work.

All in all, it reinforces the primary issue I've had with developing my RPG in RPG Maker from the start - and that is trying to mold the ideas I have in my head to the capabilities of the program presented to me. I don't want to sound ungrateful, because I know that I don't have the ability to program a game from scratch, but I feel like it would be easier to just dive into the RPG Maker program and make a generic RPG with whatever resources I can find within the program (which is undoubtedly its main use), rather than trying to use it as the engine to bring the specific game idea(s) in my head to life. But that's not what I actually want to do. I'll keep you posted. (I think that maybe actually a lot of my problems would go away if I just knew somebody personally who was a talented graphical artist that was willing to design all new graphics for me to use with the program, free of charge - because, honestly, I can't afford to pay somebody else's salary, I can't even afford to pay my own salary).

Sunday, August 9, 2015

Good News and Bad News

The bad news: After receiving some considerable (and long-anticipated) feedback, I've halted progress on polishing up Ascension, to take some time to consider what kind of significant changes I may want to make to it in the future. As such, I'm not going to have another release ready by the end of the summer like I had planned.

The good news: I've just got word that a new version of RPG Maker is due out later this year. Normally, I wouldn't be in a hurry to upgrade from a program I'm already familiar with, but this new version has some tantalizing features. In addition to a larger screen (and corresponding graphical resolution), it's designed to be multiplatform (so you can make games for both PC and Mac, in addition to mobile platforms). But most of all, it supports a sideview battle system, which has been one of the largest sticking points of the current RPG Maker program I've been using. Plus, it retains square character sprites (and not the tall, lanky ones of some previous versions of RPG Maker), which I prefer (because they remind me of the classic RPGs I love so much). So I might just have to switch to this newer program once it's released. Read more about it here: RPG Maker MV.

Friday, July 10, 2015

Summer Update

Lest anyone think I've given up on game developing (I haven't), here is an illuminating post to read (click me). Go ahead, I'll wait. The moral? Game development is long and hard, and RPGs are a pretty complex genre. And did I mention I'm working entirely alone, with a nonexistent budget? But I'm really dedicated to bringing this game to life - it's my baby - so sit tight. Until the game is finished (and I can't say how long that'll take, but I imagine it'll be measured in years), there'll always be something exciting waiting just on the next horizon.

If you've been following my progress at least as far back as last year, then the following account might sound familiar to you. As happened last year, the summer has got me spending more time outdoors away from my computer, so I've been working on my game less. And, like last year, I decided to take a break from the RPG and work on another project. I've returned my focus to Ascension, now available in beta form. There were some bits of it that I'd had it in the back of my mind to polish up after getting some feedback (mainly on the Labyrinth maze), so I'm going to take some time and do that this summer, and try to have it finished up for another release before Halloween. And unless I get some major feedback after that, I might consider that pretty much the final release, at least for the time being, so I can focus on other things (e.g., working on my RPG throughout next summer instead of taking another break from it).

So look forward to that. I also intend to play some more RPGs for inspiration, but I have a busy schedule, and developing ought to take precedence, so I can't say when I'm going to be able to find the time to do that. It's on my list, though.

Saturday, May 23, 2015

Review: Final Fantasy

After trudging through that chore of an endgame in Dragon Quest II, I was thinking that I'd need a break before embarking on my next RPG. But then I started thinking about the next game in my queue - Final Fantasy - and I started getting excited by the thought of playing it. Which is a good sign. I've made it clear that my bias is towards the Final Fantasy series, on account of growing up with it, and not Dragon Quest. So it could just be nostalgia talking, but I feel as though Final Fantasy is superior to either of the first two (at least) Dragon Quests.

As a disclaimer, it's easy for me to overlook a lot of the innovations that Final Fantasy brought to the console RPG table, since I'm so familiar with the game - I take it for granted that what Final Fantasy did constitutes, in my mind, the basic foundation for what a console RPG should be.

Though plot-wise and character-wise, the various Final Fantasy games are not narratively interconnected (until they started making sequels, such as Final Fantasy X-2...), there are a number of thematic elements that recur to give the series some cohesion. Not all of the most popular ones (e.g., Chocobos and Moogles) are present in the first game in the series, but there are a few basic ones:

* Elves sell Mithril/Silver weapons and armor.
* A Dwarven blacksmith can forge one of the strongest swords in the game (usually Excalibur), but you have to give him Adamant first (usually found in a high level dungeon).
* The story focuses around crystals (or in this case, orbs) of power.
* There are four elemental-themed bosses (which will also be a crucial element in Final Fantasy IV).
* In addition to delineating the main elemental spells as Fire, Ice, and Lightning, one of the strongest Black Magic spells is Nuke.
* Bahamut is king of the dragons.
* There is an unreasonably strong, optional robot boss.

Getting Started

When you start Final Fantasy, history is made right there on the very first screen. You hear the first iteration of the "crystal theme" that will become iconic to the series playing in the background, while text appears on the screen setting the scene for the game. Plot and dramatic elements are still pretty sparse in these early games, but from this intro I get a sense of fantasy immersion and, well, poetry, that Dragon Quest lacked. You are not the descendant of a great hero tasked with slaying dragons and defeating an evil sorcerer. You are the Light Warriors, carrying mysterious orbs, who have come to fulfill a prophecy in a world shrouded in darkness, whose natural elements are spinning out of control!

Before you even get to start playing, you are given a critical choice, that introduces a high level of customization and replayability that was totally absent in Dragon Quest. You have to assemble your party of warriors, consisting of four characters, chosen from six different possible job classes (an element Final Fantasy will pride itself on experimenting with throughout its series). You won't know this the first time you play, but how you play the game, and how difficult it will be, depends on your choice of warriors.

Dragon Quest II introduced the compartmentalization of combat roles with its fighters and spellcasters. Final Fantasy takes it to the next level with three variations on the fighter, and three different kinds of mages. The eponymous Fighter is your typical RPG warrior, who wields medieval weapons and can wear heavy armor. The Black Belt balances his inability to wear armor with a high natural attack power that doesn't rely on using rare or expensive weapons. The Thief may only be a mediocre fighter, but his speed can help your party escape dangerous encounters.

Whereas in Dragon Quest and its sequel, different types of spells were learned arbitrarily by spellcasters, Final Fantasy actually splits its magic into two main types. Black Mages can wield offensive magic, including elemental spells, while White Mages focus on defense and healing. Red Mages can use a little of both, but cannot master either. The latter's versatility may seem appealing to novices, but his limitations can be crippling.

If there's a lot to say before diving into the actual game itself, it's because we're dealing with such a new and different interface here. It's worth noting that in Final Fantasy, the save function accompanies staying at the inn, which will become a series (if not genre) standard. Additionally, Final Fantasy introduces the "portable inn". Going above and beyond simple heal potions, the portable inn (in the form of Tents, Cabins, and Houses, in order of increasing power) is something you can take with you and use (but only on the world map) to heal a good deal of your health (and sometimes magic power), and give you an option to save outside of the inn. The latter option expands the locations at which you can save your game (provided you have the right item to use), and is a step on the way to free saves anywhere on the world map.

Also noteworthy is the presence of the menu screen. Up to this point in the Dragon Quest series, the menu came in the form of a text box (or series of text boxes) overlaid on the current map screen. In Final Fantasy, the menu has its own immersive screen, with graphic depictions of the characters in your party, and different pages for the different inventory and status screens. There is a collective item inventory for your whole party, and separate weapon and armor inventories that hold up to four pieces of equipment each, for each character.

Setting Out

I may be influenced by my nostalgia here, but my immediate impression is that the music in Final Fantasy is so much better and more memorable than the music in Dragon Quest. The latter game's music may have been catchy, in a videogamey sort of way, but it didn't seem quite so...symphonic...as the music here in Final Fantasy (composed by Nobuo Uematsu).

Once you've picked out your team, the game plops you down into the game world, mercifully close to the first town - Coneria. It would behoove you to visit the town first to get your bearings and outfit yourself with the 400 G you're given to start with before braving the wilderness and the creatures that prowl there. Here the customization plays its first practical role, in that what you decide to buy - be it weapons, armor, spells, or items - is entirely up to you, and what you need will depend on the team you've picked out.

Unique to Final Fantasy is the fact that spells must be bought, rather than learned at particular levels. And rather than MP costs drawn from a character's MP pool, you have a certain number of uses of any of the spells you've learned from each magic level, which increases as your level increases. Moreover, each level sports four black and white magic spells each, but there are only three spots per level per mage. So you have to decide which spells you'd rather learn (or choose a team with duplicate mages, and then teach them different spells). It is already clear that Final Fantasy was not simply trying to be a generic RPG, but that it was trying to do something original - and succeeded. In addition to job classes, magic systems is another element that the Final Fantasy series has experimented with quite a bit from game to game.

In terms of stats and equipment, the game is not yet completely user-friendly. It's not clear which job classes can use which equipment (weapons and armor) until you buy it and try it out, and then in order to determine whether the new equipment is any better than your old equipment, you have to consult the character's status screen before and after equipping it. Also, the magic spells could use descriptions, as their names are rarely a clear indicator of what, exactly, they do (unlike in the first couple of Dragon Quest games). I think I recall the original NES cartridge coming with a fold-out chart with this information (as well as enemy stats), which is in the game's favor (but not so much the player's, if he's lost track of it - although that's one of those things that a strategy guide, and nowadays the internet, is good for). I know space for data was limited in the days of 8-bit systems, but certainly, incorporating that information into the game itself in later sequels with better technology is a decided plus.

In the castle next to, but separate from, the town of Coneria, you acquire your first mission from the king, in what is surely an homage to Dragon Quest. You must save the Princess who was kidnapped and taken to a nearby castle (which, you cannot possibly know yet, will be the location of the final dungeon, much like how Dragon Quest's final dungeon leered at you from across the channel, out of reach but within sight of the first castle).

A note on combat: firstly, I have to say that I really like the side view battle system, as opposed to Dragon Quest's front-facing system. It's great to see your characters up on the screen fighting, and it's also helpful from a visual perspective to see when your characters are weak, or poisoned, or get killed, etc. Also, seeing the different spells and weapons and attack animations (even as primitive as they are here) is really cool. Finally, as much as I love Akira Toriyama (and I do), who illustrated the monsters in Dragon Quest, I like the monsters in Final Fantasy a lot better (illustrated by Yoshitaka Amano). They're much more intimidating, as Toriyama's designs tend to lean toward the whimsical. Case in point, the iconic low-level introductory monster in Dragon Quest games is the Slime, which is a cute blob with a smiley face. The corresponding monster in Final Fantasy games is the Imp (or Goblin), the design for which definitely takes on a more grotesque rather than goofy nature.

[Aside: One revelation I had while playing Final Fantasy is that RPG Maker VX Ace has sophisticated graphics to the level of the SNES RPGS (or better), yet the combat mechanics are primitive in comparison - more on the level of the NES-era RPGs. Without intensive scripting, combat in RPG Maker VX Ace has neither graphic battlers, nor an active time battle system (combat is strictly turn-based). The simplicity is not so much a problem for me, but battles run much smoother and are frankly more fun in those later RPGs.]

Another one of Final Fantasy's innovations is the diversification of elements/monster types. Offensive damage spells in the first Dragon Quest (named Hurt and Hurtmore) were pretty neutral. Some enemies (most notably dragons) could breathe fire, but I don't know that the nature of the fire had any special significance. The spells in Dragon Quest II are mostly fire-based (although one of them may have more of a lightning nature). However, again, I don't think the elements had any special significance, other than descriptory. In Final Fantasy, on the other hand, the very first level of black magic includes two spells - Fire and Lit (i.e., lightning) - that would seem to be pretty similar (as I don't think one is significantly stronger than the other, both of them being at the same level), if not for the fact that some enemies have special weaknesses to specific elements. This ramps up the complexity of the magic and combat system, but in a way that makes it feel more fun, and introduces more strategy (as opposed to tedium) to your battles.

Similarly, there are a number of weapons (and armor) that are more or less effective against certain types of enemies - both due to elemental specialties, as well as monster type (giant, dragon, undead, magic). There was a sword in Dragon Quest II (the Dragonkiller) that would seem to serve this role, but this is an isolated example of limited practical use in that game (there were, ironically, actually very few dragons in Dragon Quest II), and Final Fantasy takes it to a whole different level with its long list of equipment compared to the first two Dragon Quests' relatively generic and streamlined weapon/armor inventory.

Now let's get into the meat of the game

Sailing to Adventure

Even once you get the ship, early in the game, the whole world doesn't open up to you just yet. Final Fantasy is a very carefully gated game, and yet at the same time there is considerable wiggle room for adventurous explorers. The ship starts out in the inland sea, and only after blowing open a canal can you sail the high seas, and even then, the entire northern hemisphere (for the most part) is still off limits until you get the airship, as there are no ports for the ship to dock at.

Between Pravoka and Elfland - which aren't even separated by a dungeon - the game throws quite a lot of equipment (and spells!) at you that you can't possibly have the money to keep up with. I don't know if this is a bad thing, as it gives a purpose to whatever grinding you choose or feel you need to do, but it is a little frustrating coming across all this stuff and thinking it will be forever before you can afford to buy everything you want/need!

I don't think I've ever really thought of it this way, but besides the Temple of Fiends - which is very small and quick to complete - there are three major towns (Coneria, Pravoka, and Elfland) before you get to the game's first real dungeon - and that's after getting the ship!

Speaking of that dungeon - the dreaded Marsh Cave - even after all these years I find myself a bit trepidatious about embarking upon that journey. Not only do you have to march a good ways from the closest safe haven (the village of Elfland) just to get to the cave, but it is a meandering, mazelike dungeon, filled with slime-type enemies that are frustratingly resilient to physical attacks (a world of difference from Dragon Quest's Slimes). [Aside: I haven't taken the time to actually verify this, but I think the Muck/Scum/Slime family of enemies are like later installments that are each vulnerable to specific elements. Here, though, they're much more menacing, and not like the "Puddings" and other desserts of later Final Fantasys]. And even when you do finally reach your goal - one of several identical treasure rooms on the deepest level - you have to fight a challenging (frustratingly difficult!) boss that puts Garland and even the Pirates you've fought up to this point to shame.

Generally, the customizable options in this game are a plus, but I have to admit that I hate having to choose only three of four possible spells at every level of magic. On the other hand, I feel like a lot of the spells are of limited applicability - particularly the status-affecting spells (though that may just be the way I tend to play). But it's still hard to choose sometimes, and I hate the feeling of completely locking out a spell for the rest of the game - what if I change my mind?

I've definitely been spoiled by Dragon Quest's Return spell. With it (in addition to the Outside spell if I'm exploring dungeons) I can head out and fight until I'm weak, then warp back to town to heal up, and reap the benefits of my earned gold and experience. In Final Fantasy (at least in the first half of the game), you have to preserve enough strength for the return journey, because if you get killed by a few wolves a couple miles from town after you've been wearied from a long and arduous journey, you're shit out of luck. It's a little annoying, and adds a lot of anxiety into the game, but at the same time, it's realistic, and it contributes to the more grown up atmosphere of this game, compared to Dragon Quest's more whimsical presentation. (In hindsight, though, I should have made more use of the portable inns - I tend to be very conservative about my item use).

Final Fantasy takes status ailments to the next level. In addition to poison, and being able to put enemies to sleep, there's also the very annoying paralysis, and the devastating stone/petrification that can only be cured by specialized items or spells (not by the clinic or using an inn).

This game really teaches you to choose your battles. When I was younger, I tended to run away from battles a lot, whether it was because I was more timid, or just lazy. But more recently, I've gotten into the habit of fighting as much as possible, because it almost feels like cheating if you run away; and anyway, if you don't get enough experience, you won't level your characters up and you'll be too weak against the bosses, and then you'll need to do boring grinding to earn the experience you could have earned gradually through the process of playing the game if you hadn't run away from all those fights (at least in games that are well-balanced).

Anyway, when you come up against a horde of Geists, who not infrequently paralyze your party members when they attack, there's really no tactical advantage in sticking around to fight (and risking your life!). Also, when you're grinding for gold, looking for Ogres (for example) to fight, it's a waste of time to kill a pack of weak wolves. And when faced with a group of Arachnids - though you might gain decent gold from them, they have a nasty habit of poisoning your party members, and those Pure potions are 75 gold a pop, so you might just end up paying for the privilege of exterminating them (thankless work, I say), when you could just run instead, and come out on top.

Final Fantasy's random encounter formula is vastly superior to Dragon Quest's. You never run into a subsequent encounter in no more than a few steps than your last one here. And while random encounters are always disruptive and jarring, so far I have not once felt that they were so frequent as to be annoying, and yet I don't feel like I can go forever without getting an encounter either. I wonder what the formula actually is here, because getting the perfect frequency of encounters is a really tricky thing to figure out. [Aside: Playing around with save states a little bit leads me to conclude that there is somewhat less randomness involved with the enemy encounters, their frequencies, and sometimes even how the enemies behave, than I would have thought.]

One thing Final Fantasy seems to be fond of are "guardian encounters", where a forced encounter will occur when you step on a particular tile (like the Axe Knight in Dragon Quest), frequently used in front of treasure chests. Final Fantasy makes you work for your treasure! But the treasure here is (generally speaking) much more valuable than it was in Dragon Quest or its sequel. I think I like these encounters - they impose a certain gravitas, like saying, "this room/treasure is something special!" In later games, they'll evolve into monsters-in-a-box (treasure chests that monsters pop out of, that you must defeat before you can claim the prize) and, in endgame dungeons, optional bosses whose vanquishing rewards you with uniquely powerful equipment.

The Rotting Earth

I haven't made it to the first major boss yet (Lich) - so take that into account - but I'm finding that after powering yourself up to survive in these harrowing dungeons, the bosses are actually not that challenging. (The Wizards are an exception largely because you face many of them at a time). Once you bring out your big guns (which mainly means all those spells you've been saving up), the bosses tend to go down without too much struggle. I remember this being the case with the final boss when I first played the game, too. After all the effort put into making it to the final boss, actually beating him wasn't too difficult. I mean, why make the final boss in the game use Fire 2/Lit 2/Ice 2 when he could be using Fire 3/Lit 3/Ice 3, let alone Nuke!?

I have to say, especially coming off the heels of Dragon Quest and its sequel, this game is exceptionally well-balanced. When I rolled into Melmond and spied the price tag for the Steel Armor - a good order of magnitude larger than anything else so far (in comparison, the Level 5 magic spells in Melmond cost 8000 G a piece, which is twice the cost of the Level 4 spells, and pretty steep, but the Steel Armor costs a whopping 45000 G!) - my knees buckled. But the armor's really strong, so it's worth the high price, and it's not like you need it immediately, either. But I restricted myself to just buying the spells I thought I needed right away (instead of filling up my slots as soon as possible), and with the bigger rewards gained from defeating the tougher enemies lurking in the Earth Cave, I found that at a point after defeating the Vampire mid-boss, but not quite having reached Lich yet, I had already managed to collect enough money for that armor!

One thing I've noticed - and this was true to a certain extent in Dragon Quest II as well, is that the continents and places of interest are aligned in a generally ordered fashion as far as seafaring goes. You might not notice it right away, when you get your ship, and start sailing around everywhere looking for places to explore. But a goal-oriented navigator will appreciate things like Elfland and Coneria being only slightly skewed from a direct north-south voyage across the inland sea, or the canal being pretty much due west of Coneria, or the landmass west of the canal nudging you gently towards Melmond (before you get lost wandering the open sea), or the fact that if you sail south from Melmond, then travel due west after rounding the tip of the Earth Cave peninsula, it will put you in sight of the port you need to drop anchor at to reach Crescent Lake (silly me, when I was a kid, I insisted on sailing the long voyage 'round the southern tip of the continent, stopping off at the southern port at Elfland for a breather...). It ensures that the player is more than likely to accidentally wind up where he's supposed to be anyway (without precluding optional exploration), which is good game design. [Misdirection is more welcome on land and in dungeons, where the space is more closed in, but since the sea is so wide and open, a little push in the right direction can prevent much frustration].

A Trial of Ice and Fire

The Earth Cave was challenging - an order of magnitude larger than the Marsh Cave - but you had to take it in two parts. The Gurgu Volcano takes things to the next level. You have to navigate winding rivers teeming with strong enemies just to get to the volcano, which is then filled with meandering, maze-like passages, and liberally (and I do mean liberally) covered with damaging lava floors.

I have to express agitation at the fact that the Warp spell is not usable until the class change. I could understand this being the case for the Exit spell, which is even better. But since you have to wait until the class change anyway, having the Warp spell (which only returns you one floor) is not so novel when you have Exit (which takes you outside the dungeon completely) available to you. The Warp spell (the usage of which does not come without cost) would be immensely valuable in the Gurgu Volcano, which is vast, and has tons of floors, and takes a lot out of you just to get to some of the lower levels of treasure chests... This may be a slight exaggeration (then again, it may not), but it almost seems like it would be easier to trudge forward and just beat Kary and use the warp to get back up to the top than have to climb all the way back up retracing your steps...

Gurgu Volcano was a chore just on account of how long it is. The Ice Cave is shorter, but if anything, it's even more of an ordeal. It's filled with tricks and traps - holes that send you to different floors - and a lot of the enemies rely on instant kills and debilitating status ailments. Sleep and paralysis are rampant, but of even more concern is the Cockatrices who can turn you to stone. Stone can only be cured by an expensive Soft potion, or the equivalent white magic spell - which is also expensive, and requires a relatively high level to be able to even use it. Then you have Sorcerers (the successor to the Wizards) who can kill with a single touch, and Mages (who look like Astos), who love to use Rub to instantly wipe out one of your characters. On top of all that, you have your straightforward enemies - the Frost Giants, Frost Wolves, and Frost Dragons, the latter with their devastating Blizzard technique... The Ice Cave is such a challenge, but ultimately, getting the airship is such a momentous occasion that I feel it's probably worth it.

Once you've learned how to raise the airship with the Floater (namely, where to use it), it's easy to take that knowledge for granted. I was curious because the sages of Crescent Lake (who don't give you new information as you advance through the game as much as I was expecting) don't mention anything about where to use the Floater - you have to figure it out from some random elf in Elfland. Having to hunt down clues like that isn't terrible (and it helps that in this case the clue actually tells you what to do instead of being so cryptic and vague as to be useless), although since this is before you get the airship, it seems like it would be a bit of a pain in the ass going around looking for clues, not knowing what the hell you're supposed to do after you've scored this mysterious Floater stone. (Still, this is a minor issue compared to how much Dragon Quest II left you hanging).

I really like the design of the airship in this game (and also in Final Fantasy IV). The blimp-style airship of Final Fantasy VI might be more realistic, but the pirate-ship-with-propellers-in-place-of-sails looks a whole lot more badass.

Above the Ocean and Under the Sea

Once you acquire the airship, the game actually encourages exploration. The Cardia Islands and the Castle of Ordeals are an optional quest that you can complete immediately or leave until later. The Mirage Tower blocks you out at first, and though you can reach Lefein, you won't be able to understand anyone there yet. You'll find the next big dungeon - the Sea Shrine - attached to Onrac, but to get there you'll have to go through the Caravan, and then the remote mountain village of Gaia. Plus, in Onrac, there are hints pointing you both to the Cardia Islands and the Waterfall, the latter of which you don't actually need to explore until after the Sea Shrine.

Coming on the tail of the Ice Cave (if you complete this optional quest right away), the Castle of Ordeals is really not too bad of an ordeal. The boss is an encounter with one or more Zombie Dragons, which are suitably intimidating, but, as undead creatures, they have two glaring weaknesses - Fire and Harm magic - which means that both White and Black Mages have a powerful weapon against them, in addition to any strong fighters you have. But even if it's not super challenging, it makes a fun little quest to break up the game between the first and last two big dungeons (not including the final dungeon), and there are some neat treasures to be found (including a couple of pieces of equipment that can be used as items to cast particular magic spells free of cost!).

The game features one money-related choke point (not involving saving up for an expensive but optional weapon, spell, or piece of armor) in the form of a Bottle you have to buy at an Oasis for the hefty price of 50000 G, before you can access the Sea Shrine. But at this point in the game, you have the airship, and access to many enemies in many areas to farm for gold if necessary. Plus, if you've been diligent about collecting treasure, and haven't gone all out spending your money on shiny new toys in all these towns that have opened up to you once you got the airship, then you should have more than enough gold from pillaging the Gurgu Volcano, Ice Cave, and Cardia Islands already.

While it's true that I may be biased by nostalgia, it's worth noting that, unlike either of the first two Dragon Quests, there has been no part in Final Fantasy where I've found myself dragging my feet (except maybe just a little bit before the Marsh Cave). Instead of being reluctant to continue (often on account of too unfair, luck-based game mechanics, or in need of too much boring, repetitive grinding), I've been eager to come back and continue advancing each day. Of course, this is at least partly due to having a good, balanced party - which is up to the player - but the option of making the game more difficult and potentially frustrating (which, being a free choice, is itself a positive) doesn't change the fact that this game is so competently balanced, and its plot and narrative environment so engrossing (relative to other games of its time).

The Sea Shrine is a bit of a unique dungeon. Every dungeon up to this point has been cave-like (except the Temple of Fiends and the Castle of Ordeals, which are castle-like), but this one is all bright and watery. From the entrance, you can actually go either up or down. The boss is on the bottom floor, but the top floor - which is a haven for mermaids, and features no enemy encounters - contains important treasure. For not even being the next to last major dungeon in the game (not even including the Waterfall, and counting the Mirage Tower as part of the Sky Castle), the Sea Shrine has lots of really good equipment lying around in those treasure chests. I also like how the Sea Shrine gets darker as you go deeper.

Although the Sea Shrine is sprawling and maze-like, with lots of empty rooms and blind alleys, it still feels like a bit of a breather between the dungeons that precede it and the dungeons that follow it. The fact that it's split in half also makes it easier to navigate - the Earth Cave was also split in half, but it was linear, and you had to traverse the first half to reach the second half. Plus, if you got the class change (and have a Black or White Wizard in your party), you can now use the Warp and/or Exit spells to easily escape the dungeon in a pinch. Still, despite all of this, the Sea Shrine has a distinctive character that makes it as memorable as all the other dungeons in this game.

Castle in the Sky

A lot of black magic spells seem to be of limited use. The elemental spells are solid, but the status-afflicting and instant death spells are always a gamble, since they're frequently ineffective. Not having the monster chart that I seem to remember coming with the game makes finding many of the enemies' strengths and weaknesses a chore. With the elemental spells, it's not too hard to figure out which enemies (or types of enemies) are generally weak against which elements (there are only three of them after all). But how to know which enemies spells like Stop or Slow or Stun are effective against? It's pretty cool having all these badass-sounding spells to choose from that are different variations of instant death - Bane, Rub, Break, Quake, XXXX, Zap! - but not knowing what the difference is between many of them - how they work, how effective they are, what enemies they're effective against - makes them all fairly same-y, and their not-always-reliable effectiveness makes you not want to use them when doing so would mean one less casting of a more reliable spell, like Fire 3, Lit 3, Ice 3, or Nuke.

The high level white magic spells, on the other hand, are very useful. In addition to Cure 4 and Harm 4, you get the powerful Life 2, plus Wall (which isn't quite like Reflect in later games, but is still a powerful magic defense booster), and Fade, which you could be forgiven for glossing over and not realizing the utility of - it's basically a holy-elemental version of Nuke, like later games' Ultima, and a rare high-powered offensive spell for the White Wizard, the efficacy of which isn't strictly limited to undead enemies like all the Harm spells are!

It's worth noting that there is a frustrating imbalance between the weapons and armor inventory (which are separate, and are both separate from your general item inventory). Each character has four weapon slots and four armor slots, but is able to equip only one weapon but up to four pieces of armor (body, shield, head, arms). Towards the end of the game, when you have your characters mostly outfitted (the mages can go through most of the game with minimal armor), it becomes difficult to juggle new equipment you pick up in the chests with the old ones you already have - and before you grab the new ones, how do you know which old ones you can spare to lose? It makes looting the Sky Castle a real chore (especially because you have to traverse the desert and then climb the Mirage Tower each time to get there).

So much good equipment is attainable from treasure chests (a lot of it not even available for sale anywhere), that I'm tempted to believe that having to buy magic spells (instead of learning them, free of charge) was implemented in order to make money actually useful in this game (on the other hand, it could have been the other way around - that the buying of magic spells prompted the developers to put lots of good equipment in treasure chests, free for the taking).

The repeating hallway in the Sky Castle makes use of the same annoying trick that was done to death in the Cave to Rhone in Dragon Quest II. The main peril here is not so much getting lost, but the fact that every extra step you take contributes to more enemy encounters - and a chance of encountering the venerable WarMech, which is even stronger than the boss of the dungeon it appears in (which is the last of four major bosses preceding the game's final boss!).

On that note, the sheer strength of WarMech makes defeating it something of an alluring challenge. But the fight is entirely optional - you may not even encounter WarMech in a casual play-through. In this case, you don't win anything but prestige (well, that and a whole bunch of gold and experience) - no super powerful weapon or anything - but nevertheless, this is surely the prototype for optional endgame bosses of Final Fantasys to come.

What makes WarMech so tough? He's got a high defense, which makes it hard to deal damage against him, plus he's got lots of HP (as much as the final boss), so you have to hurt him a lot to beat him. He doesn't have any magical weaknesses that you can exploit, and he's immune to most if not all status ailment inflicting and instant death spells. He's also got a high attack, so he can deal a lot of damage to you with each hit, and uses a technique called Nuclear (probably a variation of Nuke, the strongest black magic spell in the game) that targets your whole party for a lot of damage, leaving you in prime position to be picked off by WarMech's regular attacks.

The best strategy is to keep your White Wizard busy, casting spells to raise your party's defense (Fog) and/or evade (Invisible), as well as protect your party against fire (AFire), all while healing your party members as their HP drops (with any combination of Cure or Heal spells). Your Black Wizard can use Nuke if he has it, or other high level elemental spells (Fire 3, Lit 3, Ice 3), but is probably better off buffing your Knight (if you have one) with spells like Fast and Temper. The Knight's brute strength is probably your best bet in terms of dealing heavy enough damage to take WarMech out before he decimates your whole team. (I can't speak to the Black Belt/Grand Master's efficacy as a fighter, as I've rarely used him, and the Ninja isn't strong enough to penetrate WarMech's tough outer shell, unless you've already collected the Masamune from the final dungeon).

From what I've read, Bahamut and Tiamat are both borrowed from Dungeons & Dragons lore - Bahamut is a good dragon while Tiamat is an evil one. Tiamat would make an appearance or two in later Final Fantasys, but never at the level of prestige he (she?) is at here - one of the four Fiends. Bahamut, on the other hand, will become another iconic recurring character in Final Fantasy, often a summon (in later installments), and not always so friendly.

Back In Time

You might call it cliched or contrived or a third act M. Night Shyamalan-style twist ending, but learning near the end of the game that all the trouble you've been dealing with - the four Fiends destroying the forces of nature - is the result of a time loop - some misguided fool (Garland) bringing these forces from the past, before they were destroyed the last time, to wreak havoc again - is pretty damn awesome. It adds a level of depth to the storyline (which, albeit, is still fairly primitive at this early stage), that I just didn't get from either of the first two Dragon Quests. Sure, you have the idea of the second Dragon Quest featuring the ancestors of the first, but none of it gives the game the kind of lore that the Lefeinish stories of the Sky Warriors and the ancient civilization that was destroyed (whose airship you recover, and whose Sky Castle you must infiltrate), or the seafaring village that has floundered since Kraken came along and trapped the mermaids in the Sea Shrine, do. And this element just gets better and better as you move through the series. Perhaps the later Dragon Quest games get more serious and involved, but at this point, the first two Dragon Quest games feel like just that - children's games - while Final Fantasy is serious business. A Saturday morning cartoon versus a fantasy novel. And I prefer the latter.

The Cave to Rhone in Dragon Quest II was a chore, but the Temple of Fiends: Revisited is a gauntlet. It is a shining example of a final dungeon in an RPG. Everything you've learned is put to the test - with many different floors, filled with different kinds of enemies, and all four of the Fiends you've fought coming back for a second round. And it's not just tough enemies that are thrown at you, it's lots of them. A Gas Dragon is a threat, but four of them together is a red alert! Even enemies like Frost Dragons, which were a challenge back at the Ice Cave, but that you've outgrown, can still be a pain, wearing down your HP and MP over the long haul - and the Temple of Fiends: Revisited is a long haul. Few dungeons in this game I've beaten in a single pass (The Waterfall, the Castle of Ordeals) - mostly because I like to collect all the treasure - but the Temple of Fiends: Revisited demands multiple passes (despite featuring a one way teleporter that you must use magic to outwit), with you getting stronger, and managing to get deeper each time you go in and make it out alive. To be fair, this was also the case in the endgame dungeons in the Dragon Quest games, but here it [somehow] feels more epic and adventure-y, and less boring and grindy.

The Katana is not as strong or as cool as I remember it (why does it look like a dagger!?). But the Masamune is the perfect sword for the Ninja - it's even Japanese! It's what the Katana should be. All throughout the game, my Thief/Ninja has been an inferior fighter compared to my Fighter/Knight, but with the Masamune, he's finally equal to or even better than the Knight. In the past I've usually given the Masamune to the White Wizard to make her a decent fighter (it's awesome that anyone can use the strongest sword in the game; it really improves combat strategy customization), but this time around I'm making better use of the free-cast items than I ever used to (I always treated them as a gimmick and never used them to their full potential before), and my White Wizard is a full time healer, so the Masamune fits in the Ninja's hands like a glove.

It's interesting to note that I found the first half of this game more challenging than the second half. The Marsh Cave, the Earth Cave, The Gurgu Volcano, the Ice Cave - these were harrowing challenges. It's not that the rest of the game was easy, but I think that your lack of abilities and equipment in the first half makes the game scarier. Getting poisoned on your way to the Marsh Cave is debilitating because Pures are expensive, and you don't have the spell yet. Getting petrified in the Ice Cave is similarly devastating. In the second half of the game - particularly after the class change - you're more or less equipped to deal with any challenges that are sent your way (and lots of high level equipment is to be found as early as the Sea Shrine). I'm not sure it's a bad thing, and it's certainly nice to feel empowered by the end of the game (and it's not like the final boss wasn't still a challenge for me at Level 27), but it's an interesting thing to note.

The battle with Chaos was actually more challenging than I was expecting. Even though it's the final boss, I thought he'd be kind of a pushover like most of the other bosses in the game. I remember him using Fire 2, Lit 2, Ice 2 and wondering why he didn't use stronger spells (being the final boss and all...), but this time he used those spells plus Fire 3, Nuke, and a bunch of original spells I don't remember - Crack, Swirl, Inferno... (It's entirely possible that I leveled my characters up too far the first time I beat the game). It's nice having an opportunity to go all out in at least one battle, using all the buff skills to improve your attack and defense and magic defense, and not holding back on any of your magic that you never felt the need to use in any other battle. Things took a turn for the worse after Chaos used Cure 4, and I ended up beating him in a last desperate struggle with only my Ninja left alive in the end (after spending most of the battle stunned, since Chaos can paralyze with a hit). It was pretty awesome. I'm satisfied.

Although the combat in this first game is pretty primitive, that battle with Chaos gave me a sense of all the best battles in later Final Fantasy games where strategy and endurance pay off, and the battle really feels like a challenge - not so much frustrating as exciting. Plus, I love the first occurrence of the boss fade here, which gives the game a certain level of finality. The ending text isn't much of an ending, and it's a little cheesy and tries too hard to explain the convoluted details of the whole time loop subplot, but it at least has more narrative depth than the endings in either of the first two Dragon Quest games ("You get to marry the princess! You get to be king! The End"). I can't wait to play Final Fantasy II! But first, I think I'm going to tackle Dragon Quest III. Just between you and me, I hope the DQ team learned a few things from Final Fantasy!