How do you handle common events?

[Liak]

As you know, common events can be triggered from other events. And often times, I wonder whether or not a specific part of my events should be externalized into a common event that I then simply call. I have always been afraid to have common events all over the place, common event after common event, maybe even 1-liners. So, in other words: I don't really think that every command that occurs in more than one place should be made into a common event. The advantages are obvious: You become more flexible. Want to change the sound effect that plays when getting an item? Change 1 line in a common event instead of 1 line in every event on the map where you receive an item. The disadvantages: You will need a whole bunch of common events for all sorts of things.

So, I would like to know how you handle it. Do you have, like, some rules what to create common events for and what not?

 

[Tsumeshi]

Well, common events are meant to be used a LOT. An example is when you have a game mechanic like a boulder in the way that you can move with a key item.

 

[Liak]

But where does "a LOT" start?

 

[Galenmereth]

I do a lot of software development in my freelance job, and I'm a fan of the DRY approach (Don't Repeat Yourself). It's not applicable all of the time, but in most cases it's better not to repeat a function, because once you need to change it, you have to change it everywhere it pops up.

If I have an event that does the exact same thing more than one place, I make a Common Event of it. But I often group multiple repeating events together into one Common Event and use variables and/or switches to choose the appropriate one. This can help in terms of logical structure and also creates less clutter. But it's situational, of course; having too much in one common event is also a bad idea both in terms of complexity and ease of errors creeping in, and in terms of readability.

 

[Andar]

You have to apply logic to that - getting too much done in a single common event is as bad as fragmenting your functions into too many CEs just to re-use part of them from different places.

You can't give a single rule that applies to every project, because it depends on the project's structure where to break the functions into different CEs and where to combine them to keep everything at one place.

 

[Clord]

I use common events for example in hallways where something triggers instead of using narrow places to trigger something at a times.

 

[Zeriab]

Where to put the eventing logic is a design question with no definite answer. Instead rely on heuristics and gut feeling to guide you in where to place your logic and more generally how to design your events.
Remember that you have more options than simply placing the code in either a common event or in normal events. You can also have some code in the map event and some in a common event. You can have common events calling other common events.
There are a couple of heuristics which you may find useful in some cases:

• DRY - Don't repeat yourself
• KISS - Keep it simple stupid
• YAGNI - You aren't gonna need it

Understanding how common events works is also important. Good knowledge of a tool helps in its use.

*hugs*

 

[Shaz]

When I'm deciding whether to use an event or a common event, the two related questions I usually ask myself are:


1. How often will this segment of code be used / how many events will call this common event?


2. If I set up all of those events and DON'T use a common event, and then I want to change something, how painful is it going to be?


I'll use a common event if I have a small number of events that do a lot of processing (the same processing), or a large number of events that do even a little processing. If it's some sort of behaviour or sound effect that I want consistent across the game, I'll use a common event.


I do a lot of Call Script commands if I want to do anything special with event ids or self switches, just so I can use a common event instead of individual events with the same or similar code.

 

[Archeia]

It highly depends and to add (or reiterate?) what Zeriab is saying, I usually use Common Events on things I'm going to do repetitively or for skills.

Here's some examples:

• I have this script that stores the item/weapon name and the amount you got in a variable. Then calls a common event. Saves me a lot of trouble instead of writing the same message for all treasure chests.
• Atmospheric Effects. For example, Sunbursts that are animated via pictures. And if I'm going to use them on different maps I just call that.
• Picture Notifications. Such as, "CHECKPOINT!"
• Random Item Event. Basically, if I have a harvesting grounds and the item you get is random similar to Atelier Iris or Mana Khemia. 
• Party Rearrangement. By this I mean, I have two POVs in my games so I have a common event that wipes out the previous party and stores their inventory and replaces it with the other POV's party members and inventory.
• Rumors in Bars. So instead of writing lists in pages I just put them on Common Events and call them.
• Region Checking. For skits.

 

[Liak]

The DRY approach sounds pretty good, but as soon as you have 2 potions you can find on the map (using the same CE) and you get rid of one of them (say, replace it with a Hi-Potion), the CE becomes redundant. So you're actually LESS flexible if things like this may happen.

 

[Galenmereth]

The DRY approach sounds pretty good, but as soon as you have 2 potions you can find on the map (using the same CE) and you get rid of one of them (say, replace it with a Hi-Potion), the CE becomes redundant. So you're actually LESS flexible if things like this may happen.

This is why you have to use common sense. Let's say you have a few common things that happen when you pick up items from the ground, like a sound effect and a message window showing the item you received.


You could create the events that give this item so that they first set a variable to the item ID you receive, then call a common event to display info about the item. The common event then displays a message with "You received \ii[$game_variable[x]]", gives your party that item and voila, you now have a common event for displaying a message every time you pick up an item, which isn't just restricted to one type of item.

 

[Archeia]

The DRY approach sounds pretty good, but as soon as you have 2 potions you can find on the map (using the same CE) and you get rid of one of them (say, replace it with a Hi-Potion), the CE becomes redundant. So you're actually LESS flexible if things like this may happen.

I think you misunderstood what I said but here.

 

[Liak]

Ah, now I get it. But that does only work with scripts or at least script calls in Galenmereth's way of doing this. But let's also move away from getting items. It was merely an example I chose, and obviously not the best one. Let's get more abstract here, because I can't think of any good example right now. I just wanted to point out that if I use the DRY approach when there's at least 2 occassions of the same thing in the game, I get a redundant CE once I remove one of the occassions.

