Building a Ship (Map)

The on-ship cutscene is a staple of classic RPGs. Although in the first Final Fantasy, there was no separate map to indicate being on board the ship (or airship), I seem to recall one in Final Fantasy IV (probably just before the entire gang got attacked by Leviathan), and there were certainly scenes of that nature in Final Fantasy VI - even more so if you include the airship.

Well, in my work on the harbor town I'm designing, and the nearby sea shrine, it came to me that I'm going to need to have a scene on board the ship that your group eventually acquires the reins to. Trouble is, RPG Maker VX Ace does not include a tileset to be used for designing ship maps. I found a couple custom tilesets designed by fans, but they leave a lot to be desired.

It turns out that a previous version of RPG Maker - RPG Maker XP - did have a ship tileset. And I realized in another light bulb sorta moment that, just like you can download the RTP for RMVXAce, you can do so (on the very same webpage) for both previous versions of the program RMVX and RMXP! And then, you'll have access (in your Common Files) to all the default tilesets, graphics, music, etc. from those versions of the program!

Well, I thought, hey, this might be a way to grab some extra materials to develop with. Like, for example, the battler graphics (graphics for monsters you fight in encounters), are good enough, but the variety is too limited. I'd be happy with more in the same style, so they all look consistent, but there's just not enough included with the program. Well, it turns out that VX's graphics are very similar to VXAce, only a bit more primitive, and barely anything new that VXAce doesn't already cover.

XP is further removed from the VX series, so you'd think it might have more options, but the drop in quality is considerable. Plus, as far as the battler graphics are concerned, there is way too much emphasis on humanoid enemies (as opposed to more animal-based enemies like my game requires). Also, XP used a graphical standard where the characters were two tiles tall (I think I've seen people refer to it as "mack", but I don't know what that means), instead of the "chibi" one tile square standard that VX/Ace uses.

Personally, I prefer the one tile standard, even if it distorts the character more, because it more accurately reflects the graphical style of the classic Final Fantasy RPGs I'm drawing most of my inspiration from, and that was one of the compelling reasons that led me to get my hands on VX Ace when I had passed on many of its RPG Maker forebears. Anyhow, the fact that XP uses two tile tall characters means a lot of the graphic proportions are unsuitable for a game designed with VX/Ace. :-/

However, for the ship tileset, I'm willing to make an exception, because there really aren't any satisfactory alternatives that I've come across. But, it's not a pretty compromise. I had to modify the actual dimensions of the tileset file so it works in VX Ace. And, as far as I can surmise, RMXP used a system that involved many more layers of graphical superposition so you can, for example, lay the mast down over top of the ship's deck. This is harder to do in VXAce, without carefully manipulating which tiles go on which layer, but it can be fudged by using events (for which you can select a graphical tile, and place over top of the actual map).

But that's not all. It's a bit hard to figure out where all the ship tiles are supposed to go, and how they're supposed to be used. I unfortunately don't have access to any kind of sample map from XP, like I do in VX Ace, to see how the designer was intended to use the ship tiles. You'd think it'd be a simple enough matter to figure out via trial and error, and it more or less is, but one thing that confounds me is that the back of the ship doesn't fit together with the front. For the life of me, I don't know what's going on there, and I wish I knew how XP built a ship, because to me it looks like it can't be done with the tiles included.

Anyway, I actually went in and graphically modified the relative positions of some of the tiles, so that the back and the front of the ship match, and did my best to build a decent ship map - inside and out. It's not very shiny, but I think it's good enough to use. Go ahead and take a peek at it:

I'm going to give you a link to the ship tileset files I used, adapted from RMXP to work in RMVXAce, with the back of the ship adjusted to fit the front. Note that I used a lot of events, especially for the mast, but also for the overhang on the front of the ship, to get it looking the way it does in my map. All you have to do is import the files into your tileset folder, and then add them to a tileset in the Database. I recommend making a new one just for ships. You'll probably want the ocean tiles, and I also put the wooden plank floor tiles in files for the A layer (so you can place other stuff on top of them) - I'll give you those, too. Make sure you set the passability settings in the Database so the program knows where to let the player walk and where not to.

Ship_A1 - ocean tiles

