[Solved] What is the best practice for launching common nested events?

r66r

Fantasy dreamer... sometimes.
Veteran
Joined
Jan 5, 2020
Messages
34
Reaction score
33
First Language
French
Primarily Uses
RMMZ
For example, you have the following configuration:
  • Common Event 1: a parallel process that must launch Common Event 2 if certain conditions are met (e.g. regular party status check).
  • Common Event 2: an untriggered event that performs certain tasks and launches Common Event 3 under certain conditions (e.g. updating an actor PVs according to a particular state).
  • Common Event 3: another untriggered event that performs certain tasks (e.g. launching a cutscene before displaying Game Over).
In this case, what is the best way to launch CE2 and CE3?

A. To use the "Call Event" command in each event?​
B. To use a global switch that triggers the event? And in this case, should CE2 and CE3 be parallel or automatic processes?​
C. A mix between them, depending of the context.​

The reason why I make such a separation between events is to make them easier to debug (less lines to check, execution of a specific task). But also to allow me to reuse some common events that are not triggered in other circumstances. If I take the example above, CE3 would allow me to execute a Game Over via CE1's parallel process, but could just as easily be called as the "defeat" branch of a battle command.

So I am particularly interested in your opinion. Thanks for your feedbacks.

Edit: Here is a summary of some of the recommendations received from @Andar and @Shaz present in this thread.

Common events: autorun
  • Avoid them as much as possible, unless specifically triggered by a global switch and that this one is deactivated at the end of the execution of the event, for a unique execution and thus not to block the game with an "infinite loop".
  • Do not use them with the "Call event" command.
  • Can only manage the global context data of the game.
  • Use cases as example: cutscene between map switches, ...
Common events: parallel
  • Limit them as much as possible (in general, one global parallel event should be enough to manage a simple game).
  • Ideally, trigger them with a global switch, which would allow them to be activated/deactivated according to the context of the game (for example, deactivate the event before a battle, and reactivate it after).
  • Use a "Wait frame" command to skip executing this event for x frames, unless a user action is expected, such as a key press or a mouse click.
  • Do not use them with the "Call event" command.
  • Can only manage the global context data of the game.
  • Use cases as example: master event that controls the global gameplay, timer or countdown event, processing of user input actions, ...
Common event: non-triggered
  • Use them as much as necessary.
  • Do not use a trigger with them.
  • Call them by the "Call event" command in other common events or in map events, or use them as common events attached to skills.
  • Can manage the global context data of the game, but also the specific data of the calling event in the current map, like self switches.
  • Use cases as example: any specific data processing that needs to be run only once depending on the current context (process after level-up, post-combat process, background or sound management, before/after map transfer, skill event, ...)
 
Last edited:

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
33,695
Reaction score
8,496
First Language
German
Primarily Uses
RMMV
A
always A in such a sequence.

You should keep the number of paralel processes as low as possible for a lot of reasons, and using switches for triggering additional parallel processes has several consequences. You can find some of those reasons when you follow the link "bughunting" in my signature.

Additionally, if you call a common event the called event gains access to the properties of the calling event. That would NOT happen with a triggered event. So if you call a common event from a map event, that common event gains access to the map event's self-switches.
 

r66r

Fantasy dreamer... sometimes.
Veteran
Joined
Jan 5, 2020
Messages
34
Reaction score
33
First Language
French
Primarily Uses
RMMZ
Thank you for the reply.

You should keep the number of paralel processes as low as possible for a lot of reasons
That's something I actually try to do. However, I had a case, with a local event and a "Call event" command, where the common event was started but abruptly stopped or not executed when the local event changed its status (I think I called the common event and then activated a local switch that started an automatic process on another page).

So just to be sure, with the "Call event" command, the execution of the called event's tasks is included in the calling event's process, but not executed in parallel, right?

In other words:
This:
Code:
#Start CE1
    do some stuff from CE1
    call CE2
        #Start CE2
            do what CE2 has to do
        #Stop CE2
    do some other stuff from CE1
#Stop CE1
And not this:
Code:
#Start CE1
    do some stuff from CE1
    call CE2 ---------------------------------->#Start CE2
    continue to do some other stuff from CE1        do what CE2 has to do  
#Stop CE1                                       #Stop CE2


Additionally, if you call a common event the called event gains access to the properties of the calling event.
I didn't know this notion of "inheritance" between events. It certainly brings an additional argument to the use of the "Call event" command.

