Just to give you some more insight into the development process (and how frustrating it can be), I'm going to outline a specific problem, its solution, and the further problems that that solution inevitably presents.
I received a specific request to implement a certain feature in my game: namely, some way to increase the player's default movement speed. Although I'm not entirely comfortable with making the next speed up the default for the average player, having an option for faster movement is a good idea. After all, when I test, I do spend an awful lot of time with my finger on the dash button.
So, in order to implement this feature, the first question you have to ask is, how does the program determine the player's speed, and how can you change it? It's actually a very simple matter to change the player's speed, and I do it frequently (also for NPCs and stand-ins) during 'cutscenes' through a simple event command (under the Set Move Route feature). But there is no 'default' speed setting that you can change under settings, so each time I change the player's speed, and then want to change it back, I have to know which speed I (or rather, the player) wants it changed back to.
The obvious fix, in my mind, was to have some kind of special item the player can use (or even equip), that I can check for, to tell me (as the developer) what speed the player wants to be moving at. Ideally, I wanted it to be something you can equip, so I can check for it continuously throughout the progress of the game, but initially I couldn't implement that because the program in its default state has no way of accessing the kind of commands necessary (specifically, calling an event) to make the needed changes (i.e., to the player's speed) from the activation of a piece of equipment.
I could, on the other hand, do exactly that with the usage of an item (which allows for the calling of a "common event" - an event that isn't limited to a single map in the game). So instead of the Winged Sandals I had had in mind (based off of the Sprint Shoes from Final Fantasy VI), I went with a Bottomless Coffee, which was a non-consumable item (meaning that it doesn't disappear after you use it), that increases the player's speed upon use.
Now, this wasn't ideal. Every time, during the course of the game, I change the player's speed (like during a cutscene), when I want to change it back, I have no way of telling whether the player has used a Bottomless Coffee recently. Wait a second, that's not entirely true. I could tick off a switch or something. But then, I'd have to give the player an option to turn off the increased speed, in case they change their mind at some point in the game. That would involve either a second item (e.g., some kind of tranquilizer) or changing the first item to something that, conceptually, it makes sense to "toggle". What I mean is, it wouldn't make sense to drink one coffee to make yourself faster, and then drink a second coffee to make yourself go slow.
Honestly, something like this just works better as a piece of equipment. A healing potion, for example, works well as an item because when you use it, it has an immediate effect, and then its done. Something that has an extended effect, that you might want the player to have the option of turning on or off, works a lot better as an equippable item - like a piece of armor. And the Accessories slot, which I haven't used in my game yet, was the perfect choice. But, as mentioned above, equippable items can't access event commands the way items can (one of the frustrating inconsistencies of the program). Unless, that is, you write a script to change the way the program functions.
And, not surprising, somebody has already done that. So I actually found a script that enables me to call common events from the equipping (or dequipping) of a piece of equipment, and that solved that problem. Gone was the Bottomless Coffee, and in its place rose the Winged Sandals I had wanted in the first place. End of story, right? Ha. Not quite.
Turns out - and this was something I hadn't even thought of, and only experienced purely by accident through testing - that eventing isn't the only thing in the program that changes the player's speed. Any veteran RPGer will probably not be surprised to hear that when you travel in the "ship" vehicle, you move at an accelerated rate (probably because oceans tend to be vast and largely featureless). And when you get off, the player's speed is "returned" to the normal rate. And this is something that happens automatically, behind the scenes, and not inside of an event that I can control.
There are two solutions, that I can foresee, to this problem. One is to use a "parallel process" event (i.e., one that runs continuously in the background) to "correct" the player's speed based on whether or not they're wearing the Winged Sandals. But it's kind of a clunky workaround (disorder bugs me), and the general approach is to try to avoid running too many parallel process events at the same time, because they can allegedly slow down the game. And I've already got a huge one on the World Map that sets the appropriate terrain-based battle backgrounds.
The other potential solution is to utilize a script that would actually enable me to control the behind-the-scenes process that goes on when the player disembarks the ship vehicle, so as to make some kind of check for whether or not the player's speed should be reduced. The cost of this approach is, of course, the knowledge of how to actually script such a thing - which involves coding, and is not as simple as plugging in an intuitively named event command.
And the frustrating thing is that this isn't the only situation (far from it) where scripting knowledge would help me out of a pickle. This whole alternate outfit idea I had, for example, I realized the other day that implementing it would in actuality involve more difficulty than I had anticipated. I already set up a common event (actually a string of them) with a switch for each character to determine which of eight potential outfits they should be wearing, so that whenever I have need of changing a character's outfit (like, during a cutscene), I could determine which outfit to change it back to when I'm done.
But, that doesn't solve the problem of knowing what any given character is supposed to look like when I create placeholders for them during my cutscenes. So, for example, if Rachel is in her alternate schoolgirl uniform, she might inexplicably show up in her armor during a cutscene, because I as the developer didn't know any better when I evented that cutscene. Now, I could use conditional branches to check the switches associated with each character's outfit, but now you're talking about potentially hundreds of extra conditional branches littered throughout my game, every time a cutscene happens - and that's just too much.
Plus, there's the secondary issue of face graphics - for use with text boxes. Although I could use a single face graphic for each character, I kind of like having ones with different necks, depending on what outfit the character's wearing. This would require even more conditional branches (and not just one per character per cutscene, but one for each set of consecutive dialogue boxes, whether in cutscenes or out). But you know what? This impossible task of knowing exactly which graphic to select by accessing a variable, which simply isn't available inside text boxes - can be made available via the power of scripting.
In fact, I've already found a script that does it. The problem is (as with many robust scripts), it does a million other things, too, some of which may change the program's functioning in ways I can't anticipate or don't understand, and could create compatibility problems later on down the line, and I just don't want or need all of that. And though I've tried isolating the function I want from everything else, that's not always a straightforward task, when you don't understand what all the code is doing, and how it all fits together.
Which is the crux of the issue. Don't get me wrong, I'm not against learning Ruby for the sake of this development project. But so far, the lessons I've encountered pretty much run along the lines of, "here's some syntax, and here's how you do things in Ruby that might be important for like web development or something but probably have little to do with most of what you'll need within the context of RPG Maker". And it's not just that. I'm not a newbie when it comes to learning computer languages. I'm actually pretty good at it, and I've studied it through high school, and a little bit in college. I can more or less understand the theory behind it, and I like to think I could pick up a new language fairly quickly, if it's not completely different from things I've learned before.
But the one thing that totally puzzles me is not a matter of, "how do you do this particular task in Ruby", i.e., "what's the syntax?", but how is RPG Maker VX Ace specifically set up, organizationally speaking, and how does the code you can find in the Script Editor actually relate to the various tasks that are performed in the game. For example, I had a hell of a time finding out how to access the value for the number of steps until next encounter, even though I knew what it was, that it was there, and even (eventually) where to find it. And I look at the scripts that users have made, trying to make sense of them, and I just don't see exactly how the program is accessing the code and integrating it into the overall functioning of the program. Some kind of outline or flowchart specific to RPG Maker VX Ace would be awful nice, but I've yet to come across anything like that.
In the meantime, I guess the best I can do is just continue to familiarize myself with the basic functions of Ruby.
No comments:
Post a Comment