Problem and Solution (An Example)

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.

Alpha 4.0 Release

Ah, the long-awaited release! How's that for a Good Friday? :p

I'm gonna try not to say too much about this one, because I'm actually kinda sick of thinking about it. But this release includes what I've taken to calling the "Sea Shrine chapter" that I've been working at relentlessly for like the past month.

I've also included the Forest Realm chapter, since it was ready for the last release, and I haven't really done much to it. There are a few minor changes or additions, but it's mostly the same as you've seen it before, so you can either skip it or try it out if you haven't yet.

I left off the beginning section of the game, only because I've made enough changes to it to break the game flow, but not enough to get it running smoothly again. Hopefully it'll be ready for the next release, with some changes since the last time you've played it. But for that reason, I'll leave the last release up for the time being, in case you want to try that part of the game [again, or if you haven't done so yet].

As for the Sea Shrine chapter, since it's disconnected from the rest of the game that I've developed so far, I don't really have a solid idea of what level your characters are going to be at, so this is going to be a purely non-combat rehearsal. I figured that doing all that work balancing the stats when I know I'm just going to change them in the future would be unproductive.

So the focus here is going to be more on exploring the maps I've designed, and experiencing the drama as it unfolds. For that reason, the main feedback I'm looking for - in addition, obviously, to bug reports - is whether you like the maps/story elements, if you think they're fun/exciting, believable, or if you have any suggestions for improvement. I think I can live with a certain level of suspension of disbelief for the sake of narrative flow for this part of the game, since it took so much effort weaving all the pieces together. Bottom line, tell me if you enjoyed it or not!

Also, there's two new characters in this section of the game that you haven't seen before. One is introduced in this chapter, the other one is already in your party. I hate to throw her into the game without having given her a proper introduction first, but that's how it's going to be. So I apologize if you're like, "who is this character?" Rest assured that there will be answers later on (in an earlier part, chronologically, of the game).

Also, I haven't included a game over screen or note this time, since it should be pretty obvious when the chapter is done. You can do a little exploring at the end (but not much, so don't get your hopes up), but there is one location that's not involved in the plot that you can check out after you complete the chapter that's just for fun.

Oh, and Harry Potter fans will be pleased to note that I've completed the Deathly Hallows this time around (in the form of Developer's Tools). The Cloak of Invisibility, however, is purely superficial, and because I don't have its use implemented in any way in the rest of the game, you'll only have it in the Developer's Studio before you start the game. So get your fill of it before you start the game proper. Also, I've replaced the Bottomless Coffee with a pair of Winged Sandals. It may not be obvious, so I'm telling you now that they must be equipped as an accessory (and not used as an item) - same with the Invis Cloak.

Alright, enough talk. Give it a try!

4/19/14 Dragonfaith Alpha 4.2 (34.9 MB)

Edit: orz. I left a canoe in a place it wasn't supposed to be, theoretically giving you access to Grassland, where you shouldn't be. It has been removed in version 4.1.

V4.2: Based on early feedback, I changed some dialogue to improve narrative flow. Hopefully I didn't break anything, as I'm getting pret.ty tired.

Eventing and Choreography

In RPG Maker VX Ace, most of the real meat in developing your game (beyond the conceptual stage) occurs between three areas of the program. The two more common areas are the Map and the Database. The third is the Script Editor, which is available for more advanced developers, who wish to delve into the code and change how the program actually functions. The Database is responsible for defining the details of much of the common and non-map-based elements of your game, such as playable characters (including their attributes and growth patterns), items (including weapons and armor), skills (including damage formulas and animations), enemies (and the formation of 'troops' they attack in), and things of that sort.

The Map is, I think, where you'll probably spend most of your time (unless you're an avid scripter), at least in the earlier stages of development, although the Database is also very important. But the Map is where you actually get to build your world. There are different 'layers' to the map, the first being the obvious one where you get to lay down tiles and dictate how any given map is going to look. But equally important - if not more so - is the eventing layer. Events are super important in RMVXAce. They can accomplish all sorts of tasks. The single most important article I read in my beginning days with the program was this one, which I linked before, that really clarifies the power and function of events in a way that the RPG Maker's official tutorials critically leave out.

So what are events? They can be lots of things. But basically they are the interactive bits of the map, and the engines that guide actions that occur on maps. Probably one of the first things you learn to do with events is create an NPC. You see, an NPC is not a character you place on the map, so much as it is an event that you place on the map, that can be interacted with by the player (if you so choose to program it), that you can assign a graphic to, and a "move route", and some dialogue if you like. But events don't have to be people. An event can be a flickering fire - utilizing sprite animations instead of the limited (and a bit more complicated to customize) tile animations on the map layer. An event can be a door that transfers the player to another map. And every event's effects can be controlled by conditions (usually user-defined switches and variables).