Therefore, I guess I could create a common event where I call $gameMap.event(1).event(), and use it via the "Call event" command in different local events on different maps, and it will be the local event 1 of each map that will be impacted by the subsequent processing, right?

In other words:
Code:
# Code CE (*)
event = $gameMap.event(1).event()
event.moveLeft()
event.selfSwitch(A) = true

# Map1, LE3
call CE ---> Result: Map1.LE1 moves to the left and its selfSwitch A is activated

# Map1, LE6
call CE ---> Result: Map1.LE1 moves to the left and its selfSwitch A is activated

# Map2, LE2
call CE ---> Result: Map2.LE1 moves to the left and its selfSwitch A is activated
(*) figurative code and not to be used as is
 

Shaz

Global Moderators
Global Mod
Joined
Mar 2, 2012
Messages
43,367
Reaction score
15,179
First Language
English
Primarily Uses
RMMV
It depends entirely whether CE2 and CE3 are meant to run just once when called, or if CE1 is just telling them to start and after that they continue running until a condition is no longer met.

If they are meant to just run once and then return control to the previous CE, use the Common Event command. If they are meant to start and continue until another condition is met (or a current condition is no longer met), then make them parallel processes.

The issue with too many parallel process events can be reduced by adding a Wait 1 Frame at the start or the end of the parallel CE. In a lot of cases the wait can be even longer (consider 60 frames a second and how many times per second do you want this to run?)

I'm not aware of any situations, other than monitoring for the player pressing a button, that would require a parallel CE to not have any Wait at all.

A common event (or a map event) should never have an Autorun trigger unless you want to remove all control from the player while the event is doing its thing.
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
33,695
Reaction score
8,496
First Language
German
Primarily Uses
RMMV
However, I had a case, with a local event and a "Call event" command, where the common event was started but abruptly stopped or not executed when the local event changed its status
I can only guess what had happened in that case, but there is one thing you should keep in mind because that reallyhas the potential to mess up things:
called events should always have trigger = none.

There have been cases with MV where a parallel process event has been called, and that had some strange effects because that caused some strange looping of the CE independent of the switch.

But with trigger=none the call event command should work like a "gosub" in programming - stop the calling event while the CE is processed and return to the point of the calling event if the CE is finished.
 

r66r

Fantasy dreamer... sometimes.
Veteran
Joined
Jan 5, 2020
Messages
34
Reaction score
33
First Language
French
Primarily Uses
RMMZ
If I may summarize, the good practices would be then...

Common events: autorun
  • Avoid them as much as possible, unless specifically triggered by a global switch and that this one is deactivated at the end of the execution of the event, for a unique execution and thus not to block the game with an "infinite loop".
  • Do not use them with the "Call event" command.
  • Can only manage the global context data of the game.
  • Use cases as example: the only case I can think of is cutscenes (although it would be better if it was an autorun map event, I think).
Common events: parallel
  • Limit them as much as possible (in general, one global parallel event should be enough to manage a simple game).
  • Ideally, trigger them with a global switch, which would allow them to be activated/deactivated according to the context of the game (for example, deactivate the event before a battle, and reactivate it after).
  • Use a "Wait frame" command to delay their execution loop to skip executing this event for x frames, unless a user action is expected, such as a key press or a mouse click.
  • Do not use them with the "Call event" command.
  • Can only manage the global context data of the game.
  • Use cases as example: master event that controls the global gameplay, timer or countdown event, processing of user input actions, ...
Common event: non-triggered
  • Use them as much as necessary.
  • Do not use a trigger with them.
  • Call them only by the "Call event" command in other common events or in map events, or use them as common events attached to skills.
  • Can manage the global context data of the game, but also the specific data of the calling event in the current map, like self switches.
  • Use cases as example: any specific data processing that needs to be run only once depending on the current context (process after level-up, post-combat process, background or sound management, before/after map transfer, skill event, ...)
In conclusion: use only common non-triggered events as nested events, and call them mainly with the "Call event" command or as common events attached to skills.

Edit: some corrections according to Andar's answer below.

---
Please feel free to correct me if I made a mistake or forgot something. And if they can be useful to others, I might also edit the OP with these recommendations to make them easier to find.
 
Last edited:

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
33,695
Reaction score
8,496
First Language
German
Primarily Uses
RMMV
Use a "Wait frame" command to delay their execution loop, unless a user action is expected, such as a key press or a mouse click.
Not exactly - but to understand this someone needs to know how the wait command really works.

