(For my fellow players, here is a link to the most helpful guide I found on this game).
I thought it might be helpful to go back and play some classic RPGs for inspiration. And in light of my recent decision to scale back the complexity of my game (at least from the start), the first Dragon Quest (known in North America as Dragon Warrior) seemed like the perfect place to start. It actually preceded the first Final Fantasy by about a year or so, and is at least an order of magnitude simpler.
I find the simplicity very appealing as a novice (and solo) developer, and I'm tempted to try building a bare bones proto-RPG as a practice exercise - to sort of teach myself the basics before I try putting together something more complicated, with multiple playable characters and such. Except, I'm not sure how confident I feel about diverting that time and effort from the game I really want to be working on (Dragonfaith).
But about Dragon Quest. I never actually played any of the Dragon Quest games until my friend gave me his NES cartridge not that many years ago, despite growing up on the Final Fantasy series (which seems to have attracted more popularity in America). But I've just finished playing through it for the second time ever, and I jotted down some of my (more or less scattered) thoughts while I was playing it:
* I knew the gameplay was going to be basic for a game this old, but wow - you have to select commands from a menu to do simple things like talk to people and use stairs!
* Combat utilizes a front-facing battle screen, where the monsters are drawn to face the player as he sits in front of the screen, and the hero is not drawn on the screen at all. This is interesting, because this is the default battle system in RPG Maker VX Ace, and it's not the one I'm used to - which is the side-facing battle screen of Final Fantasy.
* Very basic combat. Party includes only a single hero (as opposed to the first Final Fantasy's four-hero party), and you only fight a single monster at a time. This means that all the physical and magic skills are combined into one character. I like that, from a simplistic development perspective.
* I like the spells in this game. They're very basic, but functional, and there's a good mix of spells designed for combat (Heal, Hurt, Sleep, Stopspell), and spells that are useful outside of combat (Radiant, Outside, Return, Repel). No spell feels useless. Well, except Hurtmore, since by the time I learned it, I didn't really need it for anything except the final boss, and every time I tried to use it on the final boss, it failed, so I just gave up trying. But it's not like Final Fantasy where you have a ton of spells that do the same thing (Fire, Ice, Lit - although I do like the concept of elements), and a million different status ailments or enhancements, many of which work so rarely that you never bother using them.
* Stats begin in the single digits. I think this really makes a lot of sense. The default stats on RPG Maker VX Ace are totally out of whack, and have level 1 actors dealing hundreds of damage right from out of the gate. I don't like that. In Dragon Quest, you start with single digit stats. The first enemies are slimes that do 1 or 2 damage, and only have a few HP. You're evenly matched at first, until you begin to level up and then eventually the slimes are dust you brush off your shoulder. That's the way it should be. Your growth is gradual and starts from a reasonable point. By the end of the game, you're probably not more than level 20, and dealing a hundred damage at once is unthinkable (as opposed to Final Fantasy's 9999 damage cap at level 99). Again, we're dealing with a simpler system here.
* Here's something that I find very interesting. Unlike Final Fantasy, which uses a gated system (which I am admittedly fond of) whereby parts of the game world are opened up to the player gradually as they unlock certain obstacles (chronicled here), when you start Dragon Quest, the whole world (apart from the final dungeon alone) is theoretically open to you, and the only thing keeping you from going anywhere you want is that the monsters get stronger and you need to build up your stats first, if you don't want your ass handed to you on a platter. I actually think this is very clever.
* On the other hand, the downside of this is that the gameplay in Dragon Quest relies heavily on "grinding" - where you're fighting the same monsters over and over again just to level up - which isn't very fun. Later, more advanced RPGs have enough story content to keep you moving through the game, whereas here it feels like you're frequently getting stuck and you can't advance in the game without a whole lot of fighting the same monsters over and over again. It gives you more time to grow with the game, but it does it in a way that feels cheap, like filler.
* Dragon Quest features a very basic fantasy setting with conventional elements (e.g., a knight trying to save a princess from a dragon). While this is a very simplified approach and eliminates any concern for developing complicated story elements, it also greatly reduces the player's incentive to finish the game and find out what happens next, as they are probably not that invested in the characters or the plot (unlike the more advanced RPGs I know of).
* The dungeons are dark, and require a torch (or other light source) to be properly explored. This wasn't the case in Final Fantasy games, but I think it's a neat gameplay element. Although, the dungeons themselves are all very samey, and suffer from a lack of graphical variation (which is something that Final Fantasy, at least, succeeded on).
* There is, mostly, a logical progression in the weapons/armor you use. While I am fond of the Final Fantasy system of having tons of equipment with an at times arbitrary hierarchy of attack/defense power, I am also attracted to a simpler, more intuitive system where, instead of getting a new sword and set of armor in every town, you progress naturally through stronger weapons and armor (like from a bamboo pole to a club to a copper sword to a hand axe to a broad sword, or from clothes to leather armor to chain mail to a half plate to a full plate). This suits my RPG better in a conceptual sense, in that part of its genesis was inspired by a desire to introduce some level of realism to typical RPG cliches (explained here), but I have yet to come to a final decision about how I'm going to handle equipment in my own game.
* Considering the difficulty of getting magic keys - their high price
and the difficulty in originally getting to the town that sells them -
the reward is rarely worthwhile. Though there are some parts of the game
that require having the keys to advance, a lot of the treasure chests
and areas unlocked by them are bogus. It doesn't have the same feeling
of accomplishment as getting the Mystic Key in Final Fantasy, for
example.
* The only place you can save your game is at the king in the first castle. This is an interesting choice, conceptually, since it has to do with recording your deeds on the "Imperial Scroll of Honor", but I don't think I like it, from a more practical perspective. Gameplay is inevitably centralized around the first castle (instead of moving from town to town as you progress through the game), such that the last time you load up your game, to brave the final dungeon and battle the final boss, you start playing from the same spot you did when you first started the game (and even though the final dungeon is tantalizingly in view of the first castle, it requires a roundabout trek to access it).
* This means that there's a lot of tedious coming and going, particularly in later parts of the game (and with no vehicles to speed things up). The world map is not super humongous, but you have to consider all the time spent traveling through early areas later in the game. Already, at level 10, fighting slimes is nothing but an annoying waste of time. They can in no way threaten your safety, and the paltry reward you get for killing them isn't even worth the effort of squashing them under your boot. And yet, you can't ignore them, because they keep throwing themselves at you like pests!
* You do learn a handy spell (Repel) to solve this problem, but considering that it only works on weaker enemies, and is therefore only a convenience, and not a significant battle advantage, you learn it much too late in the game (level 15).
* Maybe this is just me (I tend to play games in the same risk-averse fashion that I live my life), but the difference between tiers of enemies often seems to be life and death. If I'm on the verge between one tier and the next, I find that there's a tedious period during which I'm strong enough to beat the lower tier without breaking a sweat, but still weak enough to be wiped out by the larger tier in a single battle. Which means, rather than risking my life to fight the stronger enemies which would earn me more experience so I can level up faster, I'm stuck mindlessly fighting the weaker enemies at a slower rate of progress.
* On the other hand, death in this game only means that you lose half your gold and have to start back at the castle. Losing all that hard-won gold is unacceptable earlier in the game, but it seems that there comes a point later on when you max out your buyable equipment, and gold becomes pretty much useless to you.
* I don't know if there's even any point in worrying about this being a spoiler, but all I'll say is that the choice the Dragonlord gives you at the end of the game (and the penalty for choosing unwisely) is ingenious.
Concluding Remarks: I understand that Dragon Quest was an extremely influential pioneer in the realm of console RPGs, paving the way for the likes of the immensely popular Final Fantasy series (among other games), and nothing can take that away from it. Taken on its own merit, it's still a fun and creative little game, allowing for its unavoidably primitive nature (and in some ways, the simplicity can be appealing).
However, I consider the alleged tweaks that have been made to better balance the combat in recent "remixed" versions to be fixing the game (as opposed to tinkering with it), as in its original state, the grinding can become frustrating to the point that only a diehard old school RPG fan would have the patience to play it through to the ending. I feel like I spent about a month longer on this game than I should have - given its simple story - and much of that time was spent dragging my feet because I was too bored to sit and grind for another hour.
Meanwhile, pioneer though it was, Dragon Quest is overshadowed by the more evolved RPGs that followed in its wake, both in the Final Fantasy series, and, presumably (as I have yet to play them, though I'm planning to make some time for it in the near future) in its own series. More precisely, it is my opinion that the golden age of the console RPG was the Super Nintendo years. But it's still illuminating to jump back and see where the boom began.
Monday, November 24, 2014
Friday, November 21, 2014
Adjusting Encounter Rate
On every map in an RPG Maker VX Ace project, you can specify the average number of steps between random enemy encounters (on regions designated for random encounters), in the Map Properties window (below where you assign troops to each region). This gives you some level of control over how often a player will run into random encounters, but the formula the program uses to calculate the number of steps between any two given encounters leaves much to be desired. This formula can be found in the script editor on line 195 of Game_Player, and is as follows:
The good news is, changing the program's behavior is as simple as modifying the above formula. Feel free to let your imagination run wild. A simple alternative that I'm using for the time being is as follows:
And if you don't want to change the default code (which I wouldn't recommend), just paste this code into the Materials section (with whichever updated formula you want to use) and it will overwrite the default:
Click here for another mini-script related to random encounters.
@encounter_count = rand(n) + rand(n) + 1where "@encounter_count" is the number of steps until the next encounter, and "n" corresponds to the average number of steps between encounters that you specify in the Map Properties window on any given map. This formula calculates a random number from 1 to twice the average steps (plus 1) you've given the map. That means that on a map that you've chosen the average steps between encounters to be 20, for example, you could go anywhere from just a single step to as many as 41 steps before your next encounter. Quite frankly, I think that's too much variance, and especially on the low side, only being able to get a few steps between encounters is pretty frustrating.
The good news is, changing the program's behavior is as simple as modifying the above formula. Feel free to let your imagination run wild. A simple alternative that I'm using for the time being is as follows:
@encounter_count = rand(n) + n / 2Here, the lowest possible number of steps before the next encounter will be: not 1, but half whatever the average steps between encounters is, and the maximum will be 50% more than the average. So, if you set the average to be 20 on a map, the steps calculated between encounters will always be between 10 (half the average) and 30 (three halves of the average). There's still a lot of variance there, but this formula cuts out the really short and really long travels between encounters to make it all a bit more consistent. As I said, you can fool with the formula as much as you like.
And if you don't want to change the default code (which I wouldn't recommend), just paste this code into the Materials section (with whichever updated formula you want to use) and it will overwrite the default:
class Game_Player < Game_Character
def make_encounter_count
n = $game_map.encounter_step
@encounter_count = rand(n) + n / 2
end
end
I recommend you give it a title ("encounter adjustment", perhaps?) so you know what it does at a glance in the future. This is a nondestructive way of messing around with the scripts so that if for whatever reason you want to revert to the default, you can just delete the added code in the Materials section!Click here for another mini-script related to random encounters.
Monday, November 17, 2014
Battler Woes
So one of the big problems with bringing my game to life is the limitations of the "battlers" provided by RPG Maker VX Ace. ("Battlers" are the graphical images of the enemies that appear on screen during combat). My number one complaint with the battlers is the vast proportion of humanoid enemies to the exclusion of a better selection of animal-based enemies (which are, unfortunately, the focus in my particular game).
Out of 74 total default battlers, well over half of them are humanoid in nature, many including a male and female version of a particular class (Cleric, Dark Elf, Grappler, Hero, Paladin, Thief, Warrior, Wizard - oh, and God/Goddess). This is great, I guess, for games where people fight other people, but this is RPG Maker, not Tournament Fighter Maker. Anyway, going through the battlers, here are some of my specific complaints:
* Ok, before I get into my complaints, there are some good boss battlers in the set, even a few that would make good final bosses (particularly Darklord, Demon, Evilgod), so that's a plus. I would still welcome some more variety, though.
* The elemental battlers (Earthspirit, Firespirit, Waterspirit, Windspirit) leave something to be desired for me, graphically.
* There are two wolf-like battlers, but one of them is a Werewolf and the other one is Cerberus ("Kerberos"). Unless you want the wolves in your game world to be part-man or have three heads, there's no basic "wolf" battler.
* The Spider, Snake, and Scorpion battlers are all huge! I prefer the smaller snakes and spiders and scorpions of Final Fantasy 1. They're dangerous because, in spite of their small size, they dangle the threat of poison in front of you. They're not the type of enemies who rely on strength and size...
* There are no horse-based battlers (I'm sorry, but I liked the MadPonys and NiteMares of Final Fantasy 1).
* There are no crocodile or shark battlers. There is a Jellyfish, which is good (though no giant squid for a boss), and even the "Gayzer" (remember OddEye?) from Final Fantasy is replicated (despite, to my knowledge, not representing anything that lives on this Earth). There's a "Sahagin" battler, which is a fish warrior, but other than those, there's not a whole lot of other sea or water-based battlers.
* There's only a single Dragon. It's a pretty cool dragon. But there's only the one. Sure, you can adjust its hue, but my game requires 13 dragons, and so a little variety is pretty much required. One of the coolest things, for me, about the classic Final Fantasy games (even going back to the very first one) was the great diversity of dragons you encountered. I even dedicated a web page to it once! And the 8 Legendary Dragons of Final Fantasy VI was obviously a strong influence on my desire to make an RPG with a focus on a pantheon of powerful dragon bosses. But with just the one dragon, I'm honestly at a loss as to what to do...
* There are no robot battlers. I understand that this program is designed to make fantasy games, not sci-fi games, but even just a single robot-based battler would have been nice. Robot enemies turn up in a lot of the classic Final Fantasies (WarMech anyone?), which, despite being fantasy-based, often take advantage of the opportunity to have at least one dungeon in the game be all futuristic and sci-fi-y (e.g., the Sky Castle, the Tower of Zot/Tower of Bab-il/Giant of Bab-il, the Magitek Research Facility).
* They have a number of undead battlers - including Zombies, "Ghosts", Vampires, and even Death itself. This is good, even though I'm going to have difficulty working any of them into my game. But yet not one robot battler...
* They only have one bird-type battler (not including Bats and Gargoyles), and it's a weird cross between a Cockatrice (which it is apparently trying to be) and a chicken. It's fine enough on its own, but if you want some different kinds of bird-type enemies, you're pretty much stuck. Good luck trying to pass a chicken with a lizard's tail off as a "raven" or somesuch. I tried making it a raptor once, since there is a lack of reptilian battlers (do snakes count?) and no dinosaur battlers to speak of, but that's obviously a stretch. There is a tengu warrior (Garuda), but it's pretty extravagantly decorated and has the same problem as the Werewolf if you're looking for more animalian creatures.
There are some good battlers - don't get me wrong - and it's a good hodgepodge of RPG classics. But honestly I really wish there were just more variety. I'd even be willing to pay extra for a bonus pack of battlers drawn in the same style (and comparable quality) to supplicate the ones that come with the program, but I've seen no such thing. I'd be willing to buy a complete set drawn by someone else, provided they were good quality, meshed well with the graphics already in use in the game, and covered all the basics that the default battlers already cover.
So far, I've seen nothing available in the fan community (for pay or for free) that is of a professional quality, and not narrowly shoehorned into some particular alternative play style (rather than the "generic RPG" style that the default battlers assume). Picking and choosing battlers here and there is not an attractive option for me because I really think cohesion of style is important for a game. It's the primary reason I haven't broken down and just nicked a bunch of sprites from Final Fantasy to use in my game (well, that, and the fact that Final Fantasy uses a side-view battle system and RPG Maker opts for the front-view battle system like Dragon Quest)...
Out of 74 total default battlers, well over half of them are humanoid in nature, many including a male and female version of a particular class (Cleric, Dark Elf, Grappler, Hero, Paladin, Thief, Warrior, Wizard - oh, and God/Goddess). This is great, I guess, for games where people fight other people, but this is RPG Maker, not Tournament Fighter Maker. Anyway, going through the battlers, here are some of my specific complaints:
* Ok, before I get into my complaints, there are some good boss battlers in the set, even a few that would make good final bosses (particularly Darklord, Demon, Evilgod), so that's a plus. I would still welcome some more variety, though.
* The elemental battlers (Earthspirit, Firespirit, Waterspirit, Windspirit) leave something to be desired for me, graphically.
* There are two wolf-like battlers, but one of them is a Werewolf and the other one is Cerberus ("Kerberos"). Unless you want the wolves in your game world to be part-man or have three heads, there's no basic "wolf" battler.
* The Spider, Snake, and Scorpion battlers are all huge! I prefer the smaller snakes and spiders and scorpions of Final Fantasy 1. They're dangerous because, in spite of their small size, they dangle the threat of poison in front of you. They're not the type of enemies who rely on strength and size...
* There are no horse-based battlers (I'm sorry, but I liked the MadPonys and NiteMares of Final Fantasy 1).
* There are no crocodile or shark battlers. There is a Jellyfish, which is good (though no giant squid for a boss), and even the "Gayzer" (remember OddEye?) from Final Fantasy is replicated (despite, to my knowledge, not representing anything that lives on this Earth). There's a "Sahagin" battler, which is a fish warrior, but other than those, there's not a whole lot of other sea or water-based battlers.
* There's only a single Dragon. It's a pretty cool dragon. But there's only the one. Sure, you can adjust its hue, but my game requires 13 dragons, and so a little variety is pretty much required. One of the coolest things, for me, about the classic Final Fantasy games (even going back to the very first one) was the great diversity of dragons you encountered. I even dedicated a web page to it once! And the 8 Legendary Dragons of Final Fantasy VI was obviously a strong influence on my desire to make an RPG with a focus on a pantheon of powerful dragon bosses. But with just the one dragon, I'm honestly at a loss as to what to do...
* There are no robot battlers. I understand that this program is designed to make fantasy games, not sci-fi games, but even just a single robot-based battler would have been nice. Robot enemies turn up in a lot of the classic Final Fantasies (WarMech anyone?), which, despite being fantasy-based, often take advantage of the opportunity to have at least one dungeon in the game be all futuristic and sci-fi-y (e.g., the Sky Castle, the Tower of Zot/Tower of Bab-il/Giant of Bab-il, the Magitek Research Facility).
* They have a number of undead battlers - including Zombies, "Ghosts", Vampires, and even Death itself. This is good, even though I'm going to have difficulty working any of them into my game. But yet not one robot battler...
* They only have one bird-type battler (not including Bats and Gargoyles), and it's a weird cross between a Cockatrice (which it is apparently trying to be) and a chicken. It's fine enough on its own, but if you want some different kinds of bird-type enemies, you're pretty much stuck. Good luck trying to pass a chicken with a lizard's tail off as a "raven" or somesuch. I tried making it a raptor once, since there is a lack of reptilian battlers (do snakes count?) and no dinosaur battlers to speak of, but that's obviously a stretch. There is a tengu warrior (Garuda), but it's pretty extravagantly decorated and has the same problem as the Werewolf if you're looking for more animalian creatures.
There are some good battlers - don't get me wrong - and it's a good hodgepodge of RPG classics. But honestly I really wish there were just more variety. I'd even be willing to pay extra for a bonus pack of battlers drawn in the same style (and comparable quality) to supplicate the ones that come with the program, but I've seen no such thing. I'd be willing to buy a complete set drawn by someone else, provided they were good quality, meshed well with the graphics already in use in the game, and covered all the basics that the default battlers already cover.
So far, I've seen nothing available in the fan community (for pay or for free) that is of a professional quality, and not narrowly shoehorned into some particular alternative play style (rather than the "generic RPG" style that the default battlers assume). Picking and choosing battlers here and there is not an attractive option for me because I really think cohesion of style is important for a game. It's the primary reason I haven't broken down and just nicked a bunch of sprites from Final Fantasy to use in my game (well, that, and the fact that Final Fantasy uses a side-view battle system and RPG Maker opts for the front-view battle system like Dragon Quest)...
Saturday, November 15, 2014
Convention and Originality
One of the difficulties I've been having with working on my RPG, Dragonfaith, is that when I originally began visualizing it in my head, a lot of its features were designed as a response to many of the cliches and conventions of the RPG genre. The basic plot, for example - nature rising up against man - serves the purpose of giving the player a reason and an excuse to go out into the wild slaughtering beasts left and right. And the entirety of the Hunters Guild wasn't even part of the original story, but an invention designed to provide the possibility for alternatives to the usual random enemy encounter system which is so critical to the genre, and yet frequently frustrating to players.
The reason this is a problem is that, now that I've sat down and begun building an RPG for real, while I may be a veteran RPG player, I am a total n00b when it comes to actually putting together a game like this. My ideas are, in a sense, far more advanced than my technical abilities. And I feel like - in the vein of learning to walk before you can run - I should focus on learning how to actually make a conventional RPG first, before I decide to try circumventing all the usual rules; especially since I'm building my game with a program that's essentially designed to replicate all the conventions of typical RPGs, where learning how to code around the expectations of its users is an additional skill above and beyond learning the program to create RPGs in the first place.
So it's a constant struggle to decide between trying to be fancy and bring my vision to life the way it was intended, and scaling back my ambitions and just trying to put together a game that works, while telling the story I want to tell (which doesn't rely on doing it in a totally original way). And it's a problem when you can't decide what you actually want to create, because, as I've discovered before, having a clear goal in mind makes the creative process flow much more smoothly (which means better focus and more progress). Indecisiveness, on the other hand, halts progress and inspires the mind to distract itself and wander elsewhere.
In any case, I've been working on the game a lot these past few weeks, since my schedule opened up following October's month-long movie marathon. I'm not giving you a date on any future releases, because it'll be ready when it's ready. But I've been polishing up everything that I've worked on so far, paring some of the complexity back, with an eye toward the great, largely blank space that constitutes the rest of the game I haven't clearly visualized yet. And I've been playing a particularly classic RPG for inspiration as well (with others in the queue), which I should have a few words to say about here on this blog in the very near future.
The reason this is a problem is that, now that I've sat down and begun building an RPG for real, while I may be a veteran RPG player, I am a total n00b when it comes to actually putting together a game like this. My ideas are, in a sense, far more advanced than my technical abilities. And I feel like - in the vein of learning to walk before you can run - I should focus on learning how to actually make a conventional RPG first, before I decide to try circumventing all the usual rules; especially since I'm building my game with a program that's essentially designed to replicate all the conventions of typical RPGs, where learning how to code around the expectations of its users is an additional skill above and beyond learning the program to create RPGs in the first place.
So it's a constant struggle to decide between trying to be fancy and bring my vision to life the way it was intended, and scaling back my ambitions and just trying to put together a game that works, while telling the story I want to tell (which doesn't rely on doing it in a totally original way). And it's a problem when you can't decide what you actually want to create, because, as I've discovered before, having a clear goal in mind makes the creative process flow much more smoothly (which means better focus and more progress). Indecisiveness, on the other hand, halts progress and inspires the mind to distract itself and wander elsewhere.
In any case, I've been working on the game a lot these past few weeks, since my schedule opened up following October's month-long movie marathon. I'm not giving you a date on any future releases, because it'll be ready when it's ready. But I've been polishing up everything that I've worked on so far, paring some of the complexity back, with an eye toward the great, largely blank space that constitutes the rest of the game I haven't clearly visualized yet. And I've been playing a particularly classic RPG for inspiration as well (with others in the queue), which I should have a few words to say about here on this blog in the very near future.
Friday, November 7, 2014
Building a Canoe
Vehicles in RPG Maker VX Ace (without scripts) behave in a certain way. This post is concerned primarily with the "boat", which is not to be confused with the "ship". The ship is the typical RPG ship vehicle, which moves at double speed over ocean tiles (shallow or deep). Unlike in Final Fantasy (the first one), though, ships can dock anywhere on land - not just at ports - and it can also sail up rivers, basically making the boat obsolete once you get the ship.
The boat, on the other hand, instead of just paddling up rivers, can also traverse shallow ocean tiles. This can be an advantage or a disadvantage depending on what your game requires. But also depending on your RPG experience, it can be a little counter-intuitive (I'm finding that RPG Maker VX Ace is a bit of an amalgam of different RPG conventions from various sources, which is good in that it's not just a duplicate of one particular game, but can be frustrating if you're trying to model your own game after certain conventions you're used to from a particular title).
Anyway, I was wondering if I could build a canoe that works like the one in Final Fantasy, which doesn't act like a vehicle in that it sits on the map in one place and you board it, move around, and then disembark. The Final Fantasy canoe is more like an item you carry in your inventory: once you have it, previously impassable rivers are now passable. You don't need to find your canoe and board it first - you already have it with you. You just step onto the river, and your player graphic changes to the canoe, and once you step off, it changes back to your character.
Well, the RMVXAce "boat" doesn't work that way - it's a full-on vehicle, like the ship. But, as an exercise to demonstrate how to manipulate certain aspects of the game (in this case, without using scripts), let me describe a workaround I've come up with. To start with, the default settings ensure that the player can not simply walk over river tiles. This is easy enough to change, by navigating to the tileset tab of the Database, and changing the passage setting of the river tile on the "Field" tileset (second row, first column) from an X to an O.
Presumably, though, there'll be a point in your game before your character acquires the canoe. So, what you can do is copy the Field tileset and paste it onto another line (you may have to increase the maximum). On one of them, the river tile should be set to impassable, and on the other one (you should name it differently so you can tell the difference), it should be set to passable. Then, all you need to do is use the "Change Tileset" Event Command once your player acquires the canoe, on any maps with rivers, to change it from the default Field tileset to the new one with the rivers set to passable!
But, there's something you still need to account for. When you change a map's tileset via the Change Tileset Event Command, it resets whenever you leave that map. Furthermore, I don't think you can change the tileset of any other map than the one you're on when the Event triggers - which wouldn't work if you acquire the canoe in a town, and the rivers are all on the world map.
Well, here's what you can do: on any maps that have rivers, create an autorun event. It should trigger only once the player has acquired the canoe (you can check this with a switch, or else by whether the player has the canoe item, if you want to treat it that way). It should change the tileset of the map as discussed above and then erase itself (Erase Event). That way it will fix the map every time you enter it after acquiring the canoe, so that you will be able to walk over the rivers.
Now, then, you're going to need another event on the same map - a Parallel Process that runs only when the player has the canoe. This event is going to check the player's map position (by storing them in variables), and then determine the terrain tag (by storing it in another variable) of the tile the player is currently standing on (with the "Get Location" command). Of course, you'll have to go back into the Database and give the river tile (on the passable version of the Field tileset) a terrain tag (and make sure it doesn't conflict with any other terrain tags you might be using on the same map).
In the Parallel Process event, you'll want to run a conditional branch that checks whether the terrain tag of the tile the player is standing on (which you stored in a variable) matches the one you gave the river tile in the Database. If it does, use a Set Move Route command and change the player's graphic to the boat graphic, and then turn a self-switch on. Now you're in river mode.
Create a new page in the same event (also triggered by parallel process), with the conditional being the self-switch you just turned on. Now, you're going to do the same thing as before (get the player's position, store the terrain tag in a variable, then check that variable), but this time you want the conditional to run only when the terrain tag is NOT equal to the one you gave the river tile in the Database. When that happens, simply change the player's graphic back to what it was using another Set Move Route command, and then turn off the self-switch. You're back in land mode!
You can do all sorts of things now, like disable the save function when the player is on a river tile, by adding the appropriate commands to the event in the same place where you changed the player's graphic. You also may need to run a conditional branch when changing the player's graphic back, to determine which party member is at the head of the party. In fact, you'll probably want to disable Formation Access while the player is in the canoe as well, so the player doesn't switch out the canoe graphic for a different character. And, graphically, this canoe feature doesn't work well if you're using "Player Followers" (which I don't like anyway).
Those are the basics. It seems to work pretty well for me so far - I've even managed to get a waterfall cave (map transfer from river tile to dungeon, and back again) working. You can even dock the ship at a river mouth, too! Just like in the first Final Fantasy. I rigged up a nice little tutorial (like I've seen users do on the RPG Maker forums) that demonstrates how my FF canoe works - you can download it here and play it like any other RPG Maker game. Also, it's unencrypted, so you can open the project file up in RPG Maker and see just how all the events work. It's a lot like my Prefab Smithy, but taken just one more step further!
The boat, on the other hand, instead of just paddling up rivers, can also traverse shallow ocean tiles. This can be an advantage or a disadvantage depending on what your game requires. But also depending on your RPG experience, it can be a little counter-intuitive (I'm finding that RPG Maker VX Ace is a bit of an amalgam of different RPG conventions from various sources, which is good in that it's not just a duplicate of one particular game, but can be frustrating if you're trying to model your own game after certain conventions you're used to from a particular title).
Anyway, I was wondering if I could build a canoe that works like the one in Final Fantasy, which doesn't act like a vehicle in that it sits on the map in one place and you board it, move around, and then disembark. The Final Fantasy canoe is more like an item you carry in your inventory: once you have it, previously impassable rivers are now passable. You don't need to find your canoe and board it first - you already have it with you. You just step onto the river, and your player graphic changes to the canoe, and once you step off, it changes back to your character.
Well, the RMVXAce "boat" doesn't work that way - it's a full-on vehicle, like the ship. But, as an exercise to demonstrate how to manipulate certain aspects of the game (in this case, without using scripts), let me describe a workaround I've come up with. To start with, the default settings ensure that the player can not simply walk over river tiles. This is easy enough to change, by navigating to the tileset tab of the Database, and changing the passage setting of the river tile on the "Field" tileset (second row, first column) from an X to an O.
Presumably, though, there'll be a point in your game before your character acquires the canoe. So, what you can do is copy the Field tileset and paste it onto another line (you may have to increase the maximum). On one of them, the river tile should be set to impassable, and on the other one (you should name it differently so you can tell the difference), it should be set to passable. Then, all you need to do is use the "Change Tileset" Event Command once your player acquires the canoe, on any maps with rivers, to change it from the default Field tileset to the new one with the rivers set to passable!
But, there's something you still need to account for. When you change a map's tileset via the Change Tileset Event Command, it resets whenever you leave that map. Furthermore, I don't think you can change the tileset of any other map than the one you're on when the Event triggers - which wouldn't work if you acquire the canoe in a town, and the rivers are all on the world map.
Well, here's what you can do: on any maps that have rivers, create an autorun event. It should trigger only once the player has acquired the canoe (you can check this with a switch, or else by whether the player has the canoe item, if you want to treat it that way). It should change the tileset of the map as discussed above and then erase itself (Erase Event). That way it will fix the map every time you enter it after acquiring the canoe, so that you will be able to walk over the rivers.
Now, then, you're going to need another event on the same map - a Parallel Process that runs only when the player has the canoe. This event is going to check the player's map position (by storing them in variables), and then determine the terrain tag (by storing it in another variable) of the tile the player is currently standing on (with the "Get Location" command). Of course, you'll have to go back into the Database and give the river tile (on the passable version of the Field tileset) a terrain tag (and make sure it doesn't conflict with any other terrain tags you might be using on the same map).
In the Parallel Process event, you'll want to run a conditional branch that checks whether the terrain tag of the tile the player is standing on (which you stored in a variable) matches the one you gave the river tile in the Database. If it does, use a Set Move Route command and change the player's graphic to the boat graphic, and then turn a self-switch on. Now you're in river mode.
Create a new page in the same event (also triggered by parallel process), with the conditional being the self-switch you just turned on. Now, you're going to do the same thing as before (get the player's position, store the terrain tag in a variable, then check that variable), but this time you want the conditional to run only when the terrain tag is NOT equal to the one you gave the river tile in the Database. When that happens, simply change the player's graphic back to what it was using another Set Move Route command, and then turn off the self-switch. You're back in land mode!
You can do all sorts of things now, like disable the save function when the player is on a river tile, by adding the appropriate commands to the event in the same place where you changed the player's graphic. You also may need to run a conditional branch when changing the player's graphic back, to determine which party member is at the head of the party. In fact, you'll probably want to disable Formation Access while the player is in the canoe as well, so the player doesn't switch out the canoe graphic for a different character. And, graphically, this canoe feature doesn't work well if you're using "Player Followers" (which I don't like anyway).
Those are the basics. It seems to work pretty well for me so far - I've even managed to get a waterfall cave (map transfer from river tile to dungeon, and back again) working. You can even dock the ship at a river mouth, too! Just like in the first Final Fantasy. I rigged up a nice little tutorial (like I've seen users do on the RPG Maker forums) that demonstrates how my FF canoe works - you can download it here and play it like any other RPG Maker game. Also, it's unencrypted, so you can open the project file up in RPG Maker and see just how all the events work. It's a lot like my Prefab Smithy, but taken just one more step further!
Friday, October 3, 2014
Progress Report
I'm still awaiting feedback from my testers on the "final" version of Ascension, but in the meantime, I've had an opportunity to take a little break from developing. Even so, I've already started turning my mind back towards my Dragonfaith project, and resumed working on it with a renewed vigor. However, I've decided to kind of start back from sort-of-scratch, and rebuild the project up from the beginning, while scaling back a few things. I just feel like maybe there's too much complexity right in the beginning of the game, and it's gotten to a level where it can intimidate me way too early in the development process.
Some of the things I'm working on changing is tightening up some of the maps, to get rid of empty space, in an effort to maintain focus; rethinking the approach in dialogue; and opting for more player freedom rather than a rigidly plot-driven vehicle. I've also decided that maybe controlling a party of three characters right at the start of the game is maybe too much too soon - starting with a single character and then building up later on will make it easier both for the player to adapt to the combat in the game, as well as for me to start configuring the battle specs early on. (This approach was partly inspired by the simplicity of the first Dragon Quest/Warrior game, with which the front-view RPG Maker combat system resembles more closely than the side-view Final Fantasy system).
As much as I'd love to make a complex and character-driven story like Final Fantasys IV-VI, the fact is, RPGs are tough to design, and this is my very first one. So I don't want to burden myself with too many expectations right from the start. One of the tips I'd read in a guide on creating your first RPG is not to start with your dream project - to save it for when you actually know what you're doing. I didn't agree with it then, and I still don't agree with it completely, as I think the motivation to bring your dream project to life could be just the thing you need to actually push yourself through to the end instead of giving up halfway through (which is where I'd wager 95% of projects wind up - I've never wanted to be that guy). But there is some wisdom in that view, and certainly I've looked at my Ascension project partly as an opportunity to gain more experience before tackling Dragonfaith again.
Of course, Ascension wasn't just a detour - it was yet another dream project that I'd been wanting to bring to life, and I am immensely satisfied with what I've managed to come up with. Turning back towards Dragonfaith now, I think it's more important that I can piece this together into an actual, complete game that acts as a vehicle to tell the story I want to tell, than to get too bogged down with making comparisons to professional games I couldn't hope to equal (even if I did have the talent/experience, those games still require collaboration with many people to create). In the long-run, if this becomes something I enjoy and have the talent to do, I don't expect there will be any shortage of creative ideas bubbling around in my head, and it's not like primitive games haven't ever been redone to fulfill their true potential with later experience/technology (see: Metal Gear Solid).
Some of the things I'm working on changing is tightening up some of the maps, to get rid of empty space, in an effort to maintain focus; rethinking the approach in dialogue; and opting for more player freedom rather than a rigidly plot-driven vehicle. I've also decided that maybe controlling a party of three characters right at the start of the game is maybe too much too soon - starting with a single character and then building up later on will make it easier both for the player to adapt to the combat in the game, as well as for me to start configuring the battle specs early on. (This approach was partly inspired by the simplicity of the first Dragon Quest/Warrior game, with which the front-view RPG Maker combat system resembles more closely than the side-view Final Fantasy system).
As much as I'd love to make a complex and character-driven story like Final Fantasys IV-VI, the fact is, RPGs are tough to design, and this is my very first one. So I don't want to burden myself with too many expectations right from the start. One of the tips I'd read in a guide on creating your first RPG is not to start with your dream project - to save it for when you actually know what you're doing. I didn't agree with it then, and I still don't agree with it completely, as I think the motivation to bring your dream project to life could be just the thing you need to actually push yourself through to the end instead of giving up halfway through (which is where I'd wager 95% of projects wind up - I've never wanted to be that guy). But there is some wisdom in that view, and certainly I've looked at my Ascension project partly as an opportunity to gain more experience before tackling Dragonfaith again.
Of course, Ascension wasn't just a detour - it was yet another dream project that I'd been wanting to bring to life, and I am immensely satisfied with what I've managed to come up with. Turning back towards Dragonfaith now, I think it's more important that I can piece this together into an actual, complete game that acts as a vehicle to tell the story I want to tell, than to get too bogged down with making comparisons to professional games I couldn't hope to equal (even if I did have the talent/experience, those games still require collaboration with many people to create). In the long-run, if this becomes something I enjoy and have the talent to do, I don't expect there will be any shortage of creative ideas bubbling around in my head, and it's not like primitive games haven't ever been redone to fulfill their true potential with later experience/technology (see: Metal Gear Solid).
Thursday, September 18, 2014
Progress Report
Sorry (once again) for the delay - believe me, it's frustrating me as much as anyone. But I thought you'd appreciate it more if, instead of teasing you with another empty progress report, I waited until I was ready to give you an actual release before I posted again.
Yes, that's right, I have a release ready. I'm not sure I'm 100% satisfied with the Labyrinth stage, but seeing as I've worked on it for about a month, and every other stage closer to just a week, I'm tired of tweaking it and rethinking it. So I'm leaving it up to you, the testers, to let me know what you think of it. Frankly, I'm concerned that the one tester I've had feedback from on this stage is skewing my perception, since she's apparently the sort of person who can sit for 35 minutes straight wandering down aimless passages trying to solve a maze, without thinking anything of it. :p
So, please, let me know what you think of the maze, as well as the rest of the game. I'd love to hear your reaction to the secret, alternate ending if and when you manage to unlock it, as well. I had a lot of fun putting it together, and am very excited to show it off.
I'm putting the release on a separate page this time, so I can make it a sort of "official" release page, now that the game is going into "beta" phase (I guess). Alterations may still be made in the future, depending on the feedback I get, but this is where I close the main development stage and say that, barring bugs and the occasional conceptual exception (and my testers will be crucial for that), the game is pretty much finished, and I'm done working on it - at least in a regular, daily capacity.
Get the download here!
Yes, that's right, I have a release ready. I'm not sure I'm 100% satisfied with the Labyrinth stage, but seeing as I've worked on it for about a month, and every other stage closer to just a week, I'm tired of tweaking it and rethinking it. So I'm leaving it up to you, the testers, to let me know what you think of it. Frankly, I'm concerned that the one tester I've had feedback from on this stage is skewing my perception, since she's apparently the sort of person who can sit for 35 minutes straight wandering down aimless passages trying to solve a maze, without thinking anything of it. :p
So, please, let me know what you think of the maze, as well as the rest of the game. I'd love to hear your reaction to the secret, alternate ending if and when you manage to unlock it, as well. I had a lot of fun putting it together, and am very excited to show it off.
I'm putting the release on a separate page this time, so I can make it a sort of "official" release page, now that the game is going into "beta" phase (I guess). Alterations may still be made in the future, depending on the feedback I get, but this is where I close the main development stage and say that, barring bugs and the occasional conceptual exception (and my testers will be crucial for that), the game is pretty much finished, and I'm done working on it - at least in a regular, daily capacity.
Get the download here!
Friday, September 5, 2014
Progress Report
I have to apologize. I really wanted to get the next release out before this weekend (I'm going away, and won't be able to work on the game for several days), but it's just not going to happen. So you'll have to be a little bit more patient. Everything is pretty much finished (although I still need to go through the game and make sure everything works and there are no last minute tweaks), except the Labyrinth stage which I am still working on.
I swear, this stage is turning out to be the bane of this project. It's not to a point where I just want to give up yet - I think there is potential here for a really great stage. But there are just so many options, and wrapping my head around these mazes (to a sufficient degree of mastery as to predict how the player will experience them), while also trying to design unique challenges to disorient the player and ramp up the difficulty of solving the maze, while introducing a certain level of randomness...it boggles the mind. And every time I think I've got a good maze design to work on, I have to spend several hours building it in the map editor - so far only to ultimately decide that it's not good enough. :-\
It's pretty frustrating. But I'm still plugging away at it. Give me another week, and I'll see what I can come up with.
I swear, this stage is turning out to be the bane of this project. It's not to a point where I just want to give up yet - I think there is potential here for a really great stage. But there are just so many options, and wrapping my head around these mazes (to a sufficient degree of mastery as to predict how the player will experience them), while also trying to design unique challenges to disorient the player and ramp up the difficulty of solving the maze, while introducing a certain level of randomness...it boggles the mind. And every time I think I've got a good maze design to work on, I have to spend several hours building it in the map editor - so far only to ultimately decide that it's not good enough. :-\
(maze analysis)
It's pretty frustrating. But I'm still plugging away at it. Give me another week, and I'll see what I can come up with.
Friday, August 29, 2014
Progress Report
I know this is probably the longest wait I've had between releases since I started working on Ascension, but if you be just a little more patient, my next release should be more or less final, barring bug fixes and potential late-stage conceptual changes (though I hope and anticipate there won't be a lot of that). And I'm starting to get close to being ready for that release - I'm going to try real hard to put it out before next weekend. For the moment, I'd like to go over some of the changes I've been working on, and the progress I've made since my last report.
I'm just about finished hiding the secret items you have to find to get the alternate ending, which is itself pretty much finished.
I also fixed some parts in the Nastrond stage that I noticed were causing game-crashing errors (again due to the graphics file change I mentioned previously) - my apologies that the stage is apparently not playable in the latest release that's out.
And speaking of Nastrond, I'm installing a few optional shortcuts, since it's such a long, drawn out stage. Certainly, I'd like for you to experience the stage in its entirety the first time at least. But after the third or fourth time through, when you're on Hard Mode and trying for the alternate ending (for example), I don't expect you to want to sit through every bit of dialog, necessarily.
I'm also, by the way, in the process of changing around some of the dialog with Lucifer's generals, to make it a little bit more conversational and less of a lecture/text dump (since this game originally existed in the form of a written story).
I don't think I've mentioned this yet, but I made another minor graphics-related change so that now your save game file will include an indicator letting you know what difficulty level you're on (E for Easy, N for Normal, H for Hard). That should hopefully be a clever (and helpful) little addition.
Labyrinth is proving to be a real monster. I've been studying maze theory and I've come to the conclusion that my own amateur maze building skills aren't up to the task of constructing a convincingly challenging Labyrinth, so I've resorted to using a program to generate mazes which was created by maze genius Walter Pullen (here's his website - it's chock full of mazes and interesting maze-related information). Here's the prototype for the new Labyrinth maze. :p
Still, there's a lot of work involved in translating a maze into a playable game map, and then there are other considerations as well, since I want the maze to be uniquely challenging. I've utilized certain strategies to disorient the player, including reducing visibility and eliminating landmarks as much as possible. But there's still so many choices in deciding how to put this stage together that - like being lost in a maze - I can't figure out which direction to go!
But I should have that sorted out soon enough. So stay tuned for my big release, hopefully some time next week (fingers crossed!).
I'm just about finished hiding the secret items you have to find to get the alternate ending, which is itself pretty much finished.
I also fixed some parts in the Nastrond stage that I noticed were causing game-crashing errors (again due to the graphics file change I mentioned previously) - my apologies that the stage is apparently not playable in the latest release that's out.
And speaking of Nastrond, I'm installing a few optional shortcuts, since it's such a long, drawn out stage. Certainly, I'd like for you to experience the stage in its entirety the first time at least. But after the third or fourth time through, when you're on Hard Mode and trying for the alternate ending (for example), I don't expect you to want to sit through every bit of dialog, necessarily.
I'm also, by the way, in the process of changing around some of the dialog with Lucifer's generals, to make it a little bit more conversational and less of a lecture/text dump (since this game originally existed in the form of a written story).
I don't think I've mentioned this yet, but I made another minor graphics-related change so that now your save game file will include an indicator letting you know what difficulty level you're on (E for Easy, N for Normal, H for Hard). That should hopefully be a clever (and helpful) little addition.
Labyrinth is proving to be a real monster. I've been studying maze theory and I've come to the conclusion that my own amateur maze building skills aren't up to the task of constructing a convincingly challenging Labyrinth, so I've resorted to using a program to generate mazes which was created by maze genius Walter Pullen (here's his website - it's chock full of mazes and interesting maze-related information). Here's the prototype for the new Labyrinth maze. :p
Still, there's a lot of work involved in translating a maze into a playable game map, and then there are other considerations as well, since I want the maze to be uniquely challenging. I've utilized certain strategies to disorient the player, including reducing visibility and eliminating landmarks as much as possible. But there's still so many choices in deciding how to put this stage together that - like being lost in a maze - I can't figure out which direction to go!
But I should have that sorted out soon enough. So stay tuned for my big release, hopefully some time next week (fingers crossed!).
Monday, August 18, 2014
Progress Report
Since there's a lot of work to be done yet before my next release, which may not be ready for another week or more, I wanted to keep you posted on the progress I've been making, considering that I've been working literally day and night, for hours on end, to the point that my arm is going numb and my head is swimming from sitting in front of the computer too much (but I don't want to stop til it's finished!). And a lot of it is behind-the-scenes sort of stuff that you might not even notice much, as the player, and it would please me to give you an indication of just all the work that goes into putting a game together (even a relatively simple one like Ascension).
The secret alternate ending that I teased earlier is coming along very nicely. In fact, it's all but finished, and I've moved on to tackling the issue of how to unlock it. I've decided that to do so, you will need to find a hidden item in each of the stages of the game. They only appear on Hard Mode, and it will be a challenge to find/reach them, as I want the player to work for this ending (which is totally worth it). They shouldn't be impossible to find, obviously, but I want to put them in places where the player isn't very likely to stumble on them by accident. Ideally, I want the player to play through the game once and get the normal ending, before attempting the alternate ending (since the normal ending, which is the "true" ending, better concludes the story, and the secret ending is mostly just for fun). I plan on putting a tip at the end of the credits after you beat the game, informing the player of what he must do to unlock the secret ending, because, secret though it is, I do want the player to know that it's there, so he can look for it.
So anyway, while I'm hiding the secret items in each of the stages, this gives me a great opportunity to revisit each of those stages now that the game is in a state of relative completion from start to finish, and evaluate how I feel about them. I can polish them up, maybe add or extend a few things here or there, and complete things that maybe I rushed when I was trying to get the stage posted that week. Obviously, overhauling Labyrinth is going to be part of this process. I went back to Limbo (the first stage, you might remember), and completely recoded the gremlins, because the way I had done it before was kind of clunky, and OCD as I am, I wanted to polish it up a bit. It was a headache keeping track of all the switches and variables and whatnot, and as the player you shouldn't notice a difference beyond a minor change in the way the gremlins move, but as the developer I feel a lot better knowing the code is a bit more tidy. I seem to have the stage working nicely again now, which is a great relief, but certainly after I post the next release you'll have to play it and let me know if you encounter any bugs.
One other thing I've worked on a bit already is an additional challenge to the Chaos stage (as if it wasn't already tough enough!). It involves maneuvering your avatar in free fall to land on a moving platform. And it was actually an idea given by one of my testers. The first time I tried it out, I came to the conclusion that it would be too difficult to implement, and not worth the effort. But I recently thought of a different approach, and seem to have it working now. But I must stress this one caveat: I am working in RPG Maker, not Platformer Maker, and the "collision physics" are spotty at best, so I wouldn't expect too much precision, and for that reason, it will only be a minor part of the stage.
It has certainly been exciting bringing my story to life, and it has also been an immensely fruitful experience, working out all the challenges I have come across, especially in the sense of creating various "arcade"-like stages that don't necessarily run the way a game made in RPG Maker would be expected to run. I look forward to applying that experience when I finally get back to working on Dragonfaith (oh yes, I haven't given up on it). Although I'll probably need a bit of a break after Ascension reaches a stage of more or less completion. And it is towards that end I work, because I don't want this project to continue on indefinitely. I posted the first release at the beginning of June, and so I've been working on it for about two and a half months now. Let's see if I can't have it finished (at least in beta form) by the end of this month!
I better get back to work if that's to happen!
The secret alternate ending that I teased earlier is coming along very nicely. In fact, it's all but finished, and I've moved on to tackling the issue of how to unlock it. I've decided that to do so, you will need to find a hidden item in each of the stages of the game. They only appear on Hard Mode, and it will be a challenge to find/reach them, as I want the player to work for this ending (which is totally worth it). They shouldn't be impossible to find, obviously, but I want to put them in places where the player isn't very likely to stumble on them by accident. Ideally, I want the player to play through the game once and get the normal ending, before attempting the alternate ending (since the normal ending, which is the "true" ending, better concludes the story, and the secret ending is mostly just for fun). I plan on putting a tip at the end of the credits after you beat the game, informing the player of what he must do to unlock the secret ending, because, secret though it is, I do want the player to know that it's there, so he can look for it.
So anyway, while I'm hiding the secret items in each of the stages, this gives me a great opportunity to revisit each of those stages now that the game is in a state of relative completion from start to finish, and evaluate how I feel about them. I can polish them up, maybe add or extend a few things here or there, and complete things that maybe I rushed when I was trying to get the stage posted that week. Obviously, overhauling Labyrinth is going to be part of this process. I went back to Limbo (the first stage, you might remember), and completely recoded the gremlins, because the way I had done it before was kind of clunky, and OCD as I am, I wanted to polish it up a bit. It was a headache keeping track of all the switches and variables and whatnot, and as the player you shouldn't notice a difference beyond a minor change in the way the gremlins move, but as the developer I feel a lot better knowing the code is a bit more tidy. I seem to have the stage working nicely again now, which is a great relief, but certainly after I post the next release you'll have to play it and let me know if you encounter any bugs.
One other thing I've worked on a bit already is an additional challenge to the Chaos stage (as if it wasn't already tough enough!). It involves maneuvering your avatar in free fall to land on a moving platform. And it was actually an idea given by one of my testers. The first time I tried it out, I came to the conclusion that it would be too difficult to implement, and not worth the effort. But I recently thought of a different approach, and seem to have it working now. But I must stress this one caveat: I am working in RPG Maker, not Platformer Maker, and the "collision physics" are spotty at best, so I wouldn't expect too much precision, and for that reason, it will only be a minor part of the stage.
It has certainly been exciting bringing my story to life, and it has also been an immensely fruitful experience, working out all the challenges I have come across, especially in the sense of creating various "arcade"-like stages that don't necessarily run the way a game made in RPG Maker would be expected to run. I look forward to applying that experience when I finally get back to working on Dragonfaith (oh yes, I haven't given up on it). Although I'll probably need a bit of a break after Ascension reaches a stage of more or less completion. And it is towards that end I work, because I don't want this project to continue on indefinitely. I posted the first release at the beginning of June, and so I've been working on it for about two and a half months now. Let's see if I can't have it finished (at least in beta form) by the end of this month!
I better get back to work if that's to happen!
Thursday, August 14, 2014
Ascension - Stage 11
Lest you think I've been slacking off, due to this release being a couple days late, I've actually been hard at work day and night. There's a lot to do to get the end of the game all together, and it seems less logical to release these last bits separately, so that one week you have the final stage, and then the next week you get to see the credits, or what have you.
Non-endgame updates in this release:
I made some minor adjustments to the previous stage (Erebus), because the gargoyles on Hard Mode weren't giving the player very much freedom of movement.
I feared that Labyrinth might be too much of a challenge, but according to one of my testers, it may actually be too easy. The version that I've released didn't fully realize my (somewhat more complex) plans, so I may have to actually go back and rebuild the maze to make it even more unforgiving. I don't begrudge the opportunity to do this, just the work that's going to have to go into it. :p Look for that in an upcoming release.
I also changed some filenames around for some of the graphics, for economy of content (you can fit eight full character sprites or faces in a single file). I tried to fix all the parts in the game that use them, but if you come to a point where the game crashes (with an error that says such and such a file can't be found), let me know; it's an easy fix.
A little rant on cutscene choreography:
I have a lot of respect for the people who put together those half-hour long cutscenes at the end of classic RPGs. Like, I had this problem more while working on Dragonfaith. Ascension has a lot of long text-heavy passages, since it's inspired by a written story idea, but it doesn't have a lot of complex, choreographed cutscenes with different characters moving all around the screen. I wanted something a little special at the end, to reward the player for playing through the game, but this is a short (I can't call it simple) cutscene that will probably last all of a couple minutes when it's said and done, but I'm moving thirteen characters around at once, and getting the timing and positioning down is a challenge. Add to that the fact that you (as the developer) have to sit there and watch through the whole thing multiple times as you make little tweaks to the stuff towards the end, just to get it right... Yeah, I think I complained about this when I was working on Dragonfaith. It's daunting.
Notes on the ending:
The final stage is a breath of relief after 10 stages of hellish terrain. That having been said, there is still a challenge you must surmount, although it's more of a sit-back-in-your-chair-and-explore sort of challenge than the edge-of-your-seat-thrill-ride kind of challenge that is more typical of the stages in Hell. Once you beat it, the ending is not extensive, and may or may not be along the lines of what you're expecting, but I hope that it is in keeping with the theme of the game/story, and there are a couple of extra fun bits at the end.
To keep everything straight - and this is something I imagine the player can discover on their own, but for the sake of letting my testers know what's in the game to test - let me explain the different variations of the ending. If you play the game on Easy Mode, you won't be able to access the final stage - you just get the basic credits without the bestiary I put lots of work into. Normal Mode gets you access to all playable content (minus the secret ending I have planned but haven't created yet), and the "true" ending, complete with the bestiary. The Hard Mode ending plays out exactly the same as Normal Mode, except there's an extra scene at the end (which I totally think is worth challenging yourself to get).
You might notice that the endings are additive. The harder difficulty level you pick, the more content you get, and there is nothing worthwhile on an easier difficulty that is not available on the harder difficulty levels. The Normal Mode gets you a perfectly adequate ending (though you may feel it's a bit abrupt - that's intentional), so that you don't have to strain yourself to beat the game on Hard, but at the same time, I think the extra scene is worth it. Plus, I think I might make the secret ending available only on Hard Mode, because I want it to be a challenge.
But all this can change in the future, if I change my mind, or get some negative feedback on how it's currently all laid out. In the meantime, you have only to play it and let me know what you think!
14/08/14: Ascension - Stage 11b (5.71 MB) [edit: new release available, check sidebar for info]
Edit: Remember when I mentioned filenames and crashes above? Well, in a true facepalm moment, I just discovered that I forgot to update each one of the gargoyles in Erebus. So, if you already downloaded Stage 11, you'll want to replace it with 11b if you don't want the game to crash every time a gargoyle catches you in Erebus...
Non-endgame updates in this release:
I made some minor adjustments to the previous stage (Erebus), because the gargoyles on Hard Mode weren't giving the player very much freedom of movement.
I feared that Labyrinth might be too much of a challenge, but according to one of my testers, it may actually be too easy. The version that I've released didn't fully realize my (somewhat more complex) plans, so I may have to actually go back and rebuild the maze to make it even more unforgiving. I don't begrudge the opportunity to do this, just the work that's going to have to go into it. :p Look for that in an upcoming release.
I also changed some filenames around for some of the graphics, for economy of content (you can fit eight full character sprites or faces in a single file). I tried to fix all the parts in the game that use them, but if you come to a point where the game crashes (with an error that says such and such a file can't be found), let me know; it's an easy fix.
A little rant on cutscene choreography:
I have a lot of respect for the people who put together those half-hour long cutscenes at the end of classic RPGs. Like, I had this problem more while working on Dragonfaith. Ascension has a lot of long text-heavy passages, since it's inspired by a written story idea, but it doesn't have a lot of complex, choreographed cutscenes with different characters moving all around the screen. I wanted something a little special at the end, to reward the player for playing through the game, but this is a short (I can't call it simple) cutscene that will probably last all of a couple minutes when it's said and done, but I'm moving thirteen characters around at once, and getting the timing and positioning down is a challenge. Add to that the fact that you (as the developer) have to sit there and watch through the whole thing multiple times as you make little tweaks to the stuff towards the end, just to get it right... Yeah, I think I complained about this when I was working on Dragonfaith. It's daunting.
Notes on the ending:
The final stage is a breath of relief after 10 stages of hellish terrain. That having been said, there is still a challenge you must surmount, although it's more of a sit-back-in-your-chair-and-explore sort of challenge than the edge-of-your-seat-thrill-ride kind of challenge that is more typical of the stages in Hell. Once you beat it, the ending is not extensive, and may or may not be along the lines of what you're expecting, but I hope that it is in keeping with the theme of the game/story, and there are a couple of extra fun bits at the end.
To keep everything straight - and this is something I imagine the player can discover on their own, but for the sake of letting my testers know what's in the game to test - let me explain the different variations of the ending. If you play the game on Easy Mode, you won't be able to access the final stage - you just get the basic credits without the bestiary I put lots of work into. Normal Mode gets you access to all playable content (minus the secret ending I have planned but haven't created yet), and the "true" ending, complete with the bestiary. The Hard Mode ending plays out exactly the same as Normal Mode, except there's an extra scene at the end (which I totally think is worth challenging yourself to get).
You might notice that the endings are additive. The harder difficulty level you pick, the more content you get, and there is nothing worthwhile on an easier difficulty that is not available on the harder difficulty levels. The Normal Mode gets you a perfectly adequate ending (though you may feel it's a bit abrupt - that's intentional), so that you don't have to strain yourself to beat the game on Hard, but at the same time, I think the extra scene is worth it. Plus, I think I might make the secret ending available only on Hard Mode, because I want it to be a challenge.
But all this can change in the future, if I change my mind, or get some negative feedback on how it's currently all laid out. In the meantime, you have only to play it and let me know what you think!
14/08/14: Ascension - Stage 11b (5.71 MB) [edit: new release available, check sidebar for info]
Edit: Remember when I mentioned filenames and crashes above? Well, in a true facepalm moment, I just discovered that I forgot to update each one of the gargoyles in Erebus. So, if you already downloaded Stage 11, you'll want to replace it with 11b if you don't want the game to crash every time a gargoyle catches you in Erebus...
Thursday, August 7, 2014
Ascension - Stage 10
This release is a couple days late, despite being a relatively short stage. That's only because I was out of town and away from the computer for four days this past week. Although this is technically the last stage in Hell, I'm going to add a final stage in Purgatory - I probably said more than enough about that in the post for my last release. So this isn't the end, yet. But we're getting real close!
The final challenge in Hell is basically a determination of whether your soul is pure enough for Ascension. I've considered making the outcome dependent on actions you take during the game, but ultimately - and especially if you're not sure which decisions contribute to the purity of your soul - it might be a little too frustrating to make it to the end of the game only to be told, "you lose".
On the other hand, I want to reward players for not taking it too easy on themselves, and so this will, in fact, be the end of the game if you're playing on Easy Mode. To access the final level (and escape Hell), you'll have to defeat the game on Normal or Hard Mode. Otherwise, you just haven't suffered enough. :-p
For that reason, you can access (for the first time in this game!) the credits in this release, if you're playing on Easy Mode. They may not be in their final form yet, and I'm planning something extra in the form of a fun "cast" list a la Doom 2, but it's a pretty exciting start, I think.
14/08/07: Ascension - Stage 10 (5.86 MB) [edit: new release available, check sidebar for info]
The final challenge in Hell is basically a determination of whether your soul is pure enough for Ascension. I've considered making the outcome dependent on actions you take during the game, but ultimately - and especially if you're not sure which decisions contribute to the purity of your soul - it might be a little too frustrating to make it to the end of the game only to be told, "you lose".
On the other hand, I want to reward players for not taking it too easy on themselves, and so this will, in fact, be the end of the game if you're playing on Easy Mode. To access the final level (and escape Hell), you'll have to defeat the game on Normal or Hard Mode. Otherwise, you just haven't suffered enough. :-p
For that reason, you can access (for the first time in this game!) the credits in this release, if you're playing on Easy Mode. They may not be in their final form yet, and I'm planning something extra in the form of a fun "cast" list a la Doom 2, but it's a pretty exciting start, I think.
14/08/07: Ascension - Stage 10 (5.86 MB) [edit: new release available, check sidebar for info]
Wednesday, July 30, 2014
Ascension - Stage 9
I'm pretty much sick to death of mazes at this point, as I am sure you will be too by the time you finish this next stage. I'm worried that it's maybe a little bit too much, but then, that was kind of the point. I wanted to make a maze worthy of the name "Labyrinth", and one in which you could imagine a soul getting lost and wandering aimlessly for eons. At any rate, let me know what you think of it.
And I'm off to the next stage, which is the last one - officially. I hope you're getting excited as the story is nearing its conclusion! But I will say that I am definitely planning on putting something together for a kind of "epilogue", which will be at least as extensive as to be considered a stage of its own.
My original story idea was to mirror The Divine Comedy by Dante Alighieri, in the sense of composing a trilogy - one section each for Hell, Purgatory, and Heaven. But I have much less to say about Purgatory and Heaven than I do about Hell, and much of the Heaven stuff is prequel-ish, which I have mostly incorporated into the back stories of Lucifer's Generals already in this game.
And as for Purgatory, it actually made it into my original concept as one of the "13 Stages of Hell" (there are not 13 stages in my game because a couple of the stages were either combined or not playable), instead of a whole premise of its own. So I think I will just implement it as the real last stage, and then (spoiler) give Heaven a cameo in the epilogue.
But that's all to come. For now, enjoy an eternity of wandering down endless corridors!
14/07/30: Ascension - Stage 9 (5.49 MB) [edit: new release available, check sidebar for info]
And I'm off to the next stage, which is the last one - officially. I hope you're getting excited as the story is nearing its conclusion! But I will say that I am definitely planning on putting something together for a kind of "epilogue", which will be at least as extensive as to be considered a stage of its own.
My original story idea was to mirror The Divine Comedy by Dante Alighieri, in the sense of composing a trilogy - one section each for Hell, Purgatory, and Heaven. But I have much less to say about Purgatory and Heaven than I do about Hell, and much of the Heaven stuff is prequel-ish, which I have mostly incorporated into the back stories of Lucifer's Generals already in this game.
And as for Purgatory, it actually made it into my original concept as one of the "13 Stages of Hell" (there are not 13 stages in my game because a couple of the stages were either combined or not playable), instead of a whole premise of its own. So I think I will just implement it as the real last stage, and then (spoiler) give Heaven a cameo in the epilogue.
But that's all to come. For now, enjoy an eternity of wandering down endless corridors!
14/07/30: Ascension - Stage 9 (5.49 MB) [edit: new release available, check sidebar for info]
Tuesday, July 22, 2014
Ascension - Stage 8
Stage 8 turned out to be something of a colossus. Of course, I say that as the developer, and not as a player. Playing through it, you won't notice it to be particularly long or extravagant, although I do hope the atmosphere engrosses you.
I had similar trouble with the mapping as I had with Stage 3, Har Megido, although where in that case the map came together without too much fuss, I had much more trouble piecing this one together. I drew up innumerable variations on the placement of the geography, and began work on probably about ten different versions in the actual mapper itself, before things finally started falling in to place. I'm happy to say that I am very pleased with the end result, however.
I don't think I've ever had a map with this many events, though - between the bridge, and the animated tiles, and everything else on top of that. I actually had to split it in half (although you shouldn't notice that while playing), to get the bridge theatrics to sync with the passabilities of the appropriate tiles. Though it didn't really help much with the massive eventing. I hope the game doesn't lag during this stage.
I'm actually surprised it all came together in time for my weekly deadline, but I did put a lot of effort into getting it finished. The next stage was supposed to be the super difficult one to design, but now, coming off this last stage, I'm hoping it proves to be easier than I've been expecting. Only time will tell, and if I have to take a couple extra days to either work on it or take a break, so be it. It'll be worth it in the end.
And speaking of which, this project is beginning to draw near to its end. Which I'm very excited about. There are only two more stages, although I have plans for something special after that, so we'll see how that goes.
I almost forgot! I made an exciting modification to the game in this new release. Just as soon as you've had a chance to visit Nexus (I hope?), I've already nixed it. In its place, I've implemented my Paint drawing of the map of Dis (The Underworld), which functions as a trail marker and punctuates your playing experience between each stage. It also gives you a proper introduction to the names of each of the stages, as well as a visual guide to the geography of Hell (as I have envisioned it). It's fairly crude, and not as colorful as I'd like, but I'm otherwise very excited about being able to include it in the game, and I like very much how it fits in, both in the regular game itself, and as the device now intuitively powering the stage select function. Give it a try! (Just type "zharth", no caps, at the name select screen).
14/07/22: Ascension - Stage 8 (4.97 MB) [edit: new release available, check sidebar for info]
I had similar trouble with the mapping as I had with Stage 3, Har Megido, although where in that case the map came together without too much fuss, I had much more trouble piecing this one together. I drew up innumerable variations on the placement of the geography, and began work on probably about ten different versions in the actual mapper itself, before things finally started falling in to place. I'm happy to say that I am very pleased with the end result, however.
I don't think I've ever had a map with this many events, though - between the bridge, and the animated tiles, and everything else on top of that. I actually had to split it in half (although you shouldn't notice that while playing), to get the bridge theatrics to sync with the passabilities of the appropriate tiles. Though it didn't really help much with the massive eventing. I hope the game doesn't lag during this stage.
I'm actually surprised it all came together in time for my weekly deadline, but I did put a lot of effort into getting it finished. The next stage was supposed to be the super difficult one to design, but now, coming off this last stage, I'm hoping it proves to be easier than I've been expecting. Only time will tell, and if I have to take a couple extra days to either work on it or take a break, so be it. It'll be worth it in the end.
And speaking of which, this project is beginning to draw near to its end. Which I'm very excited about. There are only two more stages, although I have plans for something special after that, so we'll see how that goes.
I almost forgot! I made an exciting modification to the game in this new release. Just as soon as you've had a chance to visit Nexus (I hope?), I've already nixed it. In its place, I've implemented my Paint drawing of the map of Dis (The Underworld), which functions as a trail marker and punctuates your playing experience between each stage. It also gives you a proper introduction to the names of each of the stages, as well as a visual guide to the geography of Hell (as I have envisioned it). It's fairly crude, and not as colorful as I'd like, but I'm otherwise very excited about being able to include it in the game, and I like very much how it fits in, both in the regular game itself, and as the device now intuitively powering the stage select function. Give it a try! (Just type "zharth", no caps, at the name select screen).
14/07/22: Ascension - Stage 8 (4.97 MB) [edit: new release available, check sidebar for info]
Tuesday, July 15, 2014
Ascension - Stage 7
Stage 7 has shaped up nicely, and I am very excited to show it off. This is more of a domestic stage, like Pandaemonium - albeit with more chances to slip up - that demonstrates how some of the damned like to pass their time in Hell. Up next will be another adventure stage, and then there are only two more after that, so development is proceeding at a brisk pace!
I've made a couple small but significant changes to the rest of the game in this release. First, I've modified the gameplay slightly in the last stage - Chaos. Now, instead of the black wards acting as "base", so that the bats will ignore you only so long as you stand on them, I've changed it so that standing on them actually gives you temporary invincibility (or invisibility from the bats, at least), that wears off in a few seconds, even if you step off the ward. I think it makes gameplay just a little bit easier on what was proving to be a pretty challenging stage.
The other change I made is purely cosmetic, but I hope that it will improve clarity. You may have noticed that, although you don't technically have a "party" (RPG word for "team") in this game, extra characters are displayed in your save game file, depending on the stage your game is saved at. I did this to help the player remember where in the game they had left off when choosing to load a saved game. Up until now, I had used characters from the previous stage (since the game only saves between stages), but I thought it made more conceptual sense if the game file featured characters from the stage you're about to play, since you only really see them when you're loading the game. I hope that it's more logical now.
Apart from that, I'm in the process of working out some kinks on the way this game displays dialogue choices. From the start, I had installed a script to allow dynamic choice options, which you may remember from your first encounter with the Angel of Judgment in Limbo. That was actually inspired by the dialogue style in Realms of the Haunting (one of the best horror games ever released for PC, now available on Steam for five bucks!). I was planning to implement it more in later conversations, but I ended up deciding not to go in that direction, after all, and so I just got rid of it completely. But when I nixed the script, I had to change the way I was displaying choices, and now a couple choices that aren't attached to text boxes awkwardly appear on the side of the screen, instead of the center. I haven't decided what I'm going to do about that yet.
But otherwise, everything seems to be running smoothly. So, no more waiting - try out the latest stage!
14/07/15 Ascension - Stage 7 (4.15 MB) [edit: new release available, check sidebar for info]
I've made a couple small but significant changes to the rest of the game in this release. First, I've modified the gameplay slightly in the last stage - Chaos. Now, instead of the black wards acting as "base", so that the bats will ignore you only so long as you stand on them, I've changed it so that standing on them actually gives you temporary invincibility (or invisibility from the bats, at least), that wears off in a few seconds, even if you step off the ward. I think it makes gameplay just a little bit easier on what was proving to be a pretty challenging stage.
The other change I made is purely cosmetic, but I hope that it will improve clarity. You may have noticed that, although you don't technically have a "party" (RPG word for "team") in this game, extra characters are displayed in your save game file, depending on the stage your game is saved at. I did this to help the player remember where in the game they had left off when choosing to load a saved game. Up until now, I had used characters from the previous stage (since the game only saves between stages), but I thought it made more conceptual sense if the game file featured characters from the stage you're about to play, since you only really see them when you're loading the game. I hope that it's more logical now.
Apart from that, I'm in the process of working out some kinks on the way this game displays dialogue choices. From the start, I had installed a script to allow dynamic choice options, which you may remember from your first encounter with the Angel of Judgment in Limbo. That was actually inspired by the dialogue style in Realms of the Haunting (one of the best horror games ever released for PC, now available on Steam for five bucks!). I was planning to implement it more in later conversations, but I ended up deciding not to go in that direction, after all, and so I just got rid of it completely. But when I nixed the script, I had to change the way I was displaying choices, and now a couple choices that aren't attached to text boxes awkwardly appear on the side of the screen, instead of the center. I haven't decided what I'm going to do about that yet.
But otherwise, everything seems to be running smoothly. So, no more waiting - try out the latest stage!
14/07/15 Ascension - Stage 7 (4.15 MB) [edit: new release available, check sidebar for info]
Wednesday, July 9, 2014
Ascension - Stage 6
As promised, this is a more straightforward stage, and I feel it offers welcome diversity when compared to the last stage. It's pretty short, but that's not to say that it's easy. In fact, I've found it to be a bit challenging. I've made some adjustments to pull back the difficulty, and of course there are variations on each of the difficulty levels, but I should like to have some feedback on how tough you think this stage is. On the other hand, we're more than halfway through the game, so you shouldn't expect it to be a walk in the park.
The next stage will be another fairly elaborate one, so I should get to work on it as soon as possible. By this point it should be obvious (assuming you've actually been following along) that replaying the game from the start with each new release is a bit tedious. Although I do sometimes make adjustments to earlier stages that you might consider worth experiencing, it's probably at least as true that you'd want to dive right in to the latest stage, having already experienced more or less everything up to that point.
Well, I'm happy to report that I've finally received feedback from some testers that have beaten Stage 2 (remember Stage 2? Yeah, neither do I, it was so long ago :p). So, as promised, I will reveal to you a [rather useful] secret I've programmed into the game. At the beginning, during the name select sequence, if you enter the name "zharth" (no caps), it will take you to a special stage select zone, where you can warp directly to the beginning of any of the stages that have been completed!
I call it "Nexus", for obvious reasons. It's pure coincidence that it has the same decor as the latest stage I'm releasing - it's actually been that way since several stages ago. I might change it in the future to make it a bit more unique, but that's beside the point. Use it to warp to any stage of your choosing, for testing purposes. And don't forget to try the game on different difficulty levels if you're feeling adventurous!
14/07/09 Ascension - Stage 6 (4.02 MB) [edit: new release available, check sidebar for info]
The next stage will be another fairly elaborate one, so I should get to work on it as soon as possible. By this point it should be obvious (assuming you've actually been following along) that replaying the game from the start with each new release is a bit tedious. Although I do sometimes make adjustments to earlier stages that you might consider worth experiencing, it's probably at least as true that you'd want to dive right in to the latest stage, having already experienced more or less everything up to that point.
Well, I'm happy to report that I've finally received feedback from some testers that have beaten Stage 2 (remember Stage 2? Yeah, neither do I, it was so long ago :p). So, as promised, I will reveal to you a [rather useful] secret I've programmed into the game. At the beginning, during the name select sequence, if you enter the name "zharth" (no caps), it will take you to a special stage select zone, where you can warp directly to the beginning of any of the stages that have been completed!
I call it "Nexus", for obvious reasons. It's pure coincidence that it has the same decor as the latest stage I'm releasing - it's actually been that way since several stages ago. I might change it in the future to make it a bit more unique, but that's beside the point. Use it to warp to any stage of your choosing, for testing purposes. And don't forget to try the game on different difficulty levels if you're feeling adventurous!
14/07/09 Ascension - Stage 6 (4.02 MB) [edit: new release available, check sidebar for info]
Wednesday, July 2, 2014
Ascension - Stage 5
This was a pretty elaborate stage to develop, but one thing I've found is that having a clear plan for what you want to accomplish helps the work go a lot smoother. It's easier to be motivated and easier to be inspired, when there's a challenge ahead of you that you can confront, instead of wandering as if in the middle of a vast sea of possibilities, without a clear idea of what you're trying to create.
Anyway, this is another exposition-heavy stage, but it has more of a clear progression, and there's a lot going on. You also get introduced to a bunch more of Lucifer's generals, as in the last stage, leaving only a few left to encounter later in the game. The next stage after this one should be fun, being more gameplay-based like some of the earlier stages. But for now, I hope you'll find this stage very interesting. It's a long one!
14/07/02 Ascension - Stage 5 (3.93 MB) [edit: new release available, check sidebar for info]
Anyway, this is another exposition-heavy stage, but it has more of a clear progression, and there's a lot going on. You also get introduced to a bunch more of Lucifer's generals, as in the last stage, leaving only a few left to encounter later in the game. The next stage after this one should be fun, being more gameplay-based like some of the earlier stages. But for now, I hope you'll find this stage very interesting. It's a long one!
14/07/02 Ascension - Stage 5 (3.93 MB) [edit: new release available, check sidebar for info]
Wednesday, June 25, 2014
Ascension - Stage 4
In addition to releasing the next stage, since my testers have been having a little trouble beating Stage 2, I've made some adjustments in this release to hopefully make the playing experience a little less frustrating. There are a couple of hints as to how to beat the challenge in Stage 2, including a friendly spirit guide I've placed in the catacombs.
I've also come to the decision that the whole "one slip game over" thing is too unforgiving - especially given that progress can be saved only between stages, and you currently have to skip through all the text to play the stage again. I originally wanted to avoid giving the player "spare lives", due to the unique nature of my story (the protagonist is already dead) - and have already gone out of my way to make the game over situations not those in which you "die", but that your soul suffers some eternal fate that prevents you from journeying further through the narrative.
But, I figure this is probably one of those cases where the player would be willing to "suspend disbelief" for the sake of improving the gameplay, and making the game more of a challenge and less of a frustration. To that end, I've also added in difficulty levels, for better or worse. The gameplay challenge is ramped up in Hard Mode, and eased down in Easy Mode, and you get more lives (I'm going to call them "spirits") in Easy Mode. I want the game to be a challenge for seasoned players, but I don't want it to be impossible for novices, either, and I think having difficulty levels is the best way to handle that. I'll probably include some kind of reward or something for playing it on the harder difficulties, but I haven't decided on what that will be yet.
As for Stage 4, it's a bit different than the previous stages, with more of an emphasis on discovery, than dodging obstacles. But I'm still very excited about it - in this stage you'll be introduced to the first of Hell's 13 Generals! So I hope you'll be able to actually experience it. As an incentive, I'll tell you about a neat secret I added into the game, but only after you've beaten Stage 2! Go on then, give it a try. And I'll get started working on Stage 5, which is going to be an intense one.
14/06/25 Ascension - Stage 4 (3.61 MB) [edit: new release available, check sidebar for info]
I've also come to the decision that the whole "one slip game over" thing is too unforgiving - especially given that progress can be saved only between stages, and you currently have to skip through all the text to play the stage again. I originally wanted to avoid giving the player "spare lives", due to the unique nature of my story (the protagonist is already dead) - and have already gone out of my way to make the game over situations not those in which you "die", but that your soul suffers some eternal fate that prevents you from journeying further through the narrative.
But, I figure this is probably one of those cases where the player would be willing to "suspend disbelief" for the sake of improving the gameplay, and making the game more of a challenge and less of a frustration. To that end, I've also added in difficulty levels, for better or worse. The gameplay challenge is ramped up in Hard Mode, and eased down in Easy Mode, and you get more lives (I'm going to call them "spirits") in Easy Mode. I want the game to be a challenge for seasoned players, but I don't want it to be impossible for novices, either, and I think having difficulty levels is the best way to handle that. I'll probably include some kind of reward or something for playing it on the harder difficulties, but I haven't decided on what that will be yet.
As for Stage 4, it's a bit different than the previous stages, with more of an emphasis on discovery, than dodging obstacles. But I'm still very excited about it - in this stage you'll be introduced to the first of Hell's 13 Generals! So I hope you'll be able to actually experience it. As an incentive, I'll tell you about a neat secret I added into the game, but only after you've beaten Stage 2! Go on then, give it a try. And I'll get started working on Stage 5, which is going to be an intense one.
14/06/25 Ascension - Stage 4 (3.61 MB) [edit: new release available, check sidebar for info]
Tuesday, June 17, 2014
Ascension - Stage 3
Progress is continuing steadily on Ascension, and I now have the third stage ready to be tested. I have not yet received feedback from anyone who actually beat Stage 2 yet. I made a minor modification in this latest release to hopefully make it a little bit less frustrating, but I will say this: it's meant to be a challenge. Not a challenge as in impossible to beat (it's actually simple, but only if you know what you have to do to advance), but a challenge in the sense that you might actually have to use your head. Just remember, this is Hell. Hell doesn't want you to succeed. Hell wants you to die a thousand painful deaths and then end up interminably falling into a bottomless hole for the rest of eternity.
Anyway, Stage 3 is a bit more straightforward. There isn't much to it in the original story outline, but I'm pretty happy with what I've worked it into. It's actually a bit challenging, playing through it myself (that's the first time I can say that on this game), so I might dial back the Reaper just a tad in future installments - but then, a lot of that is ultimately left up to simple chance. In any case, I would appreciate feedback! And I've already made headways on the next stage (Stage 4), so keep your eyes open for that!
14/06/17 Ascension - Stage 3 (3.49 MB) [edit: new release available, check sidebar for info]
Anyway, Stage 3 is a bit more straightforward. There isn't much to it in the original story outline, but I'm pretty happy with what I've worked it into. It's actually a bit challenging, playing through it myself (that's the first time I can say that on this game), so I might dial back the Reaper just a tad in future installments - but then, a lot of that is ultimately left up to simple chance. In any case, I would appreciate feedback! And I've already made headways on the next stage (Stage 4), so keep your eyes open for that!
14/06/17 Ascension - Stage 3 (3.49 MB) [edit: new release available, check sidebar for info]
Tuesday, June 10, 2014
Ascension - Stage 2
Stage 2 of my new horror game Ascension is now ready to be tested! Stage 1 was a very short, introductory stage. Stage 2 is a good deal more complex (although I don't think any of these stages is ultimately going to be very long). The stakes have also been raised. There was nothing you could do in Stage 1 to fail, but Stage 2 features the first place in the game where you can get a Game Over (I hope you like my modified Game Over screen!). It also features a maze! And what I hope will be a terrifying surprise or two. Give it a try, and send feedback my way. My recommendations for playing: turn the lights down, and the volume up!
14/06/10 Ascension - Stage 2 (2.82 MB) [edit: new release available, check sidebar for info]
14/06/10 Ascension - Stage 2 (2.82 MB) [edit: new release available, check sidebar for info]
Sunday, June 8, 2014
Parallel Processing (and other Events)
tl;dr - scroll down to the bottom of this post for a summary of the important discoveries, if you don't have the time or the patience to read the whole thing.
I think I've discussed the basics of eventing in a previous post, but in case you've forgotten, events are a powerful tool in RPG Maker that govern everything from NPCs, player transfers (the mechanism by which the player moves from one map to the next), treasure chests, all the way to elaborately choreographed cutscenes. When you consider the vast majority of functions that are available to the developer when setting up an event (which becomes obvious the first time you create one and see the pages of commands to choose from), you realize just how versatile they can be.
There are five different event "triggers" - ways in which events can be activated. The first, "Action Button" mode, requires the player to walk up to the event and activate it by pressing the action button. This is pretty straightforward, and is useful for events like opening treasure chests, initiating dialogue when the player interacts with an NPC, etc. The next trigger is "Player Touch" which activates whenever the player comes into contact with or walks over the tile where the event is located. This is useful for position-based actions, like map transfers, and also to set off things like cutscenes when the player steps on a particular tile. The third trigger is "Event Touch" which works very much like Player Touch, but also activates when the event runs into the player - which could be useful for things like roaming enemies that initiate battle when they catch you, or rolling boulders that hurt you when they hit you - things like that.
The last two triggers are "Autorun" and "Parallel Process", and are two different ways of making events run automatically without the player tripping them off in some way. The difference between them is that Autorun events, like most events, interrupt the gameplay until the event is completed. This is one of the best ways to run cutscenes that you want to start automatically upon loading of a map, or upon meeting a certain condition (such as a switch being activated by some other event). Parallel Processes, on the other hand, are unique in that they run "in the background", or in parallel to everything else going on. So if you want to, say, check the status of a countdown timer, for example, without interrupting the player, you can use a Parallel Process event. There are many other useful applications for this trigger, that are easy to figure out with a little imagination.
Another thing that is unique about these automatic events - those marked with the Autorun and Parallel Process triggers - is that, instead of running through once and thus completing the event (which may be run again only if the player trips the trigger again - unless you manipulate your event so that it changes after the first run-through, usually by ticking a self-switch, to prevent it from running again, or to cause it to run differently), these automatic events will run through repeatedly and indefinitely - until some developer-defined condition is met (such as ticking a self-switch, or telling the event to erase itself) that will shut it off. Normally, this is not a terribly tricky situation to handle, as long as you understand what's going on, but I've found in my own experience that some confusion arises when you're dealing with events that involve transfers to other maps.
You see, the way events are set up is that they are placed on specific maps. Even the ones that do not have graphics (like NPCs, treasure chests, etc.), or whose triggers do not depend on being positioned on certain tiles, and are indeed invisible, still need to be placed on a tile on a map somewhere - and will only activate on that map. There are Common Events that run throughout the game, no matter what map the player is on, but they work a little bit differently, and in any case, there are usually few event functions that you would want occurring everywhere in the game, and not just on a specific map. So, it may be clear that an Autorun or Parallel Process event will run repeatedly until such conditions are met as to deactivate it, within the map that it appears on, but what happens when such an event transfers the player to another map?
Does it stop running then, because the event is no longer existent on the map the player has currently loaded? And if there are other commands after the transfer, are they performed before the event completes itself? If so, what happens if such an event transfers the player to one map, and then before finishing, transfers the player to yet another map? Or back to the first map? How are the loading of the events on these other maps treated? What if there is another Autorun or Parallel Process event on one of those maps? If the first event transfers a player away and then back to the first map, does the event that's running restart as it is being loaded anew, or keep running from whatever point it was at because it was never completed?
I haven't found any guides or tutorials that are sufficiently clear on any of these points. And for a while, I've just been taking it all for granted, using these events intuitively to the extent that they do what I want. But I recently came across a situation where things weren't happening the way I expected them to (leading me to quite a bit of confusion until I figured out where the problem was occurring), and I realized I could use a bit of a clearer understanding of what's going on with these events. So, it was time to put on my scientist's cap, and apply the scientific method to the problem, and do some trial-and-error experiments! And, of course, I figured I'd share my results in case anyone else ever comes upon these same problems, and is curious to acquire a bit of a more fine-tuned understanding of how these events work. (Tip: if you don't want to read through all the minutiae, you're more than welcome to skip down to the tl;dr at the bottom, where I summarize my findings).
Here's what I've learned:
First of all, it's worth noting that if you have NPCs or other events that have Autonomous Movement (e.g., NPCs that wander around on their own, or enemies that automatically approach the player), then even though the running of an event (any kind, except for Parallel Processes) will stop the player's actions until the event is completed, other events with Autonomous Movement will continue to move. This is true also while there is a text window on the screen, and the game is waiting for the player to press a button to dismiss it. However, if any of these other events have the "Event Touch" trigger, they will not trigger even if they touch the player as long as another (non-Parallel Process) event is running.
Similarly, if you forcibly move the player (via Set Move Route) within an event such that it would ordinarily trigger a different, Player Touch event, that Player Touch event will not be triggered so long as the first event is running. Basically, this all confirms that, with the exception of Parallel Process events, only one event can run at a given time, and whichever event is run first will run to completion before any other (non-PP) event can be triggered. This is probably self-evident, and should have gone without saying, but it pays to get confirmation of this behavior, especially as we're going to start playing around with Parallel Processes and see how that mucks things up (think of this as the "control" in our scientific experiment).
Now then, this might be a natural conclusion after the previous information, but I have found that an event (non-PP) that transfers the player to another map will continue to run until completion regardless of the map the player is located on. This is just as true of Autorun events as it is for Action and Touch events. There is no exception for events that transfer a player to another map, and then back to the first map - although it's worth noting that upon re-loading of the first map, while the event will continue to run from the point just after the latest transfer (rather than restarting from the beginning), the event, if it either has Autonomous Movement, or was moved during itself or another event while the player was previously on that map, will reload in the position it started in upon the original loading of the map.
Okay, here's where things start to get interesting. If an event (still non-PP) transfers a player to another map that contains an Autorun event (with all conditions met), the Autorun event will not run so long as the transferring event has not completed. This means that if the transferring event transfers the player to that map and then back to the first map (or to yet another map), the Autorun event on that map will not run.
Now, if the original event is an Autorun event, and it transfers the player to another map, then instead of repeating, it will stop running as soon as it reaches its end. This is consistent with the model of events running to completion regardless of player map location, and also clarifies the nature of the Autorun trigger. Autorun events do not simply repeat themselves as a matter of course; they repeat because simply existing on the same map as an Autorun event is the Autorun event's trigger. So each time an Autorun event finishes, as long as the event is still loaded (e.g., the player is still on the map where the event is located), it will continue to trigger each time it finishes. In hindsight, this seems stupidly obvious, but I'll admit I honestly never thought of it working that way...
This does, however, raise a more interesting question: what happens when multiple Autorun events exist on one map, with equivalent conditions, therefore triggering at the same time? The answer, it turns out, is totally logical. I thought that maybe it would be a matter of priority having to do with the x and y coordinates of the event, but it's even simpler than that. Every time you create an event, it is assigned a number - chronologically, in the order you create the events on any given map - and, all other conditions being met, the Autorun event with the lower event number (ID) will run first. It occurs to me that a simple reading of the code (provided you speak the language) would probably yield all these same revelations, with a minimum of fuss. But hey, it works this way, too.
What about Parallel Processes?
Everything is nice and neat and totally logical at this point, but what happens when we throw Parallel Process events into the mix? They're the black sheep of the eventing family, the trigger that behaves unlike all the others. The simple rule that guides all the other events' behavior - that only one event can run at a time, and every event runs until completion - gets thrown out the window where Parallel Processes are involved. Let's explore.
Firstly, I've learned that if you have a Parallel Process event transfer the player to another map, then the event will cease running as soon as the player transfers. So any other commands in the PP event after the map transfer will be ignored, and any Autorun events present (with no unmet conditions) on the new map will activate immediately (in priority order as explained above). After consideration, this actually makes sense, because a Parallel Process event is always running, and if it were another event that was transferring you to a different map, you normally wouldn't want any and all Parallel Processes from the first map to continue running to completion once you've entered the new map.
This, as it turns out, explains exactly the problem I was having that led me to this scientific expedition. I was used to using Autorun events that transfer the player, and then run a few more commands before completing. But in this particular case, I needed to use a Parallel Process event to do the same thing, and I hadn't realized that those few extra commands after the transfer weren't being carried out due to the intrinsic nature of the Parallel Process event trigger.
To continue further, it makes sense that there can be no Parallel Process event that transfers the player to another map, and then back to the first map, since the event will stop running after the first transfer. Thus we have no need of examining the behavior of events after a PP transfer-retransfer, since such a thing is impossible.
I would hazard a guess (a hypothesis?) that the Parallel Process event is either literally being run in parallel with other events (probably most likely), or elsewise that the PP event is actually being processed one line at a time, concurrently with any other active event, instead of being treated as a whole unit. I'm not sure I know a way to test that, or how it would affect certain eventing behaviors. It's probably not very important. I only bring it up because the way that the Parallel Process shuts down mid-event when the player is no longer present on that map would seem to suggest that the event is triggered by the player's presence on the map, much like with the Autorun event, except with the crucial difference that each command in the event - rather than the event as a whole - runs almost independently as a separate event. But again, I'm not sure how I could test that, or if it even makes any real difference.
A quick experiment reveals that, in the same way that Autonomous Movement continues while an event is running - including when a text box is on the screen, waiting for player input - the PP event will continue to run as expected. But here's an interesting thing: while the text box stays on the screen not being dismissed, any PP events will continue to run only until the end of its own set of commands. They will not re-trigger and repeat until after the player dismisses the text box (at the end of any consecutive string of text boxes). This would seem to suggest that the PP event is being processed as a whole, just in parallel (with an automatic "Exit Event Processing" command being triggered whenever the player transfers maps), and that the text box interrupts the way the game processes events in general in a more or less unique way. This could be the impetus for another series of experiments focused around the behavior of the text box, but that is beyond the scope of this exploration.
Conditions
Oh, there was one other thing I was curious about. Aside from transferring maps, another way to muck with the processing of events mid-stream is to change the nature of the conditions required for that event to run. In any non-PP event, this behavior should be pretty straightforward, as the only thing that could change a condition would be occurring within the event itself. But something interesting happens.
Say you have an event that flicks a switch halfway through its processing, and the flicking of that switch corresponds to a different event page with different commands (brief: events have multiple pages that you can set with different conditions, so that the event will behave differently depending on those conditions). Ostensibly, you might think that as soon as the switch is flicked and the conditions changed, the event would immediately abort and start running the commands designated by the new conditions (or wait to be re-triggered if it is not an Autorun event). But this isn't true. The steadfast rule that an event always runs from start to finish without interruption still holds true. But the interesting thing is that as soon as the switch is flicked, any changes to the event's graphic, Autonomous Movement, and "Options" settings occur instantly (which makes sense, since an event's position, graphic and Options are among the things you might want to change during the course of an event). The event page does change as soon as the conditions change - even mid-event - but the event commands will continue to run to completion before the new page's commands (depending on the new trigger) are considered. I think it's significant to note, as this discovery proves, that the running of an event (meaning the set of commands on the active page at the time of the start of the event), and the treatment of the event's stats (graphic, movement, etc.) are treated separately.
And here's the fascinating thing that ties all of our discoveries about Parallel Process events together. The behavior in the previous paragraph describes all non-Parallel Process events. In the case of PP events, as soon as the conditions change, the event aborts and starts running the commands on the new page immediately! (Or, if the trigger is not set to Autorun/Parallel Process, it waits to be re-triggered). This parallels the aborting behavior of the PP event on map transfer, and seems to suggest that the PP event is being re-evaluated line by line, after all.
A precursory examination seems to show that, regardless of event ID, Parallel Process Events are run before Autorun events, and that there may be a lag of some frames (fractions of a second) between the one and the other, such that if a PP event triggers a change of conditions for an Autorun (or other non-PP triggered event) before that event starts running, it will run the page with the updated conditions, but if the Autorun (or other) event begins before the PP event changes the conditions, then it will, expectedly, run the first set of commands before evaluating the new page. This is expected behavior, but if you don't account for the small time lag, it could produce what appears to be unexpected results. This would most likely be an issue where you have multiple events (all but one being Parallel Process, of course) running simultaneously, and I'm not going to get in to the fine tuning of that. A more precise understanding of this time lag would probably be more easily ascertained by a better understanding of how the underlying code functions, and this is thus where the trial-and-error scientific approach exhausts its efficiency.
Oh, by the way, I also just figured out this great thing that's been bugging me: the difference between the "Erase Event" and "Exit Event Processing" commands. It makes perfect sense, given our new understanding of event processing. "Exit Event Processing" aborts the event even if it's not completed. The event still exists and can thus still be triggered anew (which means that Autorun events will immediately restart from the first command). "Erase Event" behaves a lot like changing event conditions mid-event. The event disappears as soon as the "Erase Event" command is processed (so, if it has a graphic, for example, the graphic will disappear, even if the event hasn't finished running), but the event will continue running to completion. Then, since it has been erased, it cannot be triggered again - until you re-enter the map, at which point the event will be reloaded afresh. (Eventing 101: if you want an event to go away for good, you simply add a blank page to the event with whatever conditions depend upon its removal - often having the event flick a self-switch).
tl;dr - Yeah, apologies for the length of this post. My brain is apparently in super-overdrive right now. But for the benefit of all, allow me to summarize my own more interesting findings from the above.
1. Events can be viewed in two ways: by their attributes, and by their list of commands. Their attributes include position, graphic (optional), autonomous movement, and certain other options. Their list of commands is what is commonly referred to by the name "event". It is important to understand that an event's attributes are loaded automatically upon entering a map (or when necessary conditions change), and treated independently of the event's "contents" - its list of commands - whose processing is dependent upon the player activating the event's trigger.
2. Once an event's trigger is activated, the list of commands will be carried out without interruption, until it reaches completion. This is true regardless of whether the event's attributes are changed via changing conditions (which will be reflected immediately), and even if the player transfers to another map.
3. Only one event may run at a time. No event can be triggered while another event is running - this includes another page of the currently running event, even if those page conditions are met during the course of the running event. The new page of commands will only be processed after the current page finishes, and only if the event is newly triggered.
4. An event will only ever run once per trigger. This is true of all events. The reason Autorun and Parallel Process events repeat indefinitely as long as the player stays on the map where they are located is because they are constantly being triggered. (If multiple Autorun events with all conditions satisfied exist on the same map, the event with the lowest event ID will run).
5. Parallel Process events are the only exception to the rules described in bullet points 2 and 3. They can and do run simultaneously with other events (which is their primary purpose), and they appear to be evaluated dynamically. A Parallel Process event will cease running as soon as the player changes maps, and will update immediately* if page conditions change. *(There may be a small time lag involved that could create unexpected results. If you are having difficulty, try adding a "Wait: 1 frame(s)" command just after the condition change).
I think I've discussed the basics of eventing in a previous post, but in case you've forgotten, events are a powerful tool in RPG Maker that govern everything from NPCs, player transfers (the mechanism by which the player moves from one map to the next), treasure chests, all the way to elaborately choreographed cutscenes. When you consider the vast majority of functions that are available to the developer when setting up an event (which becomes obvious the first time you create one and see the pages of commands to choose from), you realize just how versatile they can be.
There are five different event "triggers" - ways in which events can be activated. The first, "Action Button" mode, requires the player to walk up to the event and activate it by pressing the action button. This is pretty straightforward, and is useful for events like opening treasure chests, initiating dialogue when the player interacts with an NPC, etc. The next trigger is "Player Touch" which activates whenever the player comes into contact with or walks over the tile where the event is located. This is useful for position-based actions, like map transfers, and also to set off things like cutscenes when the player steps on a particular tile. The third trigger is "Event Touch" which works very much like Player Touch, but also activates when the event runs into the player - which could be useful for things like roaming enemies that initiate battle when they catch you, or rolling boulders that hurt you when they hit you - things like that.
The last two triggers are "Autorun" and "Parallel Process", and are two different ways of making events run automatically without the player tripping them off in some way. The difference between them is that Autorun events, like most events, interrupt the gameplay until the event is completed. This is one of the best ways to run cutscenes that you want to start automatically upon loading of a map, or upon meeting a certain condition (such as a switch being activated by some other event). Parallel Processes, on the other hand, are unique in that they run "in the background", or in parallel to everything else going on. So if you want to, say, check the status of a countdown timer, for example, without interrupting the player, you can use a Parallel Process event. There are many other useful applications for this trigger, that are easy to figure out with a little imagination.
Another thing that is unique about these automatic events - those marked with the Autorun and Parallel Process triggers - is that, instead of running through once and thus completing the event (which may be run again only if the player trips the trigger again - unless you manipulate your event so that it changes after the first run-through, usually by ticking a self-switch, to prevent it from running again, or to cause it to run differently), these automatic events will run through repeatedly and indefinitely - until some developer-defined condition is met (such as ticking a self-switch, or telling the event to erase itself) that will shut it off. Normally, this is not a terribly tricky situation to handle, as long as you understand what's going on, but I've found in my own experience that some confusion arises when you're dealing with events that involve transfers to other maps.
You see, the way events are set up is that they are placed on specific maps. Even the ones that do not have graphics (like NPCs, treasure chests, etc.), or whose triggers do not depend on being positioned on certain tiles, and are indeed invisible, still need to be placed on a tile on a map somewhere - and will only activate on that map. There are Common Events that run throughout the game, no matter what map the player is on, but they work a little bit differently, and in any case, there are usually few event functions that you would want occurring everywhere in the game, and not just on a specific map. So, it may be clear that an Autorun or Parallel Process event will run repeatedly until such conditions are met as to deactivate it, within the map that it appears on, but what happens when such an event transfers the player to another map?
Does it stop running then, because the event is no longer existent on the map the player has currently loaded? And if there are other commands after the transfer, are they performed before the event completes itself? If so, what happens if such an event transfers the player to one map, and then before finishing, transfers the player to yet another map? Or back to the first map? How are the loading of the events on these other maps treated? What if there is another Autorun or Parallel Process event on one of those maps? If the first event transfers a player away and then back to the first map, does the event that's running restart as it is being loaded anew, or keep running from whatever point it was at because it was never completed?
I haven't found any guides or tutorials that are sufficiently clear on any of these points. And for a while, I've just been taking it all for granted, using these events intuitively to the extent that they do what I want. But I recently came across a situation where things weren't happening the way I expected them to (leading me to quite a bit of confusion until I figured out where the problem was occurring), and I realized I could use a bit of a clearer understanding of what's going on with these events. So, it was time to put on my scientist's cap, and apply the scientific method to the problem, and do some trial-and-error experiments! And, of course, I figured I'd share my results in case anyone else ever comes upon these same problems, and is curious to acquire a bit of a more fine-tuned understanding of how these events work. (Tip: if you don't want to read through all the minutiae, you're more than welcome to skip down to the tl;dr at the bottom, where I summarize my findings).
Here's what I've learned:
First of all, it's worth noting that if you have NPCs or other events that have Autonomous Movement (e.g., NPCs that wander around on their own, or enemies that automatically approach the player), then even though the running of an event (any kind, except for Parallel Processes) will stop the player's actions until the event is completed, other events with Autonomous Movement will continue to move. This is true also while there is a text window on the screen, and the game is waiting for the player to press a button to dismiss it. However, if any of these other events have the "Event Touch" trigger, they will not trigger even if they touch the player as long as another (non-Parallel Process) event is running.
Similarly, if you forcibly move the player (via Set Move Route) within an event such that it would ordinarily trigger a different, Player Touch event, that Player Touch event will not be triggered so long as the first event is running. Basically, this all confirms that, with the exception of Parallel Process events, only one event can run at a given time, and whichever event is run first will run to completion before any other (non-PP) event can be triggered. This is probably self-evident, and should have gone without saying, but it pays to get confirmation of this behavior, especially as we're going to start playing around with Parallel Processes and see how that mucks things up (think of this as the "control" in our scientific experiment).
Now then, this might be a natural conclusion after the previous information, but I have found that an event (non-PP) that transfers the player to another map will continue to run until completion regardless of the map the player is located on. This is just as true of Autorun events as it is for Action and Touch events. There is no exception for events that transfer a player to another map, and then back to the first map - although it's worth noting that upon re-loading of the first map, while the event will continue to run from the point just after the latest transfer (rather than restarting from the beginning), the event, if it either has Autonomous Movement, or was moved during itself or another event while the player was previously on that map, will reload in the position it started in upon the original loading of the map.
Okay, here's where things start to get interesting. If an event (still non-PP) transfers a player to another map that contains an Autorun event (with all conditions met), the Autorun event will not run so long as the transferring event has not completed. This means that if the transferring event transfers the player to that map and then back to the first map (or to yet another map), the Autorun event on that map will not run.
Now, if the original event is an Autorun event, and it transfers the player to another map, then instead of repeating, it will stop running as soon as it reaches its end. This is consistent with the model of events running to completion regardless of player map location, and also clarifies the nature of the Autorun trigger. Autorun events do not simply repeat themselves as a matter of course; they repeat because simply existing on the same map as an Autorun event is the Autorun event's trigger. So each time an Autorun event finishes, as long as the event is still loaded (e.g., the player is still on the map where the event is located), it will continue to trigger each time it finishes. In hindsight, this seems stupidly obvious, but I'll admit I honestly never thought of it working that way...
This does, however, raise a more interesting question: what happens when multiple Autorun events exist on one map, with equivalent conditions, therefore triggering at the same time? The answer, it turns out, is totally logical. I thought that maybe it would be a matter of priority having to do with the x and y coordinates of the event, but it's even simpler than that. Every time you create an event, it is assigned a number - chronologically, in the order you create the events on any given map - and, all other conditions being met, the Autorun event with the lower event number (ID) will run first. It occurs to me that a simple reading of the code (provided you speak the language) would probably yield all these same revelations, with a minimum of fuss. But hey, it works this way, too.
What about Parallel Processes?
Everything is nice and neat and totally logical at this point, but what happens when we throw Parallel Process events into the mix? They're the black sheep of the eventing family, the trigger that behaves unlike all the others. The simple rule that guides all the other events' behavior - that only one event can run at a time, and every event runs until completion - gets thrown out the window where Parallel Processes are involved. Let's explore.
Firstly, I've learned that if you have a Parallel Process event transfer the player to another map, then the event will cease running as soon as the player transfers. So any other commands in the PP event after the map transfer will be ignored, and any Autorun events present (with no unmet conditions) on the new map will activate immediately (in priority order as explained above). After consideration, this actually makes sense, because a Parallel Process event is always running, and if it were another event that was transferring you to a different map, you normally wouldn't want any and all Parallel Processes from the first map to continue running to completion once you've entered the new map.
This, as it turns out, explains exactly the problem I was having that led me to this scientific expedition. I was used to using Autorun events that transfer the player, and then run a few more commands before completing. But in this particular case, I needed to use a Parallel Process event to do the same thing, and I hadn't realized that those few extra commands after the transfer weren't being carried out due to the intrinsic nature of the Parallel Process event trigger.
To continue further, it makes sense that there can be no Parallel Process event that transfers the player to another map, and then back to the first map, since the event will stop running after the first transfer. Thus we have no need of examining the behavior of events after a PP transfer-retransfer, since such a thing is impossible.
I would hazard a guess (a hypothesis?) that the Parallel Process event is either literally being run in parallel with other events (probably most likely), or elsewise that the PP event is actually being processed one line at a time, concurrently with any other active event, instead of being treated as a whole unit. I'm not sure I know a way to test that, or how it would affect certain eventing behaviors. It's probably not very important. I only bring it up because the way that the Parallel Process shuts down mid-event when the player is no longer present on that map would seem to suggest that the event is triggered by the player's presence on the map, much like with the Autorun event, except with the crucial difference that each command in the event - rather than the event as a whole - runs almost independently as a separate event. But again, I'm not sure how I could test that, or if it even makes any real difference.
A quick experiment reveals that, in the same way that Autonomous Movement continues while an event is running - including when a text box is on the screen, waiting for player input - the PP event will continue to run as expected. But here's an interesting thing: while the text box stays on the screen not being dismissed, any PP events will continue to run only until the end of its own set of commands. They will not re-trigger and repeat until after the player dismisses the text box (at the end of any consecutive string of text boxes). This would seem to suggest that the PP event is being processed as a whole, just in parallel (with an automatic "Exit Event Processing" command being triggered whenever the player transfers maps), and that the text box interrupts the way the game processes events in general in a more or less unique way. This could be the impetus for another series of experiments focused around the behavior of the text box, but that is beyond the scope of this exploration.
Conditions
Oh, there was one other thing I was curious about. Aside from transferring maps, another way to muck with the processing of events mid-stream is to change the nature of the conditions required for that event to run. In any non-PP event, this behavior should be pretty straightforward, as the only thing that could change a condition would be occurring within the event itself. But something interesting happens.
Say you have an event that flicks a switch halfway through its processing, and the flicking of that switch corresponds to a different event page with different commands (brief: events have multiple pages that you can set with different conditions, so that the event will behave differently depending on those conditions). Ostensibly, you might think that as soon as the switch is flicked and the conditions changed, the event would immediately abort and start running the commands designated by the new conditions (or wait to be re-triggered if it is not an Autorun event). But this isn't true. The steadfast rule that an event always runs from start to finish without interruption still holds true. But the interesting thing is that as soon as the switch is flicked, any changes to the event's graphic, Autonomous Movement, and "Options" settings occur instantly (which makes sense, since an event's position, graphic and Options are among the things you might want to change during the course of an event). The event page does change as soon as the conditions change - even mid-event - but the event commands will continue to run to completion before the new page's commands (depending on the new trigger) are considered. I think it's significant to note, as this discovery proves, that the running of an event (meaning the set of commands on the active page at the time of the start of the event), and the treatment of the event's stats (graphic, movement, etc.) are treated separately.
And here's the fascinating thing that ties all of our discoveries about Parallel Process events together. The behavior in the previous paragraph describes all non-Parallel Process events. In the case of PP events, as soon as the conditions change, the event aborts and starts running the commands on the new page immediately! (Or, if the trigger is not set to Autorun/Parallel Process, it waits to be re-triggered). This parallels the aborting behavior of the PP event on map transfer, and seems to suggest that the PP event is being re-evaluated line by line, after all.
A precursory examination seems to show that, regardless of event ID, Parallel Process Events are run before Autorun events, and that there may be a lag of some frames (fractions of a second) between the one and the other, such that if a PP event triggers a change of conditions for an Autorun (or other non-PP triggered event) before that event starts running, it will run the page with the updated conditions, but if the Autorun (or other) event begins before the PP event changes the conditions, then it will, expectedly, run the first set of commands before evaluating the new page. This is expected behavior, but if you don't account for the small time lag, it could produce what appears to be unexpected results. This would most likely be an issue where you have multiple events (all but one being Parallel Process, of course) running simultaneously, and I'm not going to get in to the fine tuning of that. A more precise understanding of this time lag would probably be more easily ascertained by a better understanding of how the underlying code functions, and this is thus where the trial-and-error scientific approach exhausts its efficiency.
Oh, by the way, I also just figured out this great thing that's been bugging me: the difference between the "Erase Event" and "Exit Event Processing" commands. It makes perfect sense, given our new understanding of event processing. "Exit Event Processing" aborts the event even if it's not completed. The event still exists and can thus still be triggered anew (which means that Autorun events will immediately restart from the first command). "Erase Event" behaves a lot like changing event conditions mid-event. The event disappears as soon as the "Erase Event" command is processed (so, if it has a graphic, for example, the graphic will disappear, even if the event hasn't finished running), but the event will continue running to completion. Then, since it has been erased, it cannot be triggered again - until you re-enter the map, at which point the event will be reloaded afresh. (Eventing 101: if you want an event to go away for good, you simply add a blank page to the event with whatever conditions depend upon its removal - often having the event flick a self-switch).
--------------------------------------------------------------------------------------------------------
tl;dr - Yeah, apologies for the length of this post. My brain is apparently in super-overdrive right now. But for the benefit of all, allow me to summarize my own more interesting findings from the above.
1. Events can be viewed in two ways: by their attributes, and by their list of commands. Their attributes include position, graphic (optional), autonomous movement, and certain other options. Their list of commands is what is commonly referred to by the name "event". It is important to understand that an event's attributes are loaded automatically upon entering a map (or when necessary conditions change), and treated independently of the event's "contents" - its list of commands - whose processing is dependent upon the player activating the event's trigger.
2. Once an event's trigger is activated, the list of commands will be carried out without interruption, until it reaches completion. This is true regardless of whether the event's attributes are changed via changing conditions (which will be reflected immediately), and even if the player transfers to another map.
3. Only one event may run at a time. No event can be triggered while another event is running - this includes another page of the currently running event, even if those page conditions are met during the course of the running event. The new page of commands will only be processed after the current page finishes, and only if the event is newly triggered.
4. An event will only ever run once per trigger. This is true of all events. The reason Autorun and Parallel Process events repeat indefinitely as long as the player stays on the map where they are located is because they are constantly being triggered. (If multiple Autorun events with all conditions satisfied exist on the same map, the event with the lowest event ID will run).
5. Parallel Process events are the only exception to the rules described in bullet points 2 and 3. They can and do run simultaneously with other events (which is their primary purpose), and they appear to be evaluated dynamically. A Parallel Process event will cease running as soon as the player changes maps, and will update immediately* if page conditions change. *(There may be a small time lag involved that could create unexpected results. If you are having difficulty, try adding a "Wait: 1 frame(s)" command just after the condition change).
Wednesday, June 4, 2014
Introduction to Ascension
I feel kind of bad that I haven't been making much progress on Dragonfaith lately, but maybe this will go some ways in making up for it. Today I was totally inspired to begin work on a separate project. Don't worry, it won't take a significant amount of focus away from Dragonfaith (I hope). It's intended to be a much shorter game, and a simpler project overall, so hopefully working on it and (fingers crossed) at some point completing it will give me both experience and confidence I can put toward the monster project that is Dragonfaith.
Allow me to introduce you to Ascension. It's one of the story ideas I've had swimming around my head for years, like Dragonfaith - except it wasn't as clearly destined for a game format. But having spent so many years not completing a written story about it, and after trying out a doomed-to-failure HTML-based Choose Your Own Adventure version that proved to be way more effort than it was worth putting in to complete, I've kind of been looking for a more interactive way of telling the story. And RPG Maker VX Ace might be just the ticket.
In contrast to the RPG-style fantasy adventure that is Dragonfaith, Ascension is a horror-based game with an emphasis on narration and exploration. As such, it has a much different feel, and requires a much different development approach than Dragonfaith - which I think is totally refreshing and exciting. I'll be honest, I kind of have the "visual novel" feel in my mind as an inspiration (Fate/Stay Night being the preeminent example in my playing history), but integrated with a good deal of the top-down 2D perspective as is typical of RPG Maker games. Although you will encounter monsters in the game, I don't intend on there being any sort of random encounter-type combat that is typical of RPGs (which this game is decidedly not). The focus will instead be on creating a spooky atmosphere, and giving the player the opportunity to explore the maps I'll be creating.
As a little background, the plot of Ascension follows a soul's journey after death through the 13 Stages of Hell, based loosely on various mythical and religious interpretations of the infernal version of the afterlife. I have a nice little teaser on my website, if you're curious to learn more. As of now, I have the first stage completed (barring bug fixes and future modifications). It's a short stage, but it's just a start, and I'm really excited to show it off nonetheless. So download and enjoy!
14/06/03 Ascension - Stage 1 (1.89 MB) [edit: new release available, check sidebar for info]
(As usual, you'll need the RTP to play this game - but if you've already downloaded it for the Dragonfaith demos, you're good to go).
Allow me to introduce you to Ascension. It's one of the story ideas I've had swimming around my head for years, like Dragonfaith - except it wasn't as clearly destined for a game format. But having spent so many years not completing a written story about it, and after trying out a doomed-to-failure HTML-based Choose Your Own Adventure version that proved to be way more effort than it was worth putting in to complete, I've kind of been looking for a more interactive way of telling the story. And RPG Maker VX Ace might be just the ticket.
In contrast to the RPG-style fantasy adventure that is Dragonfaith, Ascension is a horror-based game with an emphasis on narration and exploration. As such, it has a much different feel, and requires a much different development approach than Dragonfaith - which I think is totally refreshing and exciting. I'll be honest, I kind of have the "visual novel" feel in my mind as an inspiration (Fate/Stay Night being the preeminent example in my playing history), but integrated with a good deal of the top-down 2D perspective as is typical of RPG Maker games. Although you will encounter monsters in the game, I don't intend on there being any sort of random encounter-type combat that is typical of RPGs (which this game is decidedly not). The focus will instead be on creating a spooky atmosphere, and giving the player the opportunity to explore the maps I'll be creating.
As a little background, the plot of Ascension follows a soul's journey after death through the 13 Stages of Hell, based loosely on various mythical and religious interpretations of the infernal version of the afterlife. I have a nice little teaser on my website, if you're curious to learn more. As of now, I have the first stage completed (barring bug fixes and future modifications). It's a short stage, but it's just a start, and I'm really excited to show it off nonetheless. So download and enjoy!
14/06/03 Ascension - Stage 1 (1.89 MB) [edit: new release available, check sidebar for info]
(As usual, you'll need the RTP to play this game - but if you've already downloaded it for the Dragonfaith demos, you're good to go).
Sunday, May 18, 2014
Free Will vs. Determinism
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...
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 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!
Subscribe to:
Posts (Atom)