[Eventing]Switch & Variable Efficiency, Moving from Amateur to Pro with Switches & Variables. Options

[Titanhex]

So I was grabbing some help earlier and had to return the favor. I realized what I know is not very common amongst the RPG Maker developer base, and wanted to change that.

There's a million guides for Beginners which teach them how to use switches and variables. But there's nothing that teaches them efficiency once they've learned these. I want to change that.

I see a lot of people here turn very easy, simple systems into bloated code, but only because that's how the beginner tutorials taught them to do it.

I'm here to tell you you're making more work for yourself and complicating your systems. So, lets get into it.

What a Switch REALLY is

You've always thought a switch was an ON/OFF didn't you. Well this is only half true, and sort of limits your vision of switches. I'm here to tell you what a switch REALLY is. A switch is just a boolean. What's a boolean? In programming, a boolean is simply a TRUE/FALSE. Makes sense right, ON/OFF, TRUE/FALSE. The default for switches is always OFF/FALSE on creation.

This means instead of checking if two opposites are on, such as IS PRESENT or ISNT PRESENT, you can just check IS PRESENT = ON(TRUE, Is present) or OFF (FALSE, Not present), removing that ISNT PRESENT switch.

Oh no, but what if there's 3 values. PRESENT, NEAR, and FAR. Don't make 3 switches! Make 1 variable. 0 means PRESENT, 1 means NEAR, and 2 means FAR. (BTW Variable default on creation is 0)

Turning Switches into Variables

Many switches can be condensed into a single variable. Lets say a player must grab a key to progress, then open a door to beat a boss, and pick up a chalice in the boss room by checking piles of junk. GRAB KEY would be a switch, as would KILL BOSS and GRAB CHALICE. But you could turn all of these into 1 variable, MAIN STORY STEPS, and check if MAIN STORY STEPS is higher than a number. I do this for linear plots in a game, which just move forward like steps, in increasing order. This turns upwards of 100 switches into a single variable.

So, instead of turning on GRAB KEY, we'd either set the variable to 1 or do +1. This would replace the line [Turn on Switch, GRAB KEY = ON] with MAIN STORY STEPS =+ 1. Instead of checking if GRAB KEY = ON, we'd check if MAIN STORY STEPS is greater than or equal to 1. Instead of KILL BOSS, we'd do set MAIN STORY STEPS to 2 or +1, checking for MAIN STORY STEPS equal to or higher than 2 instead of KILL BOSS as ON.

It's a good idea to keep a comment nearby telling you what # the variable should be after adding to it.

If you have a mission that requires doing steps in a random order, like collecting items scattered in a dungeon, it's easy. If the variable is at 22 when they get to this point and they have to collect 3 items in any order, each time they find an item that variable increases by 1. Thus, by the end of the collecting, the variable will be 25. So 25 is the number we check to know they have all the items.

When do I use a Switch and when do I use a Variable?

A lot of people use switches when they can be using variables. This is what this tutorial is about. Let me convert your thinking. A switch is an ON/OFF, which if you read early is just a TRUE/FALSE. A true false is really just a 0 or a 1.

What? That makes no sense. Well, what's the difference between the switch HAS DOG = ON/OFF and the variable HAS DOG = 0/1. If we check for 0, then we do the things for HAS DOG being off. That'd be the same thing for checking for OFF. Try it yourself. You'll see.

Variables are great when going through steps. Steps can be numbered. Step 1, 2, 3. That is why variables are great for quest lines, and main story setup. They're just steps.

Variables are great for checking how many items someone has collected. But if you want to check for a specific item, you should use a switch, since they either do or dont.

And that's where switches come in. Very simple black or white, do or dont, true or false. If something needs to be defined by only two values with no sequence switches are good. Like checking for gender. If we're checking for hair color, we'd use a variable as hair color has many values.

================================================================================

Thank you for reading! Underneath I've contained snippets that can help you in other commonly misunderstood areas.

The Common Event

Common events, while nice to shrink long snippets of code, is better used for actual "common" events. Common Events means the event reoccurs more than once in the game. This can make altering and correcting code so much easier. Instead of having to change the code in every event, you just change the code once in a common event. It's especially useful when you must detect an area around an event or a wide passage for a player's approach.

It can be great for creating unity in code as well, allowing for consistency, so that if you typo once you will see it in all the code that calls it.

It's important to note that objects and spells can also trigger Common Events, which can be highly useful to activate special conditions or spells. I myself have made a "HP Damage Field" that increases in power when a boss uses a skill with common events.

Credits to Night5h4d3 for bringing this up. Common Events should also be considered as Global Events. What this means is that the event can be run anywhere in the game, or can be running indefinitely despite what map you're on. When creating an event ran system it's good to keep this in mind, as it can allow a number of things, like poison effects periodically on a character with HP reduction, screen shaking when drunk, or timers.

Debugging

Ever had a problem with your events, and no matter how much you looked at the code you couldn't figure it out? Try DEBUGGING. Put in messages near the problem that say "THIS PART IS HAPPENING" or show values like "\v[1]" so you know what value a variable is at a given time. This will help you know where exactly the problem is happening until finally you pinpoint it.

Suggested by lilcooldude69: If you're playtesting your game through the editor, F9 can open up a nifty switch and variable editor as well.

Page Numbers vs Conditional Branches

I want to get people thinking about page numbers and conditional branches a little differently too. A page number is really just a Conditional Branch. You may say, "But how?!" Well, let me show you.

Think of 3 pages, each checking if a variable is 1, 2 or 3. If it's 1, on the page we put the message "This is Page 1". Repeat for 2 and 3.

Well it's the same as if we had only 1 page, but in that page we had 3 Conditional Branches. The branch checks if the variable is 1, next branch if its 2, next if it's 3, telling us what page number it is. The order the branches are in is the same as the page order. These two events are actually the same thing.

Now where page numbers and conditional branches are different is in the bottom left corner of the page, where you see Autonomous movement, Graphic, Priority, Trigger and Options. When these are not consistent between pages, then page number is necessary.

Loops & Waits

Recently I had a problem where I was running a loop without a wait in that loop. Believe it or not, if a loop doesn't have a wait in it, it could run so rapidly it stops your game from updating the screen. This is true in scripting as well as eventing. Remember when using loops to include a wait somewhere, and/or a break point so it doesn't run infinitely. If your loop isn't working, check these two problems first. It's likely one of those.

What many don't know is that a Parallel Process and Autorun is just the Loop Event with some tweaks and GUI Setup. Parallel Process is the Loop event that lets you still use your hero, and Autorun does not. The loop is broken by moving to a new page number.

Eventing is Scripting

" What?! Ludicrous! I can't script." You might say. Well, maybe I'm exaggerating a little here. Eventing is psuedo scripting. All those events you made, they're turned into script by the game. All you're doing is taking blocks of script that do certain things and putting them in via the events menu. The engine does the hard stuff for you.

But scripting is a lot of what you've already learned. Variables, Booleans, Loops, Ifs (Conditional Branch). Those are what compose the start of scripting. If you start to master these concepts, scripting may just be up your alley.

This post has been edited by Titanhex: Aug 8 2011, 01:38 PM

[Vanit]

Ahh, so there it is. I tried to look up if something like that was happening (I wasn't sure what the deal was with the abstraction), and when I found nothing I assumed it was abstracted like rm2k3.

Reading the thread it seemed like we were talking about eventing, and there was no real mention of this being done in scripts until BigEd himself explicity mentioned Ruby. But if that is infact what we're talking about I stand corrected, despite the thread not mentioning that, and the only screenshots being of an event.