A Series Of Perfectly Normal Events - Part I

[WARNING: Image-heavy post]

Part 3 of the beginner RM2K tutorials. Events.

Where do I even begin?

Ah yes, events. That's a good starting point.

Custom events, along with switches and variables, form the backbone of your game. They let you create hero interactions, cut-scenes, even battle mechanisms. Some events are absolutely necessary for almost any game - like the teleport event, without which you can't move from one map to the next. The 'Set Hero Start Position' that we used in the previous tutorial, that is also an event which we had placed in the events layer.

There are 3 kinds of events in the editor - map events (like Set Hero Start Position), common events (think of these as events that are common to all maps in your game) and battle events (that occur within a battle only).

We'll begin with the ones used most often - map events.

This post is going to be a bit more theoretical than the previous ones, as I feel things might get a little confusing if we jump straight into using events in our game. We'll still need our game editor open though. Go ahead and re-open your game, and move to the 3rd editing layer - the 'Events' layer.

Double-click on any one of the grid squares to open up the event dialog box.

A quick introduction to the different areas on this box before we dive in-depth-

1. This is where we can give our event a name/label. The default is just fine for standalone events, but if you'd like to connect events in some way, an easy to read, meaningful name will help.

2. Page actions toolbar. Pages refer to how many, well, pages of the white sheet that is the next section will be present in this event. This feature lets us have multiple pages of different sets of commands in a single event. More on pages further down.

3. This blank canvas is a page, and is where we input all our instructions. It's a click-and-select interface so there's no coding needed here (or anywhere else in RM2K, really).

4. These two panels help us set some properties for this specific event, like the graphics and trigger.

5. This last section is the conditions panel. Here, we can set conditions that determine whether the event gets triggered at all or not. Each page has its own set of panels, including the conditions panel. So each page can have its own set of conditions.

Now let's look at the 3 most crucial sections in a bit more detail - graphics and trigger, conditions and page - in that order. I'll cover just enough for now for us to be able to actually use events for common scenarios.

From hereon, we get back to the 'hands-on' approach of learning.

1. Graphics and Trigger

This is where we can set what our event looks and acts like on the map, as well as what triggers the firing of the event. Let's begin with a really common event - an NPC (non-playable character) that the hero can interact with.

Graphics - click the 'Set' button to pick the graphics for your event. You will see that you are actually able access way more than the foreground elements of your tileset to be able to set up event graphics. You can pick anything from one of the 'charsets' in the RTP library. You also have the option to make the graphic look transparent/translucent (think ghost sprites).

NOTE: There are in fact 2 common ways you can use graphics for an event (there may be more, but I haven't come across them out yet).

1. You can set an event on a tile that already has a foreground (or even background) element - this ends up being the graphic - and ensure you don't set the graphic in the events dialog (so leave it at the default pink rectangle). The event will still run once triggered appropriately.

2. Or you can set the graphic directly from the events dialog.

We'll set up both shortly (for setting up the NPC, we'll need method 2).

Movement type - this gives you a choice of ways in which your graphic can move on the map. The choices are pretty self-explanatory. When you select custom, the 'Set custom route' button below becomes clickable. You can click on that to set a custom cycling or non-cycling pattern.

Frequency here refers to how fast the sprite moves. There's a whole list of movements and actions you can choose (more than in Don's version, I think) from on the right. Fun stuff.

Trigger and the rest - options here determine when the event runs. The actual event instructions that run when triggered, if you'll recall, are added to the blank white page.

Action button => when the player clicks on it (with the spacebar or enter key); player touch => when the player touches it; event touch => when it touches something; autorun => as soon as the map loads (note: this will block all other events on the map until it is stopped - perfect for initiating cutscenes); parallel process => runs when the map loads, irrespective of whether the player interacts with it or not. Autorun and parallel process events run in infinite loops.

The priority level decides where the event is vertically. So, can your hero walk over it? Select 'below characters'. Walk under it? 'Above characters' it is, then.

NOTE: If you are using method 2 for setting a graphic (i.e., placing an event on an already existing foreground or background element), then you must make sure that the priority you choose is the same as that particular element's 'passability', otherwise it may not be possible for the hero to touch or interact with the event in order to trigger it. So if the background/foreground tile is passable/walkable, then the event must be 'below character'. If the element is not passable, then is must 'same level as character'. And so on.

The 'forbid event overlap' option below (in Don's version, it says 'allow event overlap') will prevent your hero from walking either over the event or under it, even if your priority is set to either of those options (yeah, I don't know why this option exists either).

Animation type and movement speed let you choose how your event graphic is animated in the standing position. Only charset graphics have this property, foreground graphics from the map's tileset do not.

That was too much typing for these gnarly carpal-tunneled hands. Let's hop right in and set up our NPC's graphic now!

If you thought I'd forgotten about the irrelevant image for today, you would be correct

I've made a ghost NPC with the following settings-

