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.