All events are basically processed inside a game loop that gets processed once per frame.
Inside this game loop, all the wait command does is saying "skip executing this event for x frames".

In a regular map event on action button, this will look to the player like a wait.
But in any parallel process, this will make the parallel process skip executing for the number of frames, reducing the load on the processor and thereby reducing lag.

As a result, all parallel processes should have at least a wait (1) somewhere to reduce lag, most people go with a wait(5) or wait(10).
But the best number of waits can only be found by experimenting, because that depends on what the parallel process does. And there are two conflicting effects here.

1) to reduce the lag, the wait should be as high as possible without interfering with the function. For example a parallel process checking equipped weapon to change a sprite can have a high wait because the player cannot change the weapon sixty times a second.

2) if the wait is too high, the result might look to the player as lag even if it is not. If in the example above you have a wait(60) it can result in a delay of up to 60 frames (one second) which the old sprite still being there before the game change it to the new sprite, and that will look bad and be called lag by every player.

And the optimal number of waits can change while developing the game. Because if you add another parallel process later in the development process, this will influence the timing of the existing parallel processes. So don't bother too much with finetuning unless you're in the finishing steps of playtesting the complete game.

In conclusion:
you forgot the fourth option: common events attached to skills.
those are also non-triggered, but called automatically by skill use instead of manually by event command.
And some games use them extensely for interacting between the player and the map.
 

r66r

Fantasy dreamer... sometimes.
Veteran
Joined
Jan 5, 2020
Messages
34
Reaction score
33
First Language
French
Primarily Uses
RMMZ
skip executing this event for x frames
Thanks for the clarification, I will correct in my previous post.

So don't bother too much with finetuning unless you're in the finishing steps of playtesting the complete game.
Another good tip! :ehappy:

you forgot the fourth option: common events attached to skills.
Correct, I had forgotten this use case. But I think the advice given for common non-triggered events applies in this case too, right?
 

Tiamat-86

old jrpg gamer
Veteran
Joined
Dec 5, 2017
Messages
916
Reaction score
395
First Language
english
Primarily Uses
RMMV
map autorun cutscene(CS), better when its a CS takes place only on that map.
the autorun common event CS, better when CS switches maps mid scene.

example A: mapA turn in quest CS > MapB "meanwhile" show another group CS > MapC goes back to main party "sometime later/next day" CS > resume normal play.

example B: reminiscence CSs. often seen as ending CS, just before a main character dies, or just after a major storyline event. these CSs often cycle through almost all storyline related maps in chronological or reverse-chronological order from when the 2 relevant character met till just a few minutes ago.
these CSs are meant to give the player more attachment to the characters (beware of potential upcoming "makes me wanna cry" moment) or just incite memories of the game itself (beware of upcoming end credits).

edit: ive had issues a couple times when made multi map CSs with non-triggers.
the issues seem to be related to the game trying to priorities a different autorun or parallel event on a map. for some reason just changing it to autorun with a switch trigger fixed any issues i ran into.
 
Last edited:

r66r

Fantasy dreamer... sometimes.
Veteran
Joined
Jan 5, 2020
Messages
34
Reaction score
33
First Language
French
Primarily Uses
RMMZ
the autorun common event CS, better when CS switches maps mid scene.
Indeed, a case I hadn't thought of. Thanks for mentioning it.

It so happens that in my games, I replace this way of doing by a simple empty map of 2 or 3 tiles (no tileset) in which I add the autorun map event for one or more cutscenes. The advantage: the cutscene remains attached to the map (by default displayed on a black background), and can be called simply by moving the player on that map. This avoids me to manage the activation or not of a global switch, and makes it easier to follow the red thread of the story represented by the logical sequence of the player's moves on the maps... probably not adapted for an open world, but which suits me well for my rather story-driven games.
 

Latest Threads

Latest Posts

Latest Profile Posts

Hot chocolate and music make studying and note-taking much easier :kaoluv:
Until my hand cramps up from writing too much!
Doing RPG Maker News for 21st September 2021


Malak is still waiting for Dark Deception Chapter 4... This was him yesterday after another sugar crash.
Again, he's fine. He's just bored at this point, considering he's exhausted his entire vacation bucket list.
Am I the only one who files custom resources under specific folders to remember who to credit? :kaoswt2:
1632263519730.png
I always smile to myself when I see someone do the "immediate halt and spin around" from forgetting something. I find it sort of endearing how we all do it without ever being taught to.

Forum statistics

Threads
115,265
Messages
1,088,456
Members
149,869
Latest member
ekqul
Top