Honestly, I should have had my next release up by now, but the regularity of my working habit has been interrupted by recent changes in my life, as well as the changing seasons. But also, I'm having a little difficulty with a portion of the game I'm currently working on. And one of the problems I've come across is the issue of free will vs. determinism, in terms of player control.
Allow me to clarify. There is a portion in the game, for example, where the entering of a town starts off a series of plot-related events. Now, these events are not stringed one right after another - I actually want the player to have some freedom to explore the town and encounter these events at his own pace. However, they all (or mostly all) must be triggered before a final event can occur, finishing the string of events in that town, and enabling the player to move on to the next portion of the game. That one of these events involves spending the night at an inn (or in this case, the equivalent of an inn), but there's a certain point in the chronology of the stringed events where the inn event can and cannot occur, makes it that much more difficult for me to script out all these events, given that the player may encounter them in a number of different orders, and because I have to add in some kind of artificial obstacles to prevent the player from triggering certain events before they're ready to be triggered.
Actually, this is a lot like the situation I had in the Harbor Town you might remember from my last game release. There was the introduction of a new character in the pub, a kidnapping at the Elders Council, and a meeting in the Guild Hall, the latter of which triggered a night at the inn, which opened up the further continuation of the game. It was tricky getting it all worked out, but I managed. And I think the current situation I'm dealing with is slightly more thorny, as more of the events are mandatory, and have more of an impact on the other events that may be triggered.
Which brings up a number of questions about how I want to design my game. I don't want to force the player to do things in a certain order, to the point that it feels artificial. At the same time, there are some definite limitations I have to place, because the plot elements simply wouldn't make sense otherwise. I suppose it's ultimately a matter of fitting the puzzle pieces together, but I'll admit, as smart as I am, I have a hard time juggling a bunch of different parallel alternatives in my head at the same time. The complexity, especially keeping track of all the different switches, can get to be very intimidating.
To turn my mind to other issues for the time being, let's talk about characters. One thing that appeals to me about the first Final Fantasy is its relative simplicity, compared to how much more complex RPGs got as the genre evolved over time. Especially as a first time developer, I feel like I ought to be taking more cues from the simplistic nature of that first Final Fantasy, so as not to bog myself down, considering how little experience I have (and how many different people they probably had working together on those professional games).
At the same time, sitting down and beginning to work on my RPG, I simply couldn't resist the temptation to imitate the better plot and deeper characters of the later Final Fantasy games. Think about some of your favorite moments from the SNES-era Final Fantasies. How many of those moments were great plot-based scenes? How many of those characters were memorable? Remember Cecil's transformation from Dark Knight to Paladin? Kain's repeated betrayals? When Golbez appeared and kidnapped Rosa? Tellah's failed attempt at revenge? Rydia's timely reappearance just as you're about to be annihilated? And that's all from FFIV. FFVI had a cast of something like 20 characters, all with their different personalities, back stories, and unique abilities.
In contrast, the characters you chose at the beginning of the first Final Fantasy had zero effect on the actual plot of the game. The only difference was in the gameplay, as the characters had different fighting abilities. My original idea for my own RPG worked in a similar fashion. Apart from the main character, the plot-crucial elf character, and maybe some vague ideas here or there (including the assassin character you met at the Sea Shrine in my last release), I didn't have much in mind as far as personalities and character-based plot elements go. My original idea was for you to build a party from generic archetype hunters - kind of like mercenaries - that you could swap at any Guild Hall. The main difference between the hunters would be their fighting styles - mostly what kind of weapon they used.
But, as I said, when I started working on my RPG, the temptation to create deeper characters that have more of an emotional impact on the player was strong. I'm just a little concerned about the added difficulty in writing story it's going to cause me. But I guess having more user choices for party formations that involve different types of fighters could have created more difficulty in balancing the combat, anyway. And that's probably a more frustrating (and less creative) aspect of development, so maybe it's for the best. I'll tell you one thing, it's gotta be impossible to wrap your mind around just how complicated creating a game of this type is until you actually sit down and start working on it...
Sunday, May 18, 2014
Sunday, May 4, 2014
Coming Attractions
As you could probably have guessed, the rate of progress in the development of my game has dropped considerably since that first month or so, when the novelty of the experience had me so excited that I spent pretty much every waking moment working on my game. And you're probably not going to want to hear this, but with Spring in bloom, I'm probably going to want to be spending even less time sitting in front of the computer, and more time outside in the sunshine. But rest assured, I'm committed to seeing this game project to completion, and I am very much aware that the longer I draw the experience out (in terms of being lazy and procrastinating, and not simply spending the time required actually working on the game), the less likely it is to ever reach that point.
So I wanted to let you in on some of what you'll be able to look forward to in my next release, which I am steadily working my way toward. If you've played my last release, you'll no doubt be aware of its somewhat splintered nature, and the fact that a previously playable portion of the game (the Grassland area) was off limits. Well, in my next release, I plan to have that portion of the game running again (with some modifications since the last time you played it), including some new stuff for when you later revisit the town (which I am currently still working on).
There will also be another all new town for you to visit, and - what I'm most excited to show off this time around - a white water rafting challenge. The gameplay for this portion of the game is a little bit different than what you're used to, but that's not entirely unheard of in the sort of classic RPGs I've been inspired by (for example, the river and underwater portions in Final Fantasy VI), so hopefully it's not too jarring. I don't plan to make a habit of switching up the gameplay, although it was fun doing something a little bit different for once, and I think it'll fit into the flow of the game nicely enough.
So, look forward to that! I've still got some work to do before I can put out that release, though. Stay tuned!
So I wanted to let you in on some of what you'll be able to look forward to in my next release, which I am steadily working my way toward. If you've played my last release, you'll no doubt be aware of its somewhat splintered nature, and the fact that a previously playable portion of the game (the Grassland area) was off limits. Well, in my next release, I plan to have that portion of the game running again (with some modifications since the last time you played it), including some new stuff for when you later revisit the town (which I am currently still working on).
There will also be another all new town for you to visit, and - what I'm most excited to show off this time around - a white water rafting challenge. The gameplay for this portion of the game is a little bit different than what you're used to, but that's not entirely unheard of in the sort of classic RPGs I've been inspired by (for example, the river and underwater portions in Final Fantasy VI), so hopefully it's not too jarring. I don't plan to make a habit of switching up the gameplay, although it was fun doing something a little bit different for once, and I think it'll fit into the flow of the game nicely enough.
So, look forward to that! I've still got some work to do before I can put out that release, though. Stay tuned!
Sunday, April 20, 2014
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.
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.
Friday, April 18, 2014
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.
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.
Wednesday, April 16, 2014
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!
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!
Sunday, April 13, 2014
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.
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.
Friday, March 28, 2014
Building a Ship (Map)
The on-ship cutscene is a staple of classic RPGs. Although in the first Final Fantasy, there was no separate map to indicate being on board the ship (or airship), I seem to recall one in Final Fantasy IV (probably just before the entire gang got attacked by Leviathan), and there were certainly scenes of that nature in Final Fantasy VI - even more so if you include the airship.
Well, in my work on the harbor town I'm designing, and the nearby sea shrine, it came to me that I'm going to need to have a scene on board the ship that your group eventually acquires the reins to. Trouble is, RPG Maker VX Ace does not include a tileset to be used for designing ship maps. I found a couple custom tilesets designed by fans, but they leave a lot to be desired.
It turns out that a previous version of RPG Maker - RPG Maker XP - did have a ship tileset. And I realized in another light bulb sorta moment that, just like you can download the RTP for RMVXAce, you can do so (on the very same webpage) for both previous versions of the program RMVX and RMXP! And then, you'll have access (in your Common Files) to all the default tilesets, graphics, music, etc. from those versions of the program!
Well, I thought, hey, this might be a way to grab some extra materials to develop with. Like, for example, the battler graphics (graphics for monsters you fight in encounters), are good enough, but the variety is too limited. I'd be happy with more in the same style, so they all look consistent, but there's just not enough included with the program. Well, it turns out that VX's graphics are very similar to VXAce, only a bit more primitive, and barely anything new that VXAce doesn't already cover.
XP is further removed from the VX series, so you'd think it might have more options, but the drop in quality is considerable. Plus, as far as the battler graphics are concerned, there is way too much emphasis on humanoid enemies (as opposed to more animal-based enemies like my game requires). Also, XP used a graphical standard where the characters were two tiles tall (I think I've seen people refer to it as "mack", but I don't know what that means), instead of the "chibi" one tile square standard that VX/Ace uses.
Personally, I prefer the one tile standard, even if it distorts the character more, because it more accurately reflects the graphical style of the classic Final Fantasy RPGs I'm drawing most of my inspiration from, and that was one of the compelling reasons that led me to get my hands on VX Ace when I had passed on many of its RPG Maker forebears. Anyhow, the fact that XP uses two tile tall characters means a lot of the graphic proportions are unsuitable for a game designed with VX/Ace. :-/
However, for the ship tileset, I'm willing to make an exception, because there really aren't any satisfactory alternatives that I've come across. But, it's not a pretty compromise. I had to modify the actual dimensions of the tileset file so it works in VX Ace. And, as far as I can surmise, RMXP used a system that involved many more layers of graphical superposition so you can, for example, lay the mast down over top of the ship's deck. This is harder to do in VXAce, without carefully manipulating which tiles go on which layer, but it can be fudged by using events (for which you can select a graphical tile, and place over top of the actual map).
But that's not all. It's a bit hard to figure out where all the ship tiles are supposed to go, and how they're supposed to be used. I unfortunately don't have access to any kind of sample map from XP, like I do in VX Ace, to see how the designer was intended to use the ship tiles. You'd think it'd be a simple enough matter to figure out via trial and error, and it more or less is, but one thing that confounds me is that the back of the ship doesn't fit together with the front. For the life of me, I don't know what's going on there, and I wish I knew how XP built a ship, because to me it looks like it can't be done with the tiles included.
Anyway, I actually went in and graphically modified the relative positions of some of the tiles, so that the back and the front of the ship match, and did my best to build a decent ship map - inside and out. It's not very shiny, but I think it's good enough to use. Go ahead and take a peek at it:
I'm going to give you a link to the ship tileset files I used, adapted from RMXP to work in RMVXAce, with the back of the ship adjusted to fit the front. Note that I used a lot of events, especially for the mast, but also for the overhang on the front of the ship, to get it looking the way it does in my map. All you have to do is import the files into your tileset folder, and then add them to a tileset in the Database. I recommend making a new one just for ships. You'll probably want the ocean tiles, and I also put the wooden plank floor tiles in files for the A layer (so you can place other stuff on top of them) - I'll give you those, too. Make sure you set the passability settings in the Database so the program knows where to let the player walk and where not to.
Disclaimer: I can't seem to figure out how to get the translucency to work. The transparency should work fine, but if the shadows under some of these tiles seem a little blunt, that's why.
Note: You can place any other tilesets in the remaining B, C, D, and E slots (whichever two you didn't use for the ship tilesets). For example, I put Inside_B and Inside_C (standard Interior tilesets that come with the RTP) in the D and E slots for some basic interior stuff (beds, shelves, etc.). It's up to you.
Good luck! And if you find a more elegant solution to the lack of a ship tileset in RMVXAce, please let me know what it is...
Well, in my work on the harbor town I'm designing, and the nearby sea shrine, it came to me that I'm going to need to have a scene on board the ship that your group eventually acquires the reins to. Trouble is, RPG Maker VX Ace does not include a tileset to be used for designing ship maps. I found a couple custom tilesets designed by fans, but they leave a lot to be desired.
It turns out that a previous version of RPG Maker - RPG Maker XP - did have a ship tileset. And I realized in another light bulb sorta moment that, just like you can download the RTP for RMVXAce, you can do so (on the very same webpage) for both previous versions of the program RMVX and RMXP! And then, you'll have access (in your Common Files) to all the default tilesets, graphics, music, etc. from those versions of the program!
Well, I thought, hey, this might be a way to grab some extra materials to develop with. Like, for example, the battler graphics (graphics for monsters you fight in encounters), are good enough, but the variety is too limited. I'd be happy with more in the same style, so they all look consistent, but there's just not enough included with the program. Well, it turns out that VX's graphics are very similar to VXAce, only a bit more primitive, and barely anything new that VXAce doesn't already cover.
XP is further removed from the VX series, so you'd think it might have more options, but the drop in quality is considerable. Plus, as far as the battler graphics are concerned, there is way too much emphasis on humanoid enemies (as opposed to more animal-based enemies like my game requires). Also, XP used a graphical standard where the characters were two tiles tall (I think I've seen people refer to it as "mack", but I don't know what that means), instead of the "chibi" one tile square standard that VX/Ace uses.
Personally, I prefer the one tile standard, even if it distorts the character more, because it more accurately reflects the graphical style of the classic Final Fantasy RPGs I'm drawing most of my inspiration from, and that was one of the compelling reasons that led me to get my hands on VX Ace when I had passed on many of its RPG Maker forebears. Anyhow, the fact that XP uses two tile tall characters means a lot of the graphic proportions are unsuitable for a game designed with VX/Ace. :-/
However, for the ship tileset, I'm willing to make an exception, because there really aren't any satisfactory alternatives that I've come across. But, it's not a pretty compromise. I had to modify the actual dimensions of the tileset file so it works in VX Ace. And, as far as I can surmise, RMXP used a system that involved many more layers of graphical superposition so you can, for example, lay the mast down over top of the ship's deck. This is harder to do in VXAce, without carefully manipulating which tiles go on which layer, but it can be fudged by using events (for which you can select a graphical tile, and place over top of the actual map).
But that's not all. It's a bit hard to figure out where all the ship tiles are supposed to go, and how they're supposed to be used. I unfortunately don't have access to any kind of sample map from XP, like I do in VX Ace, to see how the designer was intended to use the ship tiles. You'd think it'd be a simple enough matter to figure out via trial and error, and it more or less is, but one thing that confounds me is that the back of the ship doesn't fit together with the front. For the life of me, I don't know what's going on there, and I wish I knew how XP built a ship, because to me it looks like it can't be done with the tiles included.
Anyway, I actually went in and graphically modified the relative positions of some of the tiles, so that the back and the front of the ship match, and did my best to build a decent ship map - inside and out. It's not very shiny, but I think it's good enough to use. Go ahead and take a peek at it:
I'm going to give you a link to the ship tileset files I used, adapted from RMXP to work in RMVXAce, with the back of the ship adjusted to fit the front. Note that I used a lot of events, especially for the mast, but also for the overhang on the front of the ship, to get it looking the way it does in my map. All you have to do is import the files into your tileset folder, and then add them to a tileset in the Database. I recommend making a new one just for ships. You'll probably want the ocean tiles, and I also put the wooden plank floor tiles in files for the A layer (so you can place other stuff on top of them) - I'll give you those, too. Make sure you set the passability settings in the Database so the program knows where to let the player walk and where not to.
Ship_A1 - ocean tiles
(place this in the A1 slot since they're autotiles)
Ship_A5 - floor tiles
(place this in the A5 slot since they're not autotiles)
Ship_Bfix - first half of the ship tileset, with modified back of ship
(place this in the B, C, D, or E slot - these tiles go on top of A tiles)
Ship_C - second half of the ship tileset, mostly interiors
(place this in the B, C, D, or E slot - these tiles go on top of A tiles)
Disclaimer: I can't seem to figure out how to get the translucency to work. The transparency should work fine, but if the shadows under some of these tiles seem a little blunt, that's why.
Note: You can place any other tilesets in the remaining B, C, D, and E slots (whichever two you didn't use for the ship tilesets). For example, I put Inside_B and Inside_C (standard Interior tilesets that come with the RTP) in the D and E slots for some basic interior stuff (beds, shelves, etc.). It's up to you.
Good luck! And if you find a more elegant solution to the lack of a ship tileset in RMVXAce, please let me know what it is...
Subscribe to:
Comments (Atom)