The custom movement is just that it walks left 4 paces and back right 4 paces, over and over. I have not made it 'transparent' because it is a very opaque ghost indeedly. The event trigger, as with most NPCs, is when the hero 'clicks' on it.

2. Conditions

This panel lets us set certain filter conditions that decide whether the event actions actually take place or not. For example, let's say your NPC happens to be a thief who fleeces you by getting you to pay through your nose for a bag of sawdust that he or she sells as ground Egyptian mummies. Now, if you don't look like you're loaded already, you wouldn't be an appealing target for the thief, would you? That then, would be a condition - something that needs to be satisfied before the fleecing begins.

UNWORTHY NOTE: If your event conditions are not met, the event is simply not loaded on to the map. Go ahead and try it - try adding some random condition that you *know* cannot be met at this point, and when you run a test play, you won't even see your NPC on the map.

You can have up to 2 switches and 1 variable as conditions. Switches and variables will have their own posts, but a switch is essentially like a light switch - it can either be on, or off. For example, when a particular custom switch is off, I can make it so that the thief cannot be present there to fleece you. Both because it's too dark to see you, and because I made it so. Beat that, you snivelling criminal!

A variable is something that holds a value that can change.

You can select any number of these as pre-conditions (of course, the combinations will need to make logical sense for them to result in what you expect). Item => If my party/character has this particular item on hand, only then will the event run; Actor => If I have this particular person in my party, only then will the event run; Timer => this only works if you've got a (countdown) timer running on your map. Maybe we'll use a timer in this game eventually? Those can be a little fiddly, from my experience.

I am setting no conditions for this NPC event.

3. Page

Now we come to the most versatile panel yet - the page is where we put in all the instructions that will run once the event has been successfully triggered.

Your event can have multiple pages, each with their own set of conditions. Only one page can be active at a time in-game, and the page that will be active will be the one whose conditions are satisfied. Important: in case multiple pages have their conditions satisfied at the same time, only the page with the highest page number will be active.

Going back to our thief example again, said thief would not even appear on the screen to fleece you unless you were rich enough. So the instructions for befooling you would be on the 1st page, and the condition applied to this page would be that you were rich enough. But let's say I want the thief to be on the screen regardless - the case we're looking at is when the condition of wealth is not satisfied (let's call it the 'broke' case). Right now, the event simply does not show up on the page in the 'broke' case, but we can change that by -

1. Creating a new page with all the fleecing conditions and instructions, and

2. Turning page 1 into the default 'broke' page by adding no conditions at all to it.

You may ask why bother doing that, when you can easily just create a new page for the 'broke' case itself. The answer is, page order matters. The game engine starts processing pages and checking for satisfied conditions from right to left. From higher page numbers to lower page numbers. The moment it finds a page whose conditions are met, it stops looking further and activates that page. So if we make page 2 our default 'broke' page, the engine won't even get a chance to see the conditions on page 1. Page 2 will win by default because there are no conditions preventing it from being eligible for activation. A little confusing at first, but practice makes it easier.

Double-click on any line and you'll see a whole bunch of options pop up. Most of these explain themselves, so I won't be going over them in detail in this post. Instead, I'll go straight over to setting up my NPC's actions.

Here's what I did - I set the 'faceset' of my ghost (tab 1, column 1) -> displayed a vague text message (tab 1, column 1) -> added in a random sound effect (tab 3, column 1 'Play BGM').

NOTE: You can double-click to add an event command, and if you want to edit an existing one, you can either right-click and choose edit, or select the command and hit the spacebar.

Hit OK and it's done!The NPC LIVES! You can run a test play and interact with your NPC, see if it works as you would want it to.

We can make teleport events work the exact same way. The graphic for a teleport event is set via method 2 from above (i.e., don't set any graphic properties from the event dialog box). I'm going to create a new small map, cover it in just grassy tiles for now, and set up a teleport event that will take Chester from the map with his hut to this new map.

I've marked the exit area with the sandy tile, but a good practice is to make sure the player can't try to exit from any other area - use foreground elements and such to directly block any other way. It's pretty irritating walking to the edge of the screen and just hitting a dead-end.

Double-click to open the event dialog box, and set a teleport event (tab 2, column 1 'Transfer Player'; in Don's ripped version, it's called 'Teleport'). The trigger settings should be 'Player Touch' and position should be 'Below Hero'.

Choose your map and destination tile from the new dialog box that pops up, and that's it. Set up a teleport point from the second map back to the first in the same way, and you now have 2 screens in your game that you can move between.

"What may lie beyond the blue..."

Try out combinations of different events/player actions to see if you can spruce up the transition in any way - such as automatically making the hero sprite take a step forward in the new screen, or forcing the player to be facing a certain direction before being able to teleport (hint: this will need the fork condition command)

Now would also be a good time to mess around with the other event commands that you can use on the page.

The next post will get variables out of the way so that we can move on to common events and battle events.

Until then,

-The Mildly Overworked And Harassed Meese