(place this in the A1 slot since they're autotiles)

Ship_A5 - floor tiles

(place this in the A5 slot since they're not autotiles)

Ship_Bfix - first half of the ship tileset, with modified back of ship

(place this in the B, C, D, or E slot - these tiles go on top of A tiles)

Ship_C - second half of the ship tileset, mostly interiors

(place this in the B, C, D, or E slot - these tiles go on top of A tiles)

Disclaimer: I can't seem to figure out how to get the translucency to work. The transparency should work fine, but if the shadows under some of these tiles seem a little blunt, that's why.

Note: You can place any other tilesets in the remaining B, C, D, and E slots (whichever two you didn't use for the ship tilesets). For example, I put Inside_B and Inside_C (standard Interior tilesets that come with the RTP) in the D and E slots for some basic interior stuff (beds, shelves, etc.). It's up to you.

Good luck! And if you find a more elegant solution to the lack of a ship tileset in RMVXAce, please let me know what it is...

Progress Report

My last release seems to have given me some respite, but I've still been hard at work developing. You might be surprised by how much work it takes to put a game together - not just technical work, either, but conceptual work, too. You have to figure out what shape you want before you can start filling it in. Anyway, here's three things I've been spending a lot of time on in the ten days since my last alpha release.

The next time you visit Grassland, it may be a little different than you remember it. I'm not sure what possessed me to build an actual school - although I was very excited about it and hope to feature it at some other point in my game - but my original concept called for something a little more primitive, less modern. Namely, an Elders Council, where the village elders (those with the most experience and, presumably, wisdom), confer on matters related to the running of the village, as well as take the opportunity to teach the young ones and collect whatever wisdom they have in the form of a small library.

Besides, Grassland is a small village, and a school the size I had previously made just begs for a certain number of students, which makes an uncomfortable assumption about the population of the village. And the graduation thing was already more of a big deal than I had wanted to make it. My own assumption was that the ceremony itself would have already been completed, and the picking up of the diploma was more of a formality than anything else. At any rate, it works more smoothly, and much more like I wanted it to, with a smaller Elders Council, and now I can go about adding that element to the other villages I'm working on.

Speaking of which, I've been spending a lot of time on that harbor town I believe I mentioned previously (or did I?), and an associated sea-related dungeon. An interesting thing I've noticed is that for a map to come together, it needs a 'hook'. I was stuck for a while thinking about how to make the harbor town work (i.e., look good, and feel fun to explore). I knew it was going to be a beach town, with a pier, but it wasn't until I decided (in a great "light bulb coming on" sort of moment) it was going to have a boardwalk that it really started coming together, and I started feeling good about it. I had a similar problem designing the forest town (Splintwood) that featured in the last release, until I figured out the hook - the town needed a lake!

So since the harbor town's come together, I've been spending more time on some of the plot elements that occur in that town - it's actually a really cool scene (or set of scenes). A lot of the stuff I'm putting in to my game I have to kind of make up as I go along, because I only had room for so many details in my head before I started putting this game together. But this is one scene I've had in mind from a long time ago. It also involves meeting another member of your party - a new playable character that I haven't introduced yet! Although, it also happens a bit later in the game, so I don't have it connected up with the other stuff you've seen in the demos yet, and it's not the first extra character (beyond the first three) that you meet up with.

That first one is actually a very important character, that I've been spending a lot of time trying to work out how to get into your party. She's a character that I think is suited to joining your party early, gameplay-wise, but on the other hand, she has access to crucial plot elements that I don't want to surface until much later in the story. So it's been a bit of a struggle figuring out how to make that work. I think I've got it mostly worked out, but I've still gotta put all the pieces together (more towns and dungeons and things) before I get to the point where it actually happens.

But, the past several days I've been totally and exclusively absorbed into something that is almost a side-priority. Basically, it amounts to picking out a wardrobe for my playable characters. But, I want it to be just right. I want the characters to all have their own sort of color scheme, and they have to each have so many outfits. A lot of them are necessary for the game, for various scenes, but I've also made the decision that I'm going to include "alternate outfits" for your characters to wear - possibly as a bonus unlocked after beating the game the first time, to improve replay value and give the player something fun as a reward.

It may be entirely superficial, but I've long considered alternate outfits one of the most fun and most desirable unlockable extras in games that I play, and so I definitely want to include that option in my game. I'm actually really excited about it, and that's partly the reason I've been putting so much time and work into picking out all the right outfits (from the limited selection available to me in the program software) over the past so many days. You might not think this sort of thing would take days of continuous effort to complete, but, well, you'd be wrong. I'm just about finished, though (with room for adjustments to be made in the future, if needed), although it would probably be prudent to develop some kind of "wardrobe manager" or something.

The work never ends!

Alpha 3.0 Release

Believe it or not, here's another demo (not sure if "demo" is really the best term, maybe "alpha" would be better?). I've made a lot of small and cosmetic adjustments to the prologue and Grassland section, and appended a brand new forest town and related dungeon. The game opens in the Developer's Studio (modeled after my current apartment), where you can access some special Developer's Tools (added by request), before selecting whether to start the game from the beginning, or from where Demo 2.0 left off (with approximate stats/equipment).

While the prologue and Grassland area is slightly refined since the last demo (gosh, has it already been half a month?), the new stuff is maybe a bit rougher than you might have come to expect (the town, for example, is sparsely populated, and not all of the enterable buildings have been completed). I just don't have the desire to spend a lot of time polishing it up right now when I really need to be fleshing out the rest of the game first. But I'm pretty satisfied with the skeleton of it, and I'm really proud to show off the new maps and the second dungeon quest. At any rate, this release ought to keep the vultures happy for at least a day or two. :p The combat balance may be far from perfect for the new areas, but I tried to make it at least reasonable. I must also remind you that the world map is currently a "SparkNotes" version of the landscape, to be fleshed out in full later on down the line.

One other note before you dive in. One of the things I've added to this release was what I've taken to calling the "Monster HUD", which is basically just a visual display for the "encounter clear" system I've worked out so far. In lieu of explaining it all right here, I'll let the in-game tutorial and your own experience do the talking. I had to break down and utilize some scripts to get it working, but I found some nice, simple ones that I felt comfortable with. I might change the mechanics of the Monster HUD in the future - so feedback would be helpful. But that's something to look forward to trying out.

3/15/14 Dragonfaith Alpha 3.1 (33.6 MB)

I haven't pored over this version as much as the previous two, so if there are any glaring errors I missed, I apologize. However, please let me know, in that case, so I can fix them.

Edit: Speaking of glaring errors, I forgot to let you keep all those nifty Developer's Tools after you leave the Developer's Studio and start the game. It has been fixed in version 3.1.

Steps to Next Encounter (and my very first script!)

Even before I started building my game in RPG Maker VX Ace, I had in my mind an idea for an optional alternative to the usual random enemy encounter system. Now, as far as that standard system goes, I have mixed feelings about it, because, like everyone else, I understand and recognize that random encounters can be annoying, to say the least, and do definitely have a discouraging effect on the player's exploration of your maps. On the other hand, they do serve a purpose, increasing the feeling of "danger" in unsafe areas, giving the player something to do on a map, introducing the need to weigh the risk of searching for treasure against the cost of fighting more battles; and they're intricately integrated into the basic gameplay style of your classic RPG. Not to say that there aren't alternatives, or that there haven't been any RPGs that have explored other possibilities (some with great success), but I am very reluctant to throw it out altogether.

Therefore, I'm open to nonstandard alternatives. The most popular alternative is probably on-screen encounters, which is something that Chrono Trigger (the best non-Final Fantasy RPG ever made), and also the much-maligned Final Fantasy Mystic Quest used (in part). And while this is a nice option, I don't feel it's suited to every RPG style, and, unfortunately, RMVXAce's included sprite graphics are very limited in the monster category (even more so than their in-battle "battler" graphics), making that option pretty undesirable without seeking external graphical support.

Well, the idea I had in mind for my game was the possibility for the character - being affiliated with the Hunters Guild, whose goal is to eradicate monsters in the wild - to choose the option of, instead of waiting around and letting the monsters come to you, taking a more proactive stance and initiating a series of continuous encounters, after which the map the player is on will be entirely cleared of encounters. This way, you can actually separate the adventure and battle portions of the game play, and not have the one constantly interrupting the other. I think that that could potentially be preferable, as once you're in battle mode, you're probably less resistant to the idea of continuing to fight, whereas when you're in the middle of exploring, the last thing you want is a battle popping up out of nowhere to distract your focus.

Final Fantasy Mystic Quest actually had something like this, outside of the dungeon maps (which used on-screen encounters), in the form of "battlegrounds" (or whatever they might have been called), where you'd have to fight ten (I think) battles in a row in order to vanquish it and move to the next spot on the map. It's very similar to what I have in mind, although I would integrate it more into the rest of the game, rather than standing apart from the dungeons, and be an optional alternative to the classic random style of encounters. The only thing is, I haven't yet worked out all the kinks of how I want it to function, and that's hampering my progress on actually developing it in my game. Like, do I want vanquished maps to stay vanquished, or reset once you've left them? Do I want the players who choose random encounters to still have the option of "vanquishing" after a certain number of those random encounters, or not? And if so, can I actually do that with the program available to me?

So I've been exploring how the random encounters actually work in this program, for a better understanding of what options are open to me. It turns out that the game's random number generator is a bit less-than-ideal: for example, if you set a map's average steps between encounters to, say, 15, you will be just as likely to get one step between two encounters as you will 29. But that appears to be easy enough to modify just by changing the equation. One other very interesting thing I've learned is that after every battle, the game calculates a random number of steps (within the set bounds) until the next encounter, so it knows exactly when your next encounter is going to trigger (as opposed to, say, flipping a coin with every step).

With that knowledge came speculation about random encounter "gauges", as I've heard some other games have done, which use some kind of visual cue for the player (overlaying a picture onto the screen would be a simple matter in RMVXAce), to warn them of an impending encounter - like a symbol that changes color or flashes red when the encounter is near. I'm not sure if it's something I actually want in my game - although I can see how, without changing how the encounters actually work, it might be less jarring to the player if they can anticipate a battle that's coming up rather than being completely surprised - but I was possessed with an uncanny desire to code one myself, just to see if I could do it.

Honestly, it seemed easy enough. I was even able to pry into the scripts behind the engine, and locate some of the terminology being used to determine this hidden value that dictates the number of steps between one encounter and the next. But for the life of me, I couldn't figure out how to access that value (or the variable that presumably holds it) in an event for manipulation, even with the simple script calls I was trying out. I knew the value was there in the code somewhere, and I even thought I knew where, yet it remained - frustratingly - out of reach. I got so annoyed with it, that I actually started learning some of the basics of coding in "Ruby", in the hope that it would help me understand the code - or read somebody else's script that did what I wanted to do.

It was a frustrating effort, but I learned enough to figure that if I couldn't access the value directly, I could modify the code and add in a line that assigned the value I was looking for to a game variable that I DID know how to access. And voila, it worked like a charm. I even went so far as to learn how to write "aliases", so I could add in a new script that modifies what the game does, without changing the code on the original page - that way if there are problems in the future, I can easily revert to the default. It's almost crazy to think it, but I actually wrote a custom script of my very own! Granted, it's extremely basic, and doesn't change the actual functionality of the program, just assigns a couple of values to a couple of easily-accessed variables, but still!

By the way, if you're working on a game like me, and you'd like to access said values - namely, the number of steps the game chooses before initiating the next encounter, as well as the running count of decreasing steps left until that encounter - feel free to use this script. Because it doesn't muck around with functionality, there really shouldn't be any compatibility problems (but then again, what do I know?), but you do have to make sure the variables in this script aren't being otherwise used in your game (by yourself, or by other scripts). I chose variables number 50 and 51 just because they were empty, and I wasn't using them. You can change those two numbers to whatever you want, to correspond to two different game variables you aren't using. Then, you can access their values just like any other variable you're using in your game! You can use them to make a countdown or gauge that measures steps until the next encounter in a way that either you, the developer, can make use of, or the player can see! (I imagine it would be a simple matter of using a parallel process event that changes a picture overlaid on the screen).

Here it is. All you have to do is copy this text into an empty page in the "Materials" section of your Script Editor, and give it an appropriate name (I called mine "encounter variables"):

class Game_Player < Game_Character
  #mods Game_Player line 193-6
  #stores total number of steps until next encounter in game variable 50
  #change 50 to whatever variable number you want to use for this value
  alias :zharth_make_encounter_count :make_encounter_count
  def make_encounter_count
      zharth_make_encounter_count
      $game_variables[50] = @encounter_count
    end
    
  #mods Game_Player line 378-84
  #stores number of remaining steps until next encounter in game variable 51
  #change 51 to whatever variable number you want to use for this value
  alias :zharth_update_encounter :update_encounter
  def update_encounter
    zharth_update_encounter
    $game_variables[51] = @encounter_count
  end
end

Just a couple notes, though. First, the countdown value, that decreases with every step, and initiates an encounter when it hits zero, doesn't update until the player's taken their first step after the last encounter. So, be careful if you have something happening when the counter is at zero, it'll likely trigger after the battle instead of just before it. Also, the way the game works, certain tiles are designated as "bush" tiles - usually forests on the world map, and grass on other maps (these can be changed in the Database on the Tilesets tab) - and these tiles actually decrease the "steps until next encounter" count by 2 steps, not just one. As a result, sometimes the counter will drop to -1. Also, since the counter could jump from 2 to 0 in one step, you want to make sure that any indicator that occurs just before an encounter doesn't happen too late for the player to see it. Also, the steps counter decreases by only 0.5 for every step when the player is driving the ship vehicle. (These settings can be modified via scripts if you need).

The other thing worthy of noting is that the steps counter remains active even when the player is standing on tiles that are not designated for random enemy encounters. If, for example, you have a road that serves as a safe space, with no enemy encounters, the counter will still decrease as the player walks along the road. If they step off the road, they will still trigger an encounter when the counter reaches zero. If they remain on the road when the counter reaches zero, it will merely reset without initiating an encounter. I can see how this behavior could be abused by a player - especially if they are being given a visual cue as to when the next encounter will occur - in the form of stepping on the road as soon as the encounter is supposed to trigger, allowing the counter to reset, then venturing back out into the dangerous area. This wouldn't be an issue, however, on maps with no or very minimal safe tiles. But maps that do have such areas might invite confusion for the player if the visual gauge is flashing red while the player stands in a safe area, and no encounter initiates. You might be able to get around this by turning any such visual cues off on those tiles, but that could become tedious, or not look very smooth or elegant. I leave consideration of such issues up to you.

Progress Report

For those of you keeping track of the progress of my game, and eagerly anticipating the release of each new demo, I should warn you, I'm not a linear game developer. I put together the prologue early, because it was one of the clearest scenes in my head, and afforded a great opportunity for me to learn how to put together a cutscene (aided greatly by this guide, which I recommend to each and every beginner; considering how important events are, I'm surprised the provided tutorials don't do such a good job explaining what they are and how they work). And I began building the first village because it seemed - logically as well as practically - a good place to start. Now, once I got started, I was very excited and eager to have something to show to the few (but important) people who were anticipating my game, and to show off all the exciting things I'd learned to do in just the first week of marathon developing. And because I was limiting myself largely to one self-enclosed village, my progress seemed well suited to be demonstrated in a, well, demo.

Fact is, I've spent an awful lot of time polishing the events in that first section of the game, specifically so that I could release it in a coherent format for people to play through. And the truth is, a lot of it may change as progress on the game as a whole develops. Now that I've got something out there, and I've got a foothold in the opening section of the game, I have a lot to think about regarding the rest of the game and where all the pieces are going to fit in, and filling the holes in the story, and about many questions regarding some of the very basic elements of gameplay (like going back and forth on making medic skills item-based, or using MP, despite them not being magical in nature) - many of which are constrained in various and often unexpected ways by the program I'm working with (and though myriad scripts abound that change the way the program functions, I'm taking, at least this early in the development process, a simplistic and puritanical approach - if it can be done without scripts, that's my first choice, and if it requires scripts, then I have to think long and hard about whether there's another way to do it, and if it's something I want or need bad enough to go the script route).

So anyway, here's a list of some of the things I've been working on, and maybe even some that I've accomplished, since releasing my second demo:

* I have Dragon Island all mapped out. I've actually had this done for a number of years already - using tiles pilfered from the Final Fantasy 1 world map. Now, I have it all ported over to RMVXAce's tilesets. Their beaches aren't as nice and rounded, but I worked it out. Dragon Island is a location you travel to near the very end of the game.

* Following the completion of the second demo, I did move on a tad bit linearly and worked out a rough draft of the second town you visit, which is smack dab in the middle of forest country. I've also got the second dungeon all mapped, with what I think (and hope) is another awesome cutscene at the climax, which ties in to your reason for going there in the first place. It's a tree-based dungeon - a little bit more dungeony than the hillside the first dungeon was, but not quite full-on dank cave...yet. I'm very excited about it.

* Other than that, I've been spending an awful lot of time familiarizing myself with RMVXAce's tilesets - particularly the world map terrains and, more recently, the dungeon tiles, to help spark my creativity, as well as get a feel for what kind of environments I'll be able to craft in my game. I don't have the main world map for my game mapped out yet, and I don't even know all the towns and dungeons that are going to turn up, so that's something I need to explore and flesh out as the game slowly grows.

* I have created a really neat tropical island, which I believe is going to be the location of a hidden  (but still crucial to the plot) town that you visit later on in the game. The town itself is sort of half-built at this stage, but it's another one I'm especially excited about (which is, probably, the reason it's one of the ones I've started on first).

* I also, just last night, was playing around with some dungeon tiles, and got the first level of a later dungeon mapped out, which is a very cool homage to the Sea Shrine from Final Fantasy I. There are going to be a lot of homages, or some might say, rip-offs, of the first six Final Fantasy games, and probably more than a lot from the first Final Fantasy, in my game. But the way I view it, honestly, is that I'm inspired by what those games did. I'm not trying to recreate something that's already been done, because I do have an original idea for my RPG. But I like a lot of the stuff those other RPGs have done, and so I want my game to feel like a cousin, like it belongs in that universe of gameplay, and since those games were so good, I want to borrow the genius of what made them so much fun to play.

* Other than that, I've also got four more playable characters sketched out, three of which are still as yet unnamed, with loose ideas in my head of how they enter the story and join the hero's quest. I don't want to say much about them until they have their chance for a proper introduction in the game itself, but I can say that I'm trying for a good balance between skill types and gameplay, echoing the differing roles of the starting party - fighter, support, medic. I think that, in lieu of the Final Fantasy IV system, in which playable characters come and go, never exceeding the maximum number of slots in your party,  I'm going to have a point where the player gets to choose between the characters available, based on who they like, or whose skills they like, and how much they want to balance (or skew) their team. But there's still lots of time yet to work that out.

Tile IDs and Terrain-Dependent Battle Backgrounds

On most maps created in RPG Maker VX Ace, a "battle background" must be specified for enemy encounters (whether random or by call from an event), otherwise a less-than-satisfactory swirled composite snapshot of the current map is used. However, "world map" or "overworld" maps (designated by using the "Field" tileset) utilize a different behavior, in which the battle background chosen for an encounter if not otherwise specified depends on certain presets that correlate to the type of terrain the player is standing on when the encounter is initiated (e.g., grass, desert, snowfield). When the player is driving a vehicle (excepting the airship, which is not susceptible to normal random encounters) the ship background is used.

A variety of battle backgrounds

This is a pretty handy default, although it may not be sufficient if you'd rather have a more fine-tuned system (for example, I don't think it looks right to have an open seas background when you're paddling down the river). Normally, for dungeon maps, you'd only really need to set a single background for more or less all of the encounters, and this can be done in the map properties. But because the world map often involves multiple varied terrains, a single determined background just isn't going to cut it.

Now, you can, I believe, use region ID codes (which can be freely placed on maps, and are usually used to designate regions containing a specific set of encounters) to trigger different battle backgrounds, although I feel that may introduce some confusion for the developer, as it splits the use of region IDs across two separate purposes. Terrain tags may also be used, which are linked to the actual tile graphics themselves, although you can only denote 10 such tags (as opposed to the 64 region IDs), so they are much less useful in this case. I ended up utilizing the tile IDs instead, which are ideal - since you can designate the battle background through event (without mucking up the way anything works on other maps) - but a little tricky because you have to figure out what the tile IDs are for the tiles you're using in the first place.

I ultimately decided that I would have to use my own terrain-specific background system while I was working on an airship random encounter, inspired by the Doom Gaze enemy from Final Fantasy VI. For developers' reference, action button and touch events don't trigger while you're on the airship (but they do on the boat or ship). Otherwise, you'd find yourself entering towns in your airship just by flying over them, and that would be...awkward, to say the least. But, autorun and parallel process events will still run when you're in the airship, and so I used the latter to rig my airship random encounter.

Doom Gaze attacks sporadically when you're flying around in the airship in FFVI

It worked swimmingly, except that the system-designated battle background was, like the other vehicles, the ship background. The ship floor looked fine enough, but having the ocean, instead of the sky, in the background, was all wrong. So I manually set the background for that encounter to the one I wanted. Problem was, after I got off the airship, and ran into an encounter on a snowfield, the background was still specified as the ship+clouds background I had set for the airship encounter. And though I could respecify the background after getting off the airship, I couldn't revert it to its default unspecified state, thus triggering the automatic terrain-dependent backgrounds the system falls back on (trying to set the background to "none", by the way, just causes it to use a black screen as the background).

So I figured, if I want this to work right, I'm just going to have to knuckle down and create a system of my own that selects the backgrounds I want. The good news is that it's doable just by using a single parallel process event (per overworld map, if you have more than one) that recurringly checks the player's x and y coordinates. The bad news is that figuring out the tile IDs that the event checks the coordinates against was a bit of a pain in the ass. You'd think this was one of those things listed in the owner's manual under "specs" or something (and maybe it is - but I couldn't find it). At any rate, it is possible to brute force it, enough to get the pattern down and fill in the blanks.

First, though, you have to have a basic understanding of how autotiles work (which most of the overworld terrain tiles are). My first thought was that I could look at the tilesheet, and just count the tiles 0, 1, 2, 3, from top left to bottom right, but the way the autotile system works is that every autotile on the sheet corresponds to some 47 different tiles (depending on how its borders are oriented). Not only that, but the first tile begins at ID number 2048, and not 1 or even 0. This tutorial by Nick Palmer is an excellent discussion of how those autotiles work, but it stops short on listing the actual tile IDs, or even identifying which tiles in the pattern are the first and last (which would facilitate identifying the number at which each terrain type gives way to the next one).

So I just figured it out myself. And I'm gonna tell you what they are, so that if you find yourself in my position, you won't have to repeat all the grunt work I've just done. First, I played around with the shallow sea tiles (because that's the first terrain on the tilesheet), and rigged up an event that displays the tile ID of the tile the player is standing on when he presses the shift (dash) button, so I could jot them down. As it turns out, the tile with the lowest numerical ID within any autotile set is the one with no borders (the "center" tile), and the one with the highest numerical ID is the one with borders on all sides (the "lone" tile). After figuring that out, it was simple enough to just find out the lowest and highest IDs for each of the subsequent terrains. For what it's worth, though, here's a graphical representation of each of the 47 tiles in the autotile set, in order, from lowest numerical ID to highest. I assume the other terrains work similarly, and at least, the lowest and highest tiles have born that theory out.

The ID range for the rest of the terrains in the A layer Field tileset ("World_A") are as follows:

White numbers denote layer 1 IDs, green numbers denote layer 2 IDs.

Note that the tile ID actually has three layers, which correspond to the graphical layers on which the tiles are laid down. Layer 3 corresponds to the B, C, D, and E layers, so, in the case of the Field tileset, that would be towns and castles and things like that. The A layer, which is the one we're dealing with, includes both layers 1 and 2 of the tile IDs. The trees and mountains and things in the lower right corner of the tilesheet go on top of the ground, so they are all designated with layer 2 IDs. You'll notice, also, that the deep sea tiles are marked by layer 2 IDs. This is because they are actually placed on top of the shallow sea terrain. This is also why the sea add-ons, like the rock shoal and the icebergs, when placed on deep sea tiles, change that tile to shallow sea, instead of going on top of the deep sea. Some of these terrains have IDs that do not span the full 47 values; this is because they are not autotiles (they don't have variable borders). Incidentally, if you wanted to find the layer 3 tile IDs for the B, C, D, and E layers, you'd probably have a much easier time, as they don't include autotiles, and you can probably just count them off from the tilesheet (but I haven't actually tried it out).

Layer 2 (or 3) tiles placed on top of layer 1 (or 2) tiles (like trees on grass, or deep sea over shallow sea) will retain the lower layer ID of the ground tile, in addition to the upper layer ID of the add-on. This is something you'll have to account for in your conditional branches if you're designating different behavior for different combinations of layers. For example, shallow sea and deep sea tiles will both have layer 1 IDs in the range of 2048-2094, but the shallow sea tiles will all have layer 2 IDs of 0, whereas the deep sea tiles will have layer 2 IDs in the range of 2096-2142. As another example, pine tree forests will always have a layer 2 ID in the range of 3056-3102, but their layer 1 ID will be determined by the type of terrain the trees are sitting on. Tiles like the swamp tree, lava bubbles, waterfall, cloud, pond rock, and whirlpool, despite appearing to be add-on tiles, are actually stand-alones, and are designated by their own unique layer 1 IDs. It is also worth noting that for the 16 types of terrain in the bottom left corner of the tilesheet, each tile with a layer 2 ID is automatically placed upon (and therefore carries the layer 1 ID of) the terrain to its immediate left (exactly like the deep sea goes on top of the shallow sea).

tl;dr - If you ignore everything else, the real meat of this post is that last image above. I hope it proves useful for somebody somewhere someday.

A Prefab Smithy

So here's what I accomplished today - a prefab smithy. It's pretty simple. You go in, and the swordsmith will craft a sword for you. I intend to integrate this into my game at some point, but for right now I took it as a challenge and just wanted to see if I could put it together and get it to work. Getting some of the animations to work right was a little tricky (fine tune controlling of those step animations is a bitch), but I think I got it running pretty smoothly. I copied it to a blank project so I could upload it and let you guys try it out for yourself. Everything except the smithy and the basic sword weapon is the default the program starts with. It's not encrypted, so if you have RPG Maker VX Ace, you can open it up and see how it works. If you want to use it or modify it for your own game, be my guest.

Download: Smithy (1.47MB)

World Map and Game Flow in FF1

Among the inspirations for my RPG - and I am making no attempt whatsoever to play this down, as the creation of my own RPG is in a way a celebration of my love and appreciation for the RPGs I have played in the past - are the original Final Fantasy games on the NES and SNES; in particular, the first, fourth, sixth, and fifth games in the series (I list the fifth last and out of order only because I did not play it at the same time as the others, but many years later), because they had the most impact on me, and because the later Final Fantasies, from VII onward - despite being good games in their own right - have a completely different feel from their 2D sprite-based ancestors which I am hoping to honor with my own game.

If I were to rate the quality of the games, I think that IV and VI (and also V, I later learned) would be the best, because they have a greater sophistication than the earliest titles in the series. At the same time, the very first Final Fantasy holds a lot of nostalgia for me, and there are qualities to it I like very much, such as the elegant simplicity of the gameplay - which is something I'm striving to imitate in my own RPG, given that this is my first attempt and I don't want to get too bogged down in complicated mechanics. There was also a feeling of danger to it - a certain challenge - that made you feel like you really had to have your wits about you to survive, and that made it feel more wild and untamed than later entries in the series.

Thinking back on, for example, the difficulty of the Ice Cave - sure, it may have been frustrating, but beating that part of the game required a concentrated effort, and so when you finally did gain the Airship, you felt a sense of accomplishment, like you had truly earned it. Of course, managing the difficulty of a game requires a delicate balance between challenging the player, but not to the point of making him want to give up on it, and I may not be up to the task of leveling those scales. Also, there is the issue of wiggle room, where the freedom you give your player to choose to either grind for levels or plow ahead will affect the difficulty of the game, particularly in instances where the flow of play is not strictly linear. Nowhere is this more apparent than in the optional Castle of Ordeals in the first Final Fantasy, which, if attempted just after the Ice Cave, is challenging as it is supposed to be, given that the reward is the unique and powerful class change. But, though the upgrade is intended to help you in the later dungeons of the game, if you linger or try some of those out beforehand, by the time you reach the Castle of Ordeals you may find it somewhat less than the ordeal it was intended to be.

The reason I am reminiscing so much about Final Fantasy (the first) is because I've been spending a lot of time thinking about my own world map. I am really fond of the way that, as for example in FF1, certain areas of the world will be blocked off by certain natural obstructions (like seas and rivers and mountains), that are cleverly removed by the timely acquisition of specific vehicles or other events or items (such as the blowing of the canal to enable passage of the ship beyond the inland sea) throughout the course of the game. There may be a lot of "fetch quests" involved, but that is a hallmark of the genre, and I find it fascinating to explore the more and less linear progress of the game as different areas are unlocked. In fact, I made up a spreadsheet to chronicle all of the important locations and items in the game, and how they interact with one another in terms of the game's progress. I did it just for fun, really, because there are few things I like more than organizing ideas and information.

Now in true flow chart form!

See the clever way, for example, that, with the exception of Lich, killing the Fiends doesn't directly progress you to the next stage of the game, but is required to access the final dungeon. And also, that even though once you have the airship, you can apparently approach either of the remaining two fiends, in reality, access to the one is actually blocked by an item that can only be acquired deep in the dungeon of the other. I'm pretty sure, as well, that I once tried skipping the volcano and going straight to the ice cave, earning the airship, and beating the fiends of water and air before conquering the fiend of fire. But, instead of directly progressing the game forward, conquering the fiends actually contributes to a parallel counter that ultimately must be completed before the final dungeon can be accessed, which requires the completion of all major quests except for the optional (but very worthwhile) class change.

I know, I'm a total geek. But that's to be expected from someone trying to design their own RPG.