(For my fellow players, here is a link to the most helpful guide I found on this game).
I thought it might be helpful to go back and play some classic RPGs for inspiration. And in light of my recent decision to scale back the complexity of my game (at least from the start), the first Dragon Quest (known in North America as Dragon Warrior) seemed like the perfect place to start. It actually preceded the first Final Fantasy by about a year or so, and is at least an order of magnitude simpler.
I find the simplicity very appealing as a novice (and solo) developer, and I'm tempted to try building a bare bones proto-RPG as a practice exercise - to sort of teach myself the basics before I try putting together something more complicated, with multiple playable characters and such. Except, I'm not sure how confident I feel about diverting that time and effort from the game I really want to be working on (Dragonfaith).
But about Dragon Quest. I never actually played any of the Dragon Quest games until my friend gave me his NES cartridge not that many years ago, despite growing up on the Final Fantasy series (which seems to have attracted more popularity in America). But I've just finished playing through it for the second time ever, and I jotted down some of my (more or less scattered) thoughts while I was playing it:
* I knew the gameplay was going to be basic for a game this old, but wow - you have to select commands from a menu to do simple things like talk to people and use stairs!
* Combat utilizes a front-facing battle screen, where the monsters are drawn to face the player as he sits in front of the screen, and the hero is not drawn on the screen at all. This is interesting, because this is the default battle system in RPG Maker VX Ace, and it's not the one I'm used to - which is the side-facing battle screen of Final Fantasy.
* Very basic combat. Party includes only a single hero (as opposed to the first Final Fantasy's four-hero party), and you only fight a single monster at a time. This means that all the physical and magic skills are combined into one character. I like that, from a simplistic development perspective.
* I like the spells in this game. They're very basic, but functional, and there's a good mix of spells designed for combat (Heal, Hurt, Sleep, Stopspell), and spells that are useful outside of combat (Radiant, Outside, Return, Repel). No spell feels useless. Well, except Hurtmore, since by the time I learned it, I didn't really need it for anything except the final boss, and every time I tried to use it on the final boss, it failed, so I just gave up trying. But it's not like Final Fantasy where you have a ton of spells that do the same thing (Fire, Ice, Lit - although I do like the concept of elements), and a million different status ailments or enhancements, many of which work so rarely that you never bother using them.
* Stats begin in the single digits. I think this really makes a lot of sense. The default stats on RPG Maker VX Ace are totally out of whack, and have level 1 actors dealing hundreds of damage right from out of the gate. I don't like that. In Dragon Quest, you start with single digit stats. The first enemies are slimes that do 1 or 2 damage, and only have a few HP. You're evenly matched at first, until you begin to level up and then eventually the slimes are dust you brush off your shoulder. That's the way it should be. Your growth is gradual and starts from a reasonable point. By the end of the game, you're probably not more than level 20, and dealing a hundred damage at once is unthinkable (as opposed to Final Fantasy's 9999 damage cap at level 99). Again, we're dealing with a simpler system here.
* Here's something that I find very interesting. Unlike Final Fantasy, which uses a gated system (which I am admittedly fond of) whereby parts of the game world are opened up to the player gradually as they unlock certain obstacles (chronicled here), when you start Dragon Quest, the whole world (apart from the final dungeon alone) is theoretically open to you, and the only thing keeping you from going anywhere you want is that the monsters get stronger and you need to build up your stats first, if you don't want your ass handed to you on a platter. I actually think this is very clever.
* On the other hand, the downside of this is that the gameplay in Dragon Quest relies heavily on "grinding" - where you're fighting the same monsters over and over again just to level up - which isn't very fun. Later, more advanced RPGs have enough story content to keep you moving through the game, whereas here it feels like you're frequently getting stuck and you can't advance in the game without a whole lot of fighting the same monsters over and over again. It gives you more time to grow with the game, but it does it in a way that feels cheap, like filler.
* Dragon Quest features a very basic fantasy setting with conventional elements (e.g., a knight trying to save a princess from a dragon). While this is a very simplified approach and eliminates any concern for developing complicated story elements, it also greatly reduces the player's incentive to finish the game and find out what happens next, as they are probably not that invested in the characters or the plot (unlike the more advanced RPGs I know of).
* The dungeons are dark, and require a torch (or other light source) to be properly explored. This wasn't the case in Final Fantasy games, but I think it's a neat gameplay element. Although, the dungeons themselves are all very samey, and suffer from a lack of graphical variation (which is something that Final Fantasy, at least, succeeded on).
* There is, mostly, a logical progression in the weapons/armor you use. While I am fond of the Final Fantasy system of having tons of equipment with an at times arbitrary hierarchy of attack/defense power, I am also attracted to a simpler, more intuitive system where, instead of getting a new sword and set of armor in every town, you progress naturally through stronger weapons and armor (like from a bamboo pole to a club to a copper sword to a hand axe to a broad sword, or from clothes to leather armor to chain mail to a half plate to a full plate). This suits my RPG better in a conceptual sense, in that part of its genesis was inspired by a desire to introduce some level of realism to typical RPG cliches (explained here), but I have yet to come to a final decision about how I'm going to handle equipment in my own game.
* Considering the difficulty of getting magic keys - their high price
and the difficulty in originally getting to the town that sells them -
the reward is rarely worthwhile. Though there are some parts of the game
that require having the keys to advance, a lot of the treasure chests
and areas unlocked by them are bogus. It doesn't have the same feeling
of accomplishment as getting the Mystic Key in Final Fantasy, for
example.
* The only place you can save your game is at the king in the first castle. This is an interesting choice, conceptually, since it has to do with recording your deeds on the "Imperial Scroll of Honor", but I don't think I like it, from a more practical perspective. Gameplay is inevitably centralized around the first castle (instead of moving from town to town as you progress through the game), such that the last time you load up your game, to brave the final dungeon and battle the final boss, you start playing from the same spot you did when you first started the game (and even though the final dungeon is tantalizingly in view of the first castle, it requires a roundabout trek to access it).
* This means that there's a lot of tedious coming and going, particularly in later parts of the game (and with no vehicles to speed things up). The world map is not super humongous, but you have to consider all the time spent traveling through early areas later in the game. Already, at level 10, fighting slimes is nothing but an annoying waste of time. They can in no way threaten your safety, and the paltry reward you get for killing them isn't even worth the effort of squashing them under your boot. And yet, you can't ignore them, because they keep throwing themselves at you like pests!
* You do learn a handy spell (Repel) to solve this problem, but considering that it only works on weaker enemies, and is therefore only a convenience, and not a significant battle advantage, you learn it much too late in the game (level 15).
* Maybe this is just me (I tend to play games in the same risk-averse fashion that I live my life), but the difference between tiers of enemies often seems to be life and death. If I'm on the verge between one tier and the next, I find that there's a tedious period during which I'm strong enough to beat the lower tier without breaking a sweat, but still weak enough to be wiped out by the larger tier in a single battle. Which means, rather than risking my life to fight the stronger enemies which would earn me more experience so I can level up faster, I'm stuck mindlessly fighting the weaker enemies at a slower rate of progress.
* On the other hand, death in this game only means that you lose half your gold and have to start back at the castle. Losing all that hard-won gold is unacceptable earlier in the game, but it seems that there comes a point later on when you max out your buyable equipment, and gold becomes pretty much useless to you.
* I don't know if there's even any point in worrying about this being a spoiler, but all I'll say is that the choice the Dragonlord gives you at the end of the game (and the penalty for choosing unwisely) is ingenious.
Concluding Remarks: I understand that Dragon Quest was an extremely influential pioneer in the realm of console RPGs, paving the way for the likes of the immensely popular Final Fantasy series (among other games), and nothing can take that away from it. Taken on its own merit, it's still a fun and creative little game, allowing for its unavoidably primitive nature (and in some ways, the simplicity can be appealing).
However, I consider the alleged tweaks that have been made to better balance the combat in recent "remixed" versions to be fixing the game (as opposed to tinkering with it), as in its original state, the grinding can become frustrating to the point that only a diehard old school RPG fan would have the patience to play it through to the ending. I feel like I spent about a month longer on this game than I should have - given its simple story - and much of that time was spent dragging my feet because I was too bored to sit and grind for another hour.
Meanwhile, pioneer though it was, Dragon Quest is overshadowed by the more evolved RPGs that followed in its wake, both in the Final Fantasy series, and, presumably (as I have yet to play them, though I'm planning to make some time for it in the near future) in its own series. More precisely, it is my opinion that the golden age of the console RPG was the Super Nintendo years. But it's still illuminating to jump back and see where the boom began.
Monday, November 24, 2014
Friday, November 21, 2014
Adjusting Encounter Rate
On every map in an RPG Maker VX Ace project, you can specify the average number of steps between random enemy encounters (on regions designated for random encounters), in the Map Properties window (below where you assign troops to each region). This gives you some level of control over how often a player will run into random encounters, but the formula the program uses to calculate the number of steps between any two given encounters leaves much to be desired. This formula can be found in the script editor on line 195 of Game_Player, and is as follows:
The good news is, changing the program's behavior is as simple as modifying the above formula. Feel free to let your imagination run wild. A simple alternative that I'm using for the time being is as follows:
And if you don't want to change the default code (which I wouldn't recommend), just paste this code into the Materials section (with whichever updated formula you want to use) and it will overwrite the default:
Click here for another mini-script related to random encounters.
@encounter_count = rand(n) + rand(n) + 1where "@encounter_count" is the number of steps until the next encounter, and "n" corresponds to the average number of steps between encounters that you specify in the Map Properties window on any given map. This formula calculates a random number from 1 to twice the average steps (plus 1) you've given the map. That means that on a map that you've chosen the average steps between encounters to be 20, for example, you could go anywhere from just a single step to as many as 41 steps before your next encounter. Quite frankly, I think that's too much variance, and especially on the low side, only being able to get a few steps between encounters is pretty frustrating.
The good news is, changing the program's behavior is as simple as modifying the above formula. Feel free to let your imagination run wild. A simple alternative that I'm using for the time being is as follows:
@encounter_count = rand(n) + n / 2Here, the lowest possible number of steps before the next encounter will be: not 1, but half whatever the average steps between encounters is, and the maximum will be 50% more than the average. So, if you set the average to be 20 on a map, the steps calculated between encounters will always be between 10 (half the average) and 30 (three halves of the average). There's still a lot of variance there, but this formula cuts out the really short and really long travels between encounters to make it all a bit more consistent. As I said, you can fool with the formula as much as you like.
And if you don't want to change the default code (which I wouldn't recommend), just paste this code into the Materials section (with whichever updated formula you want to use) and it will overwrite the default:
class Game_Player < Game_Character
def make_encounter_count
n = $game_map.encounter_step
@encounter_count = rand(n) + n / 2
end
end
I recommend you give it a title ("encounter adjustment", perhaps?) so you know what it does at a glance in the future. This is a nondestructive way of messing around with the scripts so that if for whatever reason you want to revert to the default, you can just delete the added code in the Materials section!Click here for another mini-script related to random encounters.
Monday, November 17, 2014
Battler Woes
So one of the big problems with bringing my game to life is the limitations of the "battlers" provided by RPG Maker VX Ace. ("Battlers" are the graphical images of the enemies that appear on screen during combat). My number one complaint with the battlers is the vast proportion of humanoid enemies to the exclusion of a better selection of animal-based enemies (which are, unfortunately, the focus in my particular game).
Out of 74 total default battlers, well over half of them are humanoid in nature, many including a male and female version of a particular class (Cleric, Dark Elf, Grappler, Hero, Paladin, Thief, Warrior, Wizard - oh, and God/Goddess). This is great, I guess, for games where people fight other people, but this is RPG Maker, not Tournament Fighter Maker. Anyway, going through the battlers, here are some of my specific complaints:
* Ok, before I get into my complaints, there are some good boss battlers in the set, even a few that would make good final bosses (particularly Darklord, Demon, Evilgod), so that's a plus. I would still welcome some more variety, though.
* The elemental battlers (Earthspirit, Firespirit, Waterspirit, Windspirit) leave something to be desired for me, graphically.
* There are two wolf-like battlers, but one of them is a Werewolf and the other one is Cerberus ("Kerberos"). Unless you want the wolves in your game world to be part-man or have three heads, there's no basic "wolf" battler.
* The Spider, Snake, and Scorpion battlers are all huge! I prefer the smaller snakes and spiders and scorpions of Final Fantasy 1. They're dangerous because, in spite of their small size, they dangle the threat of poison in front of you. They're not the type of enemies who rely on strength and size...
* There are no horse-based battlers (I'm sorry, but I liked the MadPonys and NiteMares of Final Fantasy 1).
* There are no crocodile or shark battlers. There is a Jellyfish, which is good (though no giant squid for a boss), and even the "Gayzer" (remember OddEye?) from Final Fantasy is replicated (despite, to my knowledge, not representing anything that lives on this Earth). There's a "Sahagin" battler, which is a fish warrior, but other than those, there's not a whole lot of other sea or water-based battlers.
* There's only a single Dragon. It's a pretty cool dragon. But there's only the one. Sure, you can adjust its hue, but my game requires 13 dragons, and so a little variety is pretty much required. One of the coolest things, for me, about the classic Final Fantasy games (even going back to the very first one) was the great diversity of dragons you encountered. I even dedicated a web page to it once! And the 8 Legendary Dragons of Final Fantasy VI was obviously a strong influence on my desire to make an RPG with a focus on a pantheon of powerful dragon bosses. But with just the one dragon, I'm honestly at a loss as to what to do...
* There are no robot battlers. I understand that this program is designed to make fantasy games, not sci-fi games, but even just a single robot-based battler would have been nice. Robot enemies turn up in a lot of the classic Final Fantasies (WarMech anyone?), which, despite being fantasy-based, often take advantage of the opportunity to have at least one dungeon in the game be all futuristic and sci-fi-y (e.g., the Sky Castle, the Tower of Zot/Tower of Bab-il/Giant of Bab-il, the Magitek Research Facility).
* They have a number of undead battlers - including Zombies, "Ghosts", Vampires, and even Death itself. This is good, even though I'm going to have difficulty working any of them into my game. But yet not one robot battler...
* They only have one bird-type battler (not including Bats and Gargoyles), and it's a weird cross between a Cockatrice (which it is apparently trying to be) and a chicken. It's fine enough on its own, but if you want some different kinds of bird-type enemies, you're pretty much stuck. Good luck trying to pass a chicken with a lizard's tail off as a "raven" or somesuch. I tried making it a raptor once, since there is a lack of reptilian battlers (do snakes count?) and no dinosaur battlers to speak of, but that's obviously a stretch. There is a tengu warrior (Garuda), but it's pretty extravagantly decorated and has the same problem as the Werewolf if you're looking for more animalian creatures.
There are some good battlers - don't get me wrong - and it's a good hodgepodge of RPG classics. But honestly I really wish there were just more variety. I'd even be willing to pay extra for a bonus pack of battlers drawn in the same style (and comparable quality) to supplicate the ones that come with the program, but I've seen no such thing. I'd be willing to buy a complete set drawn by someone else, provided they were good quality, meshed well with the graphics already in use in the game, and covered all the basics that the default battlers already cover.
So far, I've seen nothing available in the fan community (for pay or for free) that is of a professional quality, and not narrowly shoehorned into some particular alternative play style (rather than the "generic RPG" style that the default battlers assume). Picking and choosing battlers here and there is not an attractive option for me because I really think cohesion of style is important for a game. It's the primary reason I haven't broken down and just nicked a bunch of sprites from Final Fantasy to use in my game (well, that, and the fact that Final Fantasy uses a side-view battle system and RPG Maker opts for the front-view battle system like Dragon Quest)...
Out of 74 total default battlers, well over half of them are humanoid in nature, many including a male and female version of a particular class (Cleric, Dark Elf, Grappler, Hero, Paladin, Thief, Warrior, Wizard - oh, and God/Goddess). This is great, I guess, for games where people fight other people, but this is RPG Maker, not Tournament Fighter Maker. Anyway, going through the battlers, here are some of my specific complaints:
* Ok, before I get into my complaints, there are some good boss battlers in the set, even a few that would make good final bosses (particularly Darklord, Demon, Evilgod), so that's a plus. I would still welcome some more variety, though.
* The elemental battlers (Earthspirit, Firespirit, Waterspirit, Windspirit) leave something to be desired for me, graphically.
* There are two wolf-like battlers, but one of them is a Werewolf and the other one is Cerberus ("Kerberos"). Unless you want the wolves in your game world to be part-man or have three heads, there's no basic "wolf" battler.
* The Spider, Snake, and Scorpion battlers are all huge! I prefer the smaller snakes and spiders and scorpions of Final Fantasy 1. They're dangerous because, in spite of their small size, they dangle the threat of poison in front of you. They're not the type of enemies who rely on strength and size...
* There are no horse-based battlers (I'm sorry, but I liked the MadPonys and NiteMares of Final Fantasy 1).
* There are no crocodile or shark battlers. There is a Jellyfish, which is good (though no giant squid for a boss), and even the "Gayzer" (remember OddEye?) from Final Fantasy is replicated (despite, to my knowledge, not representing anything that lives on this Earth). There's a "Sahagin" battler, which is a fish warrior, but other than those, there's not a whole lot of other sea or water-based battlers.
* There's only a single Dragon. It's a pretty cool dragon. But there's only the one. Sure, you can adjust its hue, but my game requires 13 dragons, and so a little variety is pretty much required. One of the coolest things, for me, about the classic Final Fantasy games (even going back to the very first one) was the great diversity of dragons you encountered. I even dedicated a web page to it once! And the 8 Legendary Dragons of Final Fantasy VI was obviously a strong influence on my desire to make an RPG with a focus on a pantheon of powerful dragon bosses. But with just the one dragon, I'm honestly at a loss as to what to do...
* There are no robot battlers. I understand that this program is designed to make fantasy games, not sci-fi games, but even just a single robot-based battler would have been nice. Robot enemies turn up in a lot of the classic Final Fantasies (WarMech anyone?), which, despite being fantasy-based, often take advantage of the opportunity to have at least one dungeon in the game be all futuristic and sci-fi-y (e.g., the Sky Castle, the Tower of Zot/Tower of Bab-il/Giant of Bab-il, the Magitek Research Facility).
* They have a number of undead battlers - including Zombies, "Ghosts", Vampires, and even Death itself. This is good, even though I'm going to have difficulty working any of them into my game. But yet not one robot battler...
* They only have one bird-type battler (not including Bats and Gargoyles), and it's a weird cross between a Cockatrice (which it is apparently trying to be) and a chicken. It's fine enough on its own, but if you want some different kinds of bird-type enemies, you're pretty much stuck. Good luck trying to pass a chicken with a lizard's tail off as a "raven" or somesuch. I tried making it a raptor once, since there is a lack of reptilian battlers (do snakes count?) and no dinosaur battlers to speak of, but that's obviously a stretch. There is a tengu warrior (Garuda), but it's pretty extravagantly decorated and has the same problem as the Werewolf if you're looking for more animalian creatures.
There are some good battlers - don't get me wrong - and it's a good hodgepodge of RPG classics. But honestly I really wish there were just more variety. I'd even be willing to pay extra for a bonus pack of battlers drawn in the same style (and comparable quality) to supplicate the ones that come with the program, but I've seen no such thing. I'd be willing to buy a complete set drawn by someone else, provided they were good quality, meshed well with the graphics already in use in the game, and covered all the basics that the default battlers already cover.
So far, I've seen nothing available in the fan community (for pay or for free) that is of a professional quality, and not narrowly shoehorned into some particular alternative play style (rather than the "generic RPG" style that the default battlers assume). Picking and choosing battlers here and there is not an attractive option for me because I really think cohesion of style is important for a game. It's the primary reason I haven't broken down and just nicked a bunch of sprites from Final Fantasy to use in my game (well, that, and the fact that Final Fantasy uses a side-view battle system and RPG Maker opts for the front-view battle system like Dragon Quest)...
Saturday, November 15, 2014
Convention and Originality
One of the difficulties I've been having with working on my RPG, Dragonfaith, is that when I originally began visualizing it in my head, a lot of its features were designed as a response to many of the cliches and conventions of the RPG genre. The basic plot, for example - nature rising up against man - serves the purpose of giving the player a reason and an excuse to go out into the wild slaughtering beasts left and right. And the entirety of the Hunters Guild wasn't even part of the original story, but an invention designed to provide the possibility for alternatives to the usual random enemy encounter system which is so critical to the genre, and yet frequently frustrating to players.
The reason this is a problem is that, now that I've sat down and begun building an RPG for real, while I may be a veteran RPG player, I am a total n00b when it comes to actually putting together a game like this. My ideas are, in a sense, far more advanced than my technical abilities. And I feel like - in the vein of learning to walk before you can run - I should focus on learning how to actually make a conventional RPG first, before I decide to try circumventing all the usual rules; especially since I'm building my game with a program that's essentially designed to replicate all the conventions of typical RPGs, where learning how to code around the expectations of its users is an additional skill above and beyond learning the program to create RPGs in the first place.
So it's a constant struggle to decide between trying to be fancy and bring my vision to life the way it was intended, and scaling back my ambitions and just trying to put together a game that works, while telling the story I want to tell (which doesn't rely on doing it in a totally original way). And it's a problem when you can't decide what you actually want to create, because, as I've discovered before, having a clear goal in mind makes the creative process flow much more smoothly (which means better focus and more progress). Indecisiveness, on the other hand, halts progress and inspires the mind to distract itself and wander elsewhere.
In any case, I've been working on the game a lot these past few weeks, since my schedule opened up following October's month-long movie marathon. I'm not giving you a date on any future releases, because it'll be ready when it's ready. But I've been polishing up everything that I've worked on so far, paring some of the complexity back, with an eye toward the great, largely blank space that constitutes the rest of the game I haven't clearly visualized yet. And I've been playing a particularly classic RPG for inspiration as well (with others in the queue), which I should have a few words to say about here on this blog in the very near future.
The reason this is a problem is that, now that I've sat down and begun building an RPG for real, while I may be a veteran RPG player, I am a total n00b when it comes to actually putting together a game like this. My ideas are, in a sense, far more advanced than my technical abilities. And I feel like - in the vein of learning to walk before you can run - I should focus on learning how to actually make a conventional RPG first, before I decide to try circumventing all the usual rules; especially since I'm building my game with a program that's essentially designed to replicate all the conventions of typical RPGs, where learning how to code around the expectations of its users is an additional skill above and beyond learning the program to create RPGs in the first place.
So it's a constant struggle to decide between trying to be fancy and bring my vision to life the way it was intended, and scaling back my ambitions and just trying to put together a game that works, while telling the story I want to tell (which doesn't rely on doing it in a totally original way). And it's a problem when you can't decide what you actually want to create, because, as I've discovered before, having a clear goal in mind makes the creative process flow much more smoothly (which means better focus and more progress). Indecisiveness, on the other hand, halts progress and inspires the mind to distract itself and wander elsewhere.
In any case, I've been working on the game a lot these past few weeks, since my schedule opened up following October's month-long movie marathon. I'm not giving you a date on any future releases, because it'll be ready when it's ready. But I've been polishing up everything that I've worked on so far, paring some of the complexity back, with an eye toward the great, largely blank space that constitutes the rest of the game I haven't clearly visualized yet. And I've been playing a particularly classic RPG for inspiration as well (with others in the queue), which I should have a few words to say about here on this blog in the very near future.
Friday, November 7, 2014
Building a Canoe
Vehicles in RPG Maker VX Ace (without scripts) behave in a certain way. This post is concerned primarily with the "boat", which is not to be confused with the "ship". The ship is the typical RPG ship vehicle, which moves at double speed over ocean tiles (shallow or deep). Unlike in Final Fantasy (the first one), though, ships can dock anywhere on land - not just at ports - and it can also sail up rivers, basically making the boat obsolete once you get the ship.
The boat, on the other hand, instead of just paddling up rivers, can also traverse shallow ocean tiles. This can be an advantage or a disadvantage depending on what your game requires. But also depending on your RPG experience, it can be a little counter-intuitive (I'm finding that RPG Maker VX Ace is a bit of an amalgam of different RPG conventions from various sources, which is good in that it's not just a duplicate of one particular game, but can be frustrating if you're trying to model your own game after certain conventions you're used to from a particular title).
Anyway, I was wondering if I could build a canoe that works like the one in Final Fantasy, which doesn't act like a vehicle in that it sits on the map in one place and you board it, move around, and then disembark. The Final Fantasy canoe is more like an item you carry in your inventory: once you have it, previously impassable rivers are now passable. You don't need to find your canoe and board it first - you already have it with you. You just step onto the river, and your player graphic changes to the canoe, and once you step off, it changes back to your character.
Well, the RMVXAce "boat" doesn't work that way - it's a full-on vehicle, like the ship. But, as an exercise to demonstrate how to manipulate certain aspects of the game (in this case, without using scripts), let me describe a workaround I've come up with. To start with, the default settings ensure that the player can not simply walk over river tiles. This is easy enough to change, by navigating to the tileset tab of the Database, and changing the passage setting of the river tile on the "Field" tileset (second row, first column) from an X to an O.
Presumably, though, there'll be a point in your game before your character acquires the canoe. So, what you can do is copy the Field tileset and paste it onto another line (you may have to increase the maximum). On one of them, the river tile should be set to impassable, and on the other one (you should name it differently so you can tell the difference), it should be set to passable. Then, all you need to do is use the "Change Tileset" Event Command once your player acquires the canoe, on any maps with rivers, to change it from the default Field tileset to the new one with the rivers set to passable!
But, there's something you still need to account for. When you change a map's tileset via the Change Tileset Event Command, it resets whenever you leave that map. Furthermore, I don't think you can change the tileset of any other map than the one you're on when the Event triggers - which wouldn't work if you acquire the canoe in a town, and the rivers are all on the world map.
Well, here's what you can do: on any maps that have rivers, create an autorun event. It should trigger only once the player has acquired the canoe (you can check this with a switch, or else by whether the player has the canoe item, if you want to treat it that way). It should change the tileset of the map as discussed above and then erase itself (Erase Event). That way it will fix the map every time you enter it after acquiring the canoe, so that you will be able to walk over the rivers.
Now, then, you're going to need another event on the same map - a Parallel Process that runs only when the player has the canoe. This event is going to check the player's map position (by storing them in variables), and then determine the terrain tag (by storing it in another variable) of the tile the player is currently standing on (with the "Get Location" command). Of course, you'll have to go back into the Database and give the river tile (on the passable version of the Field tileset) a terrain tag (and make sure it doesn't conflict with any other terrain tags you might be using on the same map).
In the Parallel Process event, you'll want to run a conditional branch that checks whether the terrain tag of the tile the player is standing on (which you stored in a variable) matches the one you gave the river tile in the Database. If it does, use a Set Move Route command and change the player's graphic to the boat graphic, and then turn a self-switch on. Now you're in river mode.
Create a new page in the same event (also triggered by parallel process), with the conditional being the self-switch you just turned on. Now, you're going to do the same thing as before (get the player's position, store the terrain tag in a variable, then check that variable), but this time you want the conditional to run only when the terrain tag is NOT equal to the one you gave the river tile in the Database. When that happens, simply change the player's graphic back to what it was using another Set Move Route command, and then turn off the self-switch. You're back in land mode!
You can do all sorts of things now, like disable the save function when the player is on a river tile, by adding the appropriate commands to the event in the same place where you changed the player's graphic. You also may need to run a conditional branch when changing the player's graphic back, to determine which party member is at the head of the party. In fact, you'll probably want to disable Formation Access while the player is in the canoe as well, so the player doesn't switch out the canoe graphic for a different character. And, graphically, this canoe feature doesn't work well if you're using "Player Followers" (which I don't like anyway).
Those are the basics. It seems to work pretty well for me so far - I've even managed to get a waterfall cave (map transfer from river tile to dungeon, and back again) working. You can even dock the ship at a river mouth, too! Just like in the first Final Fantasy. I rigged up a nice little tutorial (like I've seen users do on the RPG Maker forums) that demonstrates how my FF canoe works - you can download it here and play it like any other RPG Maker game. Also, it's unencrypted, so you can open the project file up in RPG Maker and see just how all the events work. It's a lot like my Prefab Smithy, but taken just one more step further!
The boat, on the other hand, instead of just paddling up rivers, can also traverse shallow ocean tiles. This can be an advantage or a disadvantage depending on what your game requires. But also depending on your RPG experience, it can be a little counter-intuitive (I'm finding that RPG Maker VX Ace is a bit of an amalgam of different RPG conventions from various sources, which is good in that it's not just a duplicate of one particular game, but can be frustrating if you're trying to model your own game after certain conventions you're used to from a particular title).
Anyway, I was wondering if I could build a canoe that works like the one in Final Fantasy, which doesn't act like a vehicle in that it sits on the map in one place and you board it, move around, and then disembark. The Final Fantasy canoe is more like an item you carry in your inventory: once you have it, previously impassable rivers are now passable. You don't need to find your canoe and board it first - you already have it with you. You just step onto the river, and your player graphic changes to the canoe, and once you step off, it changes back to your character.
Well, the RMVXAce "boat" doesn't work that way - it's a full-on vehicle, like the ship. But, as an exercise to demonstrate how to manipulate certain aspects of the game (in this case, without using scripts), let me describe a workaround I've come up with. To start with, the default settings ensure that the player can not simply walk over river tiles. This is easy enough to change, by navigating to the tileset tab of the Database, and changing the passage setting of the river tile on the "Field" tileset (second row, first column) from an X to an O.
Presumably, though, there'll be a point in your game before your character acquires the canoe. So, what you can do is copy the Field tileset and paste it onto another line (you may have to increase the maximum). On one of them, the river tile should be set to impassable, and on the other one (you should name it differently so you can tell the difference), it should be set to passable. Then, all you need to do is use the "Change Tileset" Event Command once your player acquires the canoe, on any maps with rivers, to change it from the default Field tileset to the new one with the rivers set to passable!
But, there's something you still need to account for. When you change a map's tileset via the Change Tileset Event Command, it resets whenever you leave that map. Furthermore, I don't think you can change the tileset of any other map than the one you're on when the Event triggers - which wouldn't work if you acquire the canoe in a town, and the rivers are all on the world map.
Well, here's what you can do: on any maps that have rivers, create an autorun event. It should trigger only once the player has acquired the canoe (you can check this with a switch, or else by whether the player has the canoe item, if you want to treat it that way). It should change the tileset of the map as discussed above and then erase itself (Erase Event). That way it will fix the map every time you enter it after acquiring the canoe, so that you will be able to walk over the rivers.
Now, then, you're going to need another event on the same map - a Parallel Process that runs only when the player has the canoe. This event is going to check the player's map position (by storing them in variables), and then determine the terrain tag (by storing it in another variable) of the tile the player is currently standing on (with the "Get Location" command). Of course, you'll have to go back into the Database and give the river tile (on the passable version of the Field tileset) a terrain tag (and make sure it doesn't conflict with any other terrain tags you might be using on the same map).
In the Parallel Process event, you'll want to run a conditional branch that checks whether the terrain tag of the tile the player is standing on (which you stored in a variable) matches the one you gave the river tile in the Database. If it does, use a Set Move Route command and change the player's graphic to the boat graphic, and then turn a self-switch on. Now you're in river mode.
Create a new page in the same event (also triggered by parallel process), with the conditional being the self-switch you just turned on. Now, you're going to do the same thing as before (get the player's position, store the terrain tag in a variable, then check that variable), but this time you want the conditional to run only when the terrain tag is NOT equal to the one you gave the river tile in the Database. When that happens, simply change the player's graphic back to what it was using another Set Move Route command, and then turn off the self-switch. You're back in land mode!
You can do all sorts of things now, like disable the save function when the player is on a river tile, by adding the appropriate commands to the event in the same place where you changed the player's graphic. You also may need to run a conditional branch when changing the player's graphic back, to determine which party member is at the head of the party. In fact, you'll probably want to disable Formation Access while the player is in the canoe as well, so the player doesn't switch out the canoe graphic for a different character. And, graphically, this canoe feature doesn't work well if you're using "Player Followers" (which I don't like anyway).
Those are the basics. It seems to work pretty well for me so far - I've even managed to get a waterfall cave (map transfer from river tile to dungeon, and back again) working. You can even dock the ship at a river mouth, too! Just like in the first Final Fantasy. I rigged up a nice little tutorial (like I've seen users do on the RPG Maker forums) that demonstrates how my FF canoe works - you can download it here and play it like any other RPG Maker game. Also, it's unencrypted, so you can open the project file up in RPG Maker and see just how all the events work. It's a lot like my Prefab Smithy, but taken just one more step further!
Subscribe to:
Posts (Atom)