USING COMMON EVENTS TO MAKE LIFE EASIER

This mini tutorial, which I did not deem substantial enough for a full article, is aimed at intermediate to expert developers. It is particularly aimed at gameplay-intensive games such as puzzle games, but can be extended to any genre of game made within the RPG Maker engine and perhaps beyond, if you replace the word "common event" with "function".

You can use common events to make game development more quick, efficient and easy when you want to be able to alter the shared functionality of a set of events. Here are some ideas for using common events.


1. Player transfers, or teleports. By storing these in common events you can alter default Fade type, SE and other specifics of transfers for all move-related events. Just use the "Designation with variables" option in the "Transfer Player" command and call this common event after assigning Map ID, Map X and Map Y variables. If "Direct designation" is preferred, just standardize the Move SE using a common event, as well as before/after transitions, stated in point 2.
2. Before/after transitions. Use these to standardize fade outs/fade ins before/after the teleport events. What I recommend is a "Tint Screen" to black, and use "Transfer Player" with "None" Fade, followed by a "Tint Screen" to normal colour.
3. Puzzle items such as crates or boulders. This is more the case with puzzle games, but I believe it makes life easier for any game. To standardize the behaviour of objects in your universe, assign a common event that defines that behaviour. For example, if a boulder will roll until it hits a wall, and then makes a sound at the end, create this functionality in a Common Event and duplicate it for all boulders, so that if a new puzzle mechanic comes up that requires you to modify the boulders' behaviour, you don't have to go through every single boulder and copy-paste the relevant code. This improves modularity and the ability to modify all boulder code using one event. This hopefully will speed up game development, and make it more robust and understandable.
4. Save points, victory/flee/defeat conditions in scripted battles. You can standardize save points, and what happens if you win/flee/lose scripted battles.
5. Reset map. Again, mostly useful for puzzle games. Create a common event that teleports you to another map and brings you back to the origin spot, possibly resetting self switches in the process, if required. The script I use to reset all self switches in a map is as follows:



This allows you to call "reset_self()" in a "Script" event command to reset all self switches on a map.

And now I'm going to give you another weird tip.


Use an "@" sign before a variable name to declare it private to an event. For example, in an event you may assign name, age and gender to an NPC, as follows:



In the first Conditional Branch, the script check "@init.nil?" checks if the private variable "@init" exists. If it does, it initializes "@name" as "John", "@age" as 16, "@gender" as "M", and "@init" as true, which is to indicate that initialization has occurred. This is so that the next time you interact with this event, it won't reset the age back to 16.

The next Conditional Branch checks if you are 18 or older. It uses the script "@age >= 18", which means "is the private variable "age" greater than or equal to 18?". If that is true, it displays a message saying you're an adult. Else, it displays a message saying you are not an adult yet.

Next, it asks if you would like to age one year, and then if you say yes, it will increment the "@age" variable by 1.

If you interact with the event 3 times and say "yes" the first 2 times, it will tell you that you're an adult. This is because the "@age" variable would have been incremented by 1 twice, leading it to equal 18, which satisfies the conditional branch "@age >= 18".

The advantage of using private variables over public variables is that you can literally copy-paste this event multiple times, and not have to change a thing. If you used public variables and tried to copy-paste this event severally, these events would share the same public variable, and you'd have to change every single one of them. But when you use private variables, there is no need to modify each event.

You can combine this with the advice I gave above by storing the event code for a "Teenage Boy" type of event in a Common Event. This standardizes the behaviour for "Teenage Boy" and makes it easily modifiable. Thus you can copy "Teenage Boy" wherever you like and he'll work.

Note that this is more useful for objects that do not exhibit unique behaviour, like crates or boulders or save points.