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]

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]

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]

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).

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).