But, perhaps most importantly, an event has the power to control the flow of a scene in the game. One event can control other events - NPCs or otherwise - move the screen around, even control the player. Eventing is how you accomplish "cutscenes" in an RPG, and understanding how they work is crucial to learning how to develop good cutscenes in your game. My prologue, for example, is one long event that controls all the action over two or more maps, almost like a puppetmaster pulling the strings on several other events dressed up as NPCs, and controlling where the "camera" (i.e., the screen) is focused. I'm not going to get into how to - technically - accomplish various tasks via events, as that is a task for a more hands-on tutorial; I just want to impart to you the importance of events and the basic theory behind them.

The latest part of my game that I've been working on involves a lot more "cutscenes" than previous portions. Take the forest chapter, for example. There are only really three scenes with any significant "weight" - the one that introduces your next quest, the one that occurs during the climax of that quest, and the one handling the aftereffects of the quest -  none of which (with the possible exception of the second) are all that long or involved. All the rest of the action and adventure is player-oriented; it's a pretty straightforward quest. Not all of them will be that straightforward, though. For example, the Sea Shrine chapter I'm working on now is very involved (as you will soon be able to find out for yourself), including multiple cutscenes over multiple maps, and a lot more (necessary, I fear) controls on the player's actions in this one section of the game.

Designing a map is hard. It takes a lot of creativity, and a good visual sense. Designing a cutscene is more like being a film director than a set designer. Of course, you have to have a good storyboard to start from, before you start moving your characters around on the screen. And dialogue is often an important part of a scene. And when you get multiple characters moving simultaneously? The choreography can become mind-boggling - like in the one scene in my prologue, where twelve different cloaked cultmembers file into a single tile-sized doorway (and not while moving in a single-file line). I had to work out their movements like pieces on a chess board to get it running smoothly. And then when you start manipulating switch conditions, changing other events' graphics, and moving from one map to another...

Considering that the narrative flow of a cutscene can be improved greatly by something as subtle as a 1/3 second pause between a character's movement and their subsequent dialogue, having to sit through the majority of a cutscene multiple times, while making little tweaks here and there each time, is hard enough. When the scene begins to drag on, or sprawls across multiple maps, or manipulates too many outside agents, the workload quickly becomes overbearing. I'm not exactly trying to elicit sympathy, so much as a respectful understanding of the effort that goes into developing an RPG - especially when you're just one person, all by yourself, and not a member of a team (although I can imagine that applying multiple brains to a single project introduces creative difficulties of its own).

In any case, I will hopefully be able to release this section of the game (in a not entirely finished state, it should go without saying), fairly soon, and then you can just see for yourself what I've accomplished, and perhaps provide some tips for how I can continue to polish it and perfect it in the future!

Progress Report

If you've been waiting patiently for an update, I apologize for the down time. I'd like to give you more frequent updates, but sometimes progress just goes really slow. Plus, I went to a convention last weekend, and that stalled development for a good several days. Otherwise, though, I've been making a mammoth effort in ironing out the wrinkles in this one section of the game, that involves the harbor town and sea shrine.

One thing I can tell you, is that development often involves days of staring at a partially completed map, making little tweaks here and there, until the inspiration hits (often involving finding a "hook"), followed immediately by untracked hours of focused absorption into a feverish mapping process. That's what happened with the Valley Pass "dungeon", the forest town (a.k.a., Splintwood), and to an even greater extent with this sea shrine dungeon, at least in terms of providing the meat of the dungeon.

But I've got that all pretty much squared away, and I'm very excited to show it to you. But before I can do that, I have to get the plot straightened out and the cutscenes put together, and that's proving to be a very frustrating process. I have a few set ideas of things I definitely want to happen, and in the process of stringing them together and working them into my game, I'm finding it a lot more difficult than I anticipated to fit all the pieces together, so that it all feels very natural, and not too convoluted, and doesn't stretch the player's suspension of disbelief too far.

For example, take the ship map I discussed in my last post. At first, I wasn't sure I was going to be able to make one, so I didn't want the plot to rely on an on-ship scene. But then I made the map, and worked it into the plot. But what if the story flows better without that scene? Then it kind of sucks not to be able to use this map that I put so much effort into, and that I think is pretty cool and would really like to showcase. And there are other little things here and there, elements that I think are a lot of fun, but just because you think catgirls wielding machine guns is cool, doesn't mean it fits into your game just where you'd like it to go. (Rest assured, that was just an off-the-wall example; I have no intention of putting machine gun-wielding catgirls in my game).

So basically what I'm saying is that the development continues to drag on, and I'm pretty confident that all the kinks will work themselves out given enough time and consideration, but - well, it's just that: it's going to take some time. I'll be happy when I'm ready to move on to another portion of the game, though; it seems like I've been working on this one forever now. I've laid down the preliminaries for what I hope will be a very cool (if cliched - but hey, like a greatest hits tour, you gotta hit all the bases) pyramid-themed dungeon. If I ever get out of this harbor, that is.