Common Events

[Zeriab]

Common Events
Note: This is aimed at intermediate eventers

Common events are pretty much like map events with change that they are made common to all maps and don't have pages. (Or exactly one page)
I will discuss various issues of common events though first take a look at this common event and map event:

What happens when you trigger the map event?
What would happen if you change the common event's trigger to Parallel instead of Autorun and then trigger the map event?
What happens if you call the common event from a battle event?
Basically, how does self-switches work in common events with the added question about order of execution.

The call stack
Self-switches
The common events do not have self-switches attached to themselves, but you can still use the self-switch functionality. They work differently than in map events.
To help understand how self-switches work in common events I will introduce the concept of a Call Stack. Whenever you use the Call Common Event... event command you place the common event on the Call Stack. (On top of the event which calls the common event)
To help you understand the Call Stack try to imagine a stack of papers. Each time you call a common event you place on top of the stack just like you would place a piece of paper on top of the paper stack. Whenever you have processed the top common event you remove it from the stack and look at the event which called the common event since it is now on top. This event is then continued from where it called the common event.
A bit like you read the paper on top of the stack. You come to a 'call common event' and place another paper on the stack. Once you have read that paper you go back to the previous paper and read from where you left it.

All except the bottom event (the event which is not called with the Call Common Event... event command) in the Call Stack are common events because only common events can be called. The bottom event can be a map event, battle event or a common event.
The bottom event is the important event when considering self-switches since the Control Self Switch... command only makes any difference when the bottom event is a map event. If the bottom event is a map event then the self-switches changed will be the map event's self-switches. Likewise is the self-switches of the map event considered in conditional branches. If the bottom event is not a map event then all self-switches are OFF and you cannot turn them ON.
You can have several map events call the same common event. When each map event is interpreted it is used for considering self switches.

Here is an example of a chest (2 pages) and a common event:


Set move route
As you can see I have used a Set Move Route... command which works similarly to Control Self Switches....
If you select This Event as the event to use it will only work if the bottom event of the Call Stack is a map event.
The map event is the one moved just like how the self switches of the map event were considered in the common event.
If the Player or a specific event was chosen then it will work on the map, but not in the battle.
Note that when choosing a specific event the id is considered. If you call the event on a different map it will try to use the event with the same id on the different map.
Note also that you can only pick among the events on the map you look at (or lasted looked at). You may therefore need to choose a different map before you can pick the event you want.

Code reuse
After having made the event above you can just copy and paste the chests to get chests that you can only open once. What are the advantages of this approach? What are the disadvantages?
If you change the common event you will change the functionality of all the chests. If you want it to open a little faster you just have to do it in the common event. No need to find all chests and change them all.
A disadvantage which I am sure you have realized is that all the chests currently contain the same thing, 50 gold. You can of course easily change it, but you would change the contents of all the chests. What if you wanted the chests to have different contents? Well, you can remove the message and gold gain from the common event and place it in the chest. Then you can change it from chest to chest while still sharing the way of opening a chest in the common event.
You can say that you reuse the code for opening a chest. You only define it one place and then reuse it in each chest. Of course you can make a common event which other common event calls. Code reuse is about preventing copy-pasting of event code where you make no alterations.
Does this mean it is always a good idea to share functionality? NO! It is not always a good idea to share functionality. You have to evaluate the need on a case-by-case situation and sometimes a solution which is preferable in one situation or game is not preferable in another situation or game.

Code reuse typically increases complexity initially although it may turn out later to increase the productivity. On the other hand it may turn out to decrease the productivity.
Take a look at this event demo: http://zeriab.plesk3.freepgs.com/root/events/Doors.rar
It is a door system where the player can pick the preferred functionality of the doors, or at least the standard doors.
Is it ridiculous? Has too many common events and effort been spent on the doors? Is it even worth it? Is it too little?
It is case-dependent. It most cases probably a little too much, but then again, maybe not. Maybe the player will like being able to speed up transitions after a while. It may just add an extra touch.
I do hope you see what I am getting at.
There is of course much more to be discussed about code reuse but I will leave that to another tutorial.

"Common event call has exceeded maximum limit."
You get this error when there are too many events on the call stack. There is a fixed limit of at most 100 events on top of the bottom event. If you try an additional call common event you get the error.
You can alter this limit with a simple edit to the Interpreter script. Note that the amount of calls is limited by the system stack as well. With a simple event which called itself I got to make 491 calls before getting a SystemStackError. Do not make the mistake of thinking you can use up to 491 calls since some event commands can easily need more calls and with the alias style in many scripts you can easily have more calls.

I can't imagine a situation where the 100 call limit will be a problem except for badly designed events. You can for example consider the situation where you have one common event calling another common event which in turn calls the first common event. There, you have a cycle. This error should definitely be discovered, but you can have designs where it may not necessarily be discovered.
Consider an evented menu where you have a common event for each menu item. The menu is shown as well. If you move up or down you call the common event corresponding to the new menu item and then just prepare for that event to exit afterwards. When you have gone up and down more than 100 times you get the error. It is definitely possible that you won't test for this.

How should it have been designed instead? One solution could be to introduce a common event which launches the common events for each menu item corresponding to a variable. Each of the common events will exchange the explicit calls to other menu common events with an implicit call by changing the variable and then exiting. The launcher common event will then call the common event.
We now have a structure which should not continuously increase the size of the stack. (The amount of papers in it)

Exercises
These exercises are totally optional. You can use them to get a feeling of what I am talking about and for getting some experience.

Exercise 1
The first exercise is about answering the questions answered at the very top about the Mysterious person.
Try to guess what messages will be shown when the common event trigger is on Autorun.
Try to guess what messages will be shown when the common event trigger is on Parallel.
Try to guess what messages will be shown if a battle event calls the common event. (Common event triggers won't work in battles)

I suggest you write it down and then use RMXP to check it the answers. Be sure to enter the events exactly as shown here.
Here are the answers although I recommend you using RMXP to check the answers if possible.

Content Hidden

Try to guess what messages will be shown when the common event trigger is on Autorun.
Message 1: ON

Try to guess what messages will be shown when the common event trigger is on Parallel.
Message 1: ON
Message 2: OFF

Try to guess what messages will be shown if a battle event calls the common event.
Message 1: OFF

Exercise 2
This exercise revolves around making a chest system you are satisfied with.
Try to make it easy to copy while still being easy to modify. This is about making your game quicker.
You can additionally consider storing how many chests have been opened for stats fanatics. (Believe me; if you get an idea like this far into the project you will be VERY pleased if all the chests use a common event)

Exercise 3
Everybody loves puzzles.(Untrue statement)
Therefore this exercise is about making a puzzle or at least some building stones for puzzles.
The idea behind the puzzle is to get from point A to point B. There are some objects in the way with which you can interact.
Here is a list of the building blocks:

• A boulder which you can push forward
  
• A boulder which keeps sliding forward until it hits something or you push it another way
  
• A boulder which you only can pull backwards
  
• A boulder which you can both push and pull
  
• A boulder which you also can drag sideways
  
• Anything else you can imagine
  

Try to create nice scalable solutions. Hopefully boulders you can just copy and paste.
I won't promise that all of these types of boulders are feasible to create nice and scalable. It is up to you to find out.
Good luck.

Final notes
While this is very tutorial like I want discussions. Hopefully insightful discussion about beneficial common event use.
I realize that I have only scratched the surface here. I haven't talked about scalability yet. I feel that it is a bit too much in an intermediate eventing tutorial.
I will be happy to hear any suggestions on how to improve this tutorial.
I want to thank everyone who takes time off for reading my tutorial and everyone who replies.
I hope you will become wiser in your eventing decisions.

Thanks
Iceplosion for some very nice critique!

*hugs*
- Zeriab