Let’s revisit for a moment a topic that we discussed in our first tutorial, adjusting encounters so that they also happen while riding in the boat (or ship, or airship, for that matter). We saw how it was fairly easy to get this change in place, by only adjusting a few lines of code. But, we might notice there’s a slight problem… unless we craft dozens of different areas to perfectly match the contours of our water and land, we will end up with land dwellers attacking us while on the high seas, and sharks attacking us on land. Needless to say, this is kind of inadequate. Unfortunately, out of the box, there is no way to specify that troops only appear on certain types of tiles. So, we need to write a bit of script in order to make this work.

Before diving into how to do this, it’s worth digressing for just a brief moment to point out that a new feature in VX Ace, known as Regions, averts this issue. Though still impossible to define encounters based on tiles, rectangular areas have been replaced by regions, which can have any arbitrary shape by essentially painting them onto the map. So, the obvious solution would be to simply draw out separate land and water regions as needed, and assign appropriate troops to each. But until the English release, let’s continue looking at VX… Continue reading →

We looked at how to make a simple change by working through the code base, and determining where the change needs to be made.  However, going into the default code and making changes to it has a few drawbacks… it’s sloppy, not easily transportable, and a bit error prone.  So, how do we do better?

The Ruby language supports a few interesting things that are relatively unique among programming languages: redefinition, and aliasing.  This is one topic where it’s worth a bit of discussion about the language specifically, since these features are so important and relevant to our specific use case in writing scripts. Continue reading →

Let’s start our little journey into scripting by getting a few orders of business out of the way quickly.  First, I don’t intend to spend too much time talking about the details and syntax of the Ruby language, or about programming theory, and concepts in object-oriented programming.  These things  are all part of scripting for RGSS, of course.  However, they are very deep topics that would take dozens of tutorials to cover adequately, and are already well documented elsewhere, so there’s no sense in duplicating the effort here.

Second, before delving into scripting, be sure to have a strong knowledge of using the maker on it’s own, in particular, the details of the database, and a strong understanding of writing events.  Although not identical, complicated events that utilize conditional branching, switches, and variable handling, have a lot in common with writing scripts.  A good event writer will likely have an easy time starting to learn scripting.

Lastly, realize that when one first starts modifying scripts, it’s unlikely they are going to write a new custom battle system within their first few days.  On the contrary, the longest and most complicated scripts come from those who have substantial experience in the various versions of RGSS, or a programming background in other areas.  With all of that said and out of the way, we can’t learn to swim without getting into the water, so let’s start taking a look at the existing scripts, and then we’ll learn how to implement a simple change to how the default engine works, as an example. Continue reading →