Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -



Post new topic Reply to topic  [ 10 posts ] 
    Zeriab
  Tue Dec 30, 2008 8:53 pm
Hugging Lion
User avatar
Sponsor

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:
Image Image
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:
Image Image Image

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://www.mediafire.com/?uckm2itjdgg
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


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

_________________
Image
Image
Image
Image
Image


Last edited by Zeriab on Tue Jan 06, 2009 5:58 pm, edited 3 times in total.

Top Top
Profile      
 

    rmxp_beginner
  Wed Dec 31, 2008 2:04 am
Gamer since rm2k3
User avatar
Member


Location: Torrington, Connecticut
I don't really see how this is aimed towards "intermediate eventers" seeing as i'm new to RMXP and understood your tutorial all so well. Might want to fix that, and please try not to use color. its annoying to see and screws up my eyes :-) thanks

_________________
What i'm good at

Things I'm working on to get better at

TAKING REQUESTS!!!


Top Top
Profile      
 

    Nachos
  Wed Dec 31, 2008 5:19 am
User avatar


Check you screen contrast, because the blue & red shouldn't be bothering you eyesight.

The tutorial is very well-made. Ans yes, there are a lot of intermediate eventers who don't know how to do this.


Top Top
Profile      
 

    rmxp_beginner
  Wed Dec 31, 2008 5:23 am
Gamer since rm2k3
User avatar
Member


Location: Torrington, Connecticut
thats interesting
also, i found out why the colors hurt....its cuz my eyesight is fucked up...getting eyes checked tommorow maybe getting glasses....

_________________
What i'm good at

Things I'm working on to get better at

TAKING REQUESTS!!!


Top Top
Profile      
 

    Zeriab
  Thu Jan 01, 2009 2:47 am
Hugging Lion
User avatar
Sponsor

Thanks a lot for the comments.
The reason I say the tutorial is aimed at intermediate eventers is because I don't go into details you see in other tutorials like what is a switch, what is a self-switch and so on. I assume the knowledge is present.
I am happy you understood my tutorial. It means my explanations work :D
About the color, can you tell me how it is when you get glasses? Is it still stressful to look at?

I have updated the tutorial with a new section about the limit on the size of the call stack.

*hugs*
- Zeriab

_________________
Image
Image
Image
Image
Image


Top Top
Profile      
 

    Surmuck
  Thu Jan 01, 2009 3:01 am
oficial anderson coop fan club presdent
User avatar
Member


Location: Literary Analysis
This is a great new tutorial Zeriab; it's very well written and I'm sure it'll help a lot of people

Nothing less than what I'd expect :thumb:


Top Top
Profile      
 

    Zeriab
  Fri Jan 02, 2009 9:47 pm
Hugging Lion
User avatar
Sponsor

Thanks for the nice comment Surmuck :3

*hugs*

_________________
Image
Image
Image
Image
Image


Top Top
Profile      
 

    Dissonance
  Sat Jan 03, 2009 6:11 pm
I'm good 'till the last drop!
User avatar
Banned


Location: back to nigger dicks out of spite
Good stuff.

I mean I am already way above this level of eventing myself ubt it's great for noobs. I remember having to figure out common events by myself. :x


Top Top
Profile      
 

    Zeriab
  Tue Jan 06, 2009 5:58 pm
Hugging Lion
User avatar
Sponsor

Thanks Diss :3
Maybe my next tutorial will be one you can learn from ^_^

I have revised the tutorial so hopefully it's even more awesome :cute:

*hugs*
- Zeriab

_________________
Image
Image
Image
Image
Image


Top Top
Profile      
 

    LDanarkos
  Wed Jan 19, 2011 11:52 am
Member

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

I had trouble understanding this. I'm using RM2K, and the error I got was "Event Call Limit Exceeded," but it's basically the same thing. Also, I didn't produce the error from calling common events, I produced it by calling map events (with the Event Start Condition set to Push Key, not sure what the RMXP equivalent is called). But either way, I think the error will go away if I can figure out what the above passage is telling me to do. (Reason I asked here is this is the actual only English thread that addressed "Event Call Limit Exceeded.")


Top Top
Profile      
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 


Who is online

Users browsing this forum: No users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

We are an independent, not-for-profit game making community.
Homepage
Board Index
About Us
Downloadable Games
Free Browser Games
Games in Development
RPG Maker Support
Game Maker Support
Construct 2 Support
HBGames the eZine
Advanced RPG Maker
Site Announcements
Powered by phpBB © phpBB Group