And by the way, this topic is not only to help me figuring out a way how to do it, but also to just collect ideas from people. So, I would be glad to leave the centre of discussion (where I kind of see myself right now?). If I can figure out some neat way of handling CEs with the help of ideas posted here, fine, if not, it doesn't matter that much either. I'm interested in all the different approaches used. And the reasons behind them.

 

[Archeia]

DRY only works on things that are a lot more linear. Obviously logic will have to get in here and if it's logical to use DRY approach for other things. But DRY is a good advice as a whole. For example, calling message boxes. I don't use a script for those since I like to control my animation and have specific things to hide when people are talking. Let me get a visual example.

As opposed to this one that doesn't use DRY approach (VXAce Lite can't call Common Events unless you cheat using conditional branches):

 

[Celianna]

I use common events like Archeia; to initialize some sort of system that repeatedly gets used. In her case, she sets up her own window, and it gets called each time text is shown on screen.


I use it to handle all interaction with an NPC, from dialogue, to their portrait. Since my NPCs wander from map to map, I don't want to edit each and every single version to change something, so I simply have all events call the common event which will determine what happens when they interact with them.


This is what my regular NPC event looks like (for all NPCs):

The common event that gets called does a lot of stuff. It calls a bunch of other common events to: set up a custom portrait, show a beating heart, show blinking eyes, show dialogue specific to the location, time and day etc. One NPC gets about 20 common events (it's mostly the dialogue which adds up to the total). Here's what it ends up looking like once the initial common event is called:

(the heart is animated, and his eyes blink)


In the end, I use common events the most, especially when it comes to evented systems. They are probably the most useful thing to have in RPG Maker.

 

[Zeriab]

You can consider common events as chunks of repeatable code which can be called and used within any other event, yes including other common events.

When should you lift code into common events? How many repetitions?

How should you treat similar yet not quite the same situations?

When does the functionality of different entities evolving in distinct direction require splitting or removing common events?

etc.

I know this is rather vague, but I cannot give more explicit advice without a specific situation.

Give me a concrete example (demo) and I can give you concrete advice.

*hugs*

 

[Liak]

I don't have a concrete example, but an abstract one.

Let's say we have 3 lines of code. Line 1 and 2 are used by other events, and line 2 and 3 are also used by other events. Do we need 3 common events with each one containing 1 line of code?

If you're about to say: "No, no CE for just 1 line!", then how about we have 20 lines, with lines 1-15 being used elsewhere and 5-20 being used on different occassions. Do we need to split it into 1-5, 5-15 and 15-20?

Again, I'm just pointing out that you run into some problems (where there might not even be a definite solution to). And that in addition to deleting instances later on (making the usage of a CE redundant) or splitting everything up until you can't work with it properly anymore. It's just very vague often times, and you need to decide on each occasion what to do. I understand that, of course. But how do YOU deal with these inconsistencies and this vagueness?

 

[Galenmereth]

This is stepping into the realm of computer science and programming theory. DRY is a principle, not a be all and end all concept. You have to consider each instance on its own terms; modularity is a great principle, but it's not a solution to every program. At the end of the day, the most important thing is to work in a way that suits you, that makes your job of getting things done more efficient. Of course elements like performance and redundancy are important to be mindful of, but often it's more about preference: How do you prefer to solve your challenges? Your question is very vague and so my answer is equally so. I hope you get my point, however

 

[Celianna]

I don't have a concrete example, but an abstract one.


Let's say we have 3 lines of code. Line 1 and 2 are used by other events, and line 2 and 3 are also used by other events. Do we need 3 common events with each one containing 1 line of code?


If you're about to say: "No, no CE for just 1 line!", then how about we have 20 lines, with lines 1-15 being used elsewhere and 5-20 being used on different occassions. Do we need to split it into 1-5, 5-15 and 15-20?

How many lines of code there is in a common event matters not.


Well, maybe it matters, if there's many lines of commands you may want to split it up to organize it better. But for one line only? Why not. For example, I have a common event that has only one line; it changes a variable. It gets called when an item is used. So yeah, go nuts, make tons of common events if you want.


If you end up with 100 common events, well, I don't see that as a bad thing (I have over 100).

 

[Archeia]

I don't have a concrete example, but an abstract one.

Let's say we have 3 lines of code. Line 1 and 2 are used by other events, and line 2 and 3 are also used by other events. Do we need 3 common events with each one containing 1 line of code?

If you're about to say: "No, no CE for just 1 line!", then how about we have 20 lines, with lines 1-15 being used elsewhere and 5-20 being used on different occassions. Do we need to split it into 1-5, 5-15 and 15-20?

Again, I'm just pointing out that you run into some problems (where there might not even be a definite solution to). And that in addition to deleting instances later on (making the usage of a CE redundant) or splitting everything up until you can't work with it properly anymore. It's just very vague often times, and you need to decide on each occasion what to do. I understand that, of course. But how do YOU deal with these inconsistencies and this vagueness?

I have one liner CEs because I can't put them on skills nor do I really feel like putting scripts for notetags at times. Are you talking about stuff like this?

Because there is nothing wrong with One Line CEs.

You also don't have to delete instances or split codes for Common Events and stuff. I still turn on and off switches even when they're in a batch CE sometimes. That's very rare though.