Is it worth reformating these schedule events? Would it improve performance?

[KingHazeel]

Basically I have several schedule parallel process events that move NPCs around depending on the time of day. The event starts by placing or removing the NPC depending on the time of day when the player enters the map. The event then switches to a new page where it acts as a parallel process and waits until a certain time passes before having the NPC move indoors or outdoors. It then switches to another new page and waits again for another certain time to pass. The event is reset to its default state whenever the player transitions to a different area. This is the event as it is:

https://i.imgur.com/Abq9ZKK.png

Ignore page 4. That just turns off the event since the NPC's schedule will eventually change. Anyway, I have roughly 13 of these parallel process schedule events running in the main city map. Currently I'm noticing any lag, and the events are working fine as is, however I've recently considered another way I could run these, mostly relying on switch/variable checks instead of checking with a parallel process. This is what the alternative method would look like:

https://i.imgur.com/qCWXieG.png

Would it be worth it to change all schedule events to look like this? Would it significantly decrease the risk of lag or otherwise boost performance? Or would any changes be insignificant compared to the current method?

 

[Bex]

I dont know, i cant grasp the whole of it and how it reacts with Engine, if it works its good to use, i just have the feeling there could be an easier solution.
The amount of parallel Events running all the Time could make some problems if you add more other performance sucking stuff later on.
For PC this might even be ignorable, for Browser or App Game this could cause problems (Untested, just a Theory of mine).

The Paralell Event, if i get it right, 1st Page is when map is entered first time, after that only page 2 and 3 are changing after they run on paralell for some Time.
I would try to make1 Eventpage out of that 3. Than i would try to include all 13 into that 1 Event.
Make a backup Copy, you dont want to kill the existing working mechanic, just in case we run into a dead end or other Errors.

 

[Engr. Adiktuzmiko]

If you already have a time system in place, #2 makes more sense as it runs using your time system..

To reduce number of events though, you can combine the controller event of multiple events into one assuming they move at the same time.. Like if 2 NPCs move at 9:00, control them both using just 1 of those events instead of having 1 control event per NPC.

You can also opt to try to use just 1 control event for all NPCs in the map via utilizing Conditional Branches that checks the current time value. This would be optimal in terms of reduction in the amount of events present in the map.

 

[KingHazeel]

To be honest, I'm not 100% sure I could pull this off with a single event since I would need to be checking if the NPC is coming outside or returning home. Trying to combine events when possible seems like a good idea. I'm just wondering if either "type" of event would likely have better performance.

 

[Heirukichi]

To reduce number of events though, you can combine the controller event of multiple events into one assuming they move at the same time..

I wholeheartedly agree with this. Those events do not look inefficient to me, they do exactly what they are supposed to do and do it without extra loops/commands. I would simply use a single event to handle them all. Of course, depending on how they are placed in your map, you could use a script to move them using regions instead, that would help a lot when it comes to reading the event and making a path.

 

[KingHazeel]

Hmmm...maybe I'm making this out to be more daunting than it is. I suppose I could just have page one of the event place all the NPCs as is...with page 2, I was concerned with the schedule repeating itself and/or skipping schedule events, but as long as I place the events beforehand, that should handle any skipping. As for repeating...maybe have a variable update itself as an "old time value" and only check the schedule when the current hour doesn't match the old hour, otherwise a character would be repeating their schedule until the hour passes. I'll try that when I get home.

 

[Bex]

If you have trouble executing the event only 1 time when the hour is met, and not again and again until the next hour is reached,
than 1 Variable and Conditional Branch can help.

Your assumed code now:
Condition if time is between 5 o clock and 8?
if yes, do stuff (sadly this is repeated again and again until the hours are over.)
end
Condition if time is between 9 and 10 o clock?
if yes, do stuff (sadly this is repeated again and again until the hours are over.)
end

Here a possible solution, the code only executes 1 time when the correct time is reached, thanks to a second conditional branch and a control variable command:
Condition if time is between 5 o clock and 8?
-Condition Variable1 is not equal 1
if both yes, Control Variable1 set to 1
do other stuff (now it doesnt repeat anymore)
end
Condition if time is between 9 and 10 o clock?
-Condition Variable1 is not equal 2
if both yes, Control Variable1 set to 2
do other stuff (now it doesnt repeat anymore)
end
and so forth.....

Edit: Sorry didnt have much time, hope this explanation is understandable, else just ask.

 

[Heirukichi]

I would do that differently, like defining a path and taking it step by step, in the same way the engine updates events all together, you can update one step for each event. The obvious disadvantage is that you have to plan a path for each event beforehand, the equally obvious advantage is that there is no need to avoid checking multiple times: if the path is completed there is no step to do so that particular event is not going to move.

Either a list or a path drawn using regions might work toward this goal. A list is easy to handle and you can check if it is empty or not, a path drawn using regions requires an ending point, but it is equally efficient.

If we call N the number of events in your map, we can compare the efficiency of those two methods.

Using a list, the cost for each single step is O(1), which means a total cost of O(N).
Using regions, the cost for each single step is O(4) (because you have to check which adjacent square has the correct region ID) and the total cost is O(N*4) = O(N).

While the region solution has a multiplier of 4, its complexity is still O(N) so both solutions are good solutions. On top of it, the engine already handles events with a linear algorithm, adding this to how the engine handles them does not affect the overall complexity at all. That said, it is true that the solution that uses regions comes with a slightly slower algorithm, but it is also true that it is much easier to edit later on since you can just draw regions on your map.

 

[KingHazeel]

OK this is what I tried. Page one is more or less the same. Just combines all the other NPC set ups and ends by setting an "old hour" value.

https://i.imgur.com/z6wlbT7.png

Page 2 is just a schedule for each of the 24 hours. It only checks the schedule when a new hour has passed (current hour != "old hour") and then updates the old hour. If anyone has a scheduled event at this time, it activates that. If the current hour is the same as the "old hour" the event just waits for 60 frames before checking again. Hopefully this is a better way of managing things:

https://i.imgur.com/Y7N0qe6.png

Although right now there are a few concerns I have with the schedule.

1) One of the NPC's schedules is a bit more complex and requires letting the NPC's move route be set on wait, which I can't do here or it'll hold everything up. I'll just have to give him his own individual event. Not a big deal, I think.

2) This only really bugs me because I'm a perfectionist, but at the moment, the player could theoretically block an NPC for an hour or so and then the NPC's next schedule will have them teleport to their house and retrace back their default position. A small issue, of course, because really nobody's going to do this...but I think I can fix it all the same if I add more conditional branches (God help me.) to check if the NPC's D switch is active before having them change locations.

3) ...I really wish I could scroll to the right in event pages. |'D My current work around has been making the event in Common Events and then pasting it, since Common Events has more width to work with...though it's far from ideal.

Still, this should allow for better performance, yes?

 

[Heirukichi]

First of all, your first image has a lot of conditional branches, but the condition for all those branches looks the same. Just put all those self switches in a single branch. I recommend doing it this way (so that you can change it easily later on):

scheduled_events = [42, 43, 44, 45] # you can add or remove them as you please
scheduled_events.each { |i| $game_self_switches[[$game_map.map_id, i, 'D']] = true } # or false

Instead of using "Wait 60" you can use the following script call:

t = $game_clock.instance_variable_get(:@time) % HCK.phase_length
t = HCK.phase_length if (t == 0)
wait(t)

It is not a standard VX Ace method, but since you are using my script you can use this. It calculates how many frames are required before the clock advances to the next phase (30 minutes interval) and waits the same amount of frames. After all there is no need to check if it is time for a new phase if you are sure the phase did not change, is it?

This would definitely improve your performance as it greatly reduces the number of times the event runs. Assuming you are using the default configuration, it takes 18000 frames to complete a phase, if you wait 60 frames you check it 300 times before it actually changes. Among those 300 checks only 1 of them is actually useful. Using the code above would completely eliminate those extra 299 checks (they can be less or more, depending on how you configured the script), I think you can see on your own how it brings a huge improvement.

One of the NPC's schedules is a bit more complex and requires letting the NPC's move route be set on wait, which I can't do here or it'll hold everything up. I'll just have to give him his own individual event. Not a big deal, I think.

You can just set "Wait for Completion" to false though, the event will proceed with other move routes. On top of it, once you set a move route for events, you can simply use a normal autorun event that is triggered by a self switch and switches back to the old parallel process. There is no need to set up a move route more than once.

This only really bugs me because I'm a perfectionist, but at the moment, the player could theoretically block an NPC for an hour or so and then the NPC's next schedule will have them teleport to their house and retrace back their default position.

Set events "Through" flag to true during their move route so that they can pass through the player and go home.

...I really wish I could scroll to the right in event pages. |'D My current work around has been making the event in Common Events and then pasting it, since Common Events has more width to work with...though it's far from ideal.

I feel your pain. That is one of the reason why I always go the hard-code way. I can edit the code in a text editor and then copy/paste it there.

 

[KingHazeel]

First of all, your first image has a lot of conditional branches, but the condition for all those branches looks the same. Just put all those self switches in a single branch. I recommend doing it this way (so that you can change it easily later on):

scheduled_events = [42, 43, 44, 45] # you can add or remove them as you please
scheduled_events.each { |i| $game_self_switches[[$game_map.map_id, i, 'D']] = true } # or false

Yeah, I can definitely combine some of those, though it doesn't seem practical to set it up the same way I did the rest of the schedule since there would be a lot of repeats depending on the time.

Instead of using "Wait 60" you can use the following script call:

t = $game_clock.instance_variable_get(:@time) % HCK.phase_length
t = HCK.phase_length if (t == 0)
wait(t)

It is not a standard VX Ace method, but since you are using my script you can use this. It calculates how many frames are required before the clock advances to the next phase (30 minutes interval) and waits the same amount of frames. After all there is no need to check if it is time for a new phase if you are sure the phase did not change, is it?

Thanks!

You can just set "Wait for Completion" to false though, the event will proceed with other move routes.

That's how I handle most of them. However this particular NPC schedule involves said NPC heading to his boat, getting on, and then sailing elsewhere until he returns in the morning. It involves two events being scheduled together and only being activated after one finishes. I could have the event wait a set amount of time being being activated, but the time it takes the NPC to reach the boat will vary, unless I make all the NPCs through during transition periods (which I'm trying to avoid because I'm picky that way). Still, having only two schedules to worry about is a massive improvement over 13, I'd think.

On top of it, once you set a move route for events, you can simply use a normal autorun event that is triggered by a self switch and switches back to the old parallel process. There is no need to set up a move route more than once.

I think I must be misunderstanding you. An autorun would pause the player, no?

I feel your pain. That is one of the reason why I always go the hard-code way. I can edit the code in a text editor and then copy/paste it there.

You mean do the whole thing in script? Hmmm that is tempting...

 

[Heirukichi]

I think I must be misunderstanding you. An autorun would pause the player, no?

Movement routes are defined as part of the Game_Character class. Once you store them they are automatically executed when the character is updated (which happens every frame). If you do not set the "Wait for completion" flag to true, you can only run the autorun event once, then go back to the parallel process event.

Running it once is enough to store all those move routes, the engine then ensures that those move routes work properly, updating them when their respective character is updated.

You mean do the whole thing in script? Hmmm that is tempting...

A long script call or a script, pick the one you like the most. I think that a big script call might be better here, but using a script does basically the same thing.

Talking about the character that has to ride a boat and whose path is variable, This is one of the many reasons why, in one of my previous posts, I recommended using a different approach and having your characters move one step closer tot their destination. Doing it that way is not as easy as designing a simple move route, but ensures that they always find their way to their destination, and allows you to handle them all in the same way.

However, while this makes handling them easier, it does not affect performance. The player cannot see how you wrote the event. As long as you know what to edit and why, you should be fine using them this way.

 

[KingHazeel]

Yes, so if I'm correct, it's basically just creating multiple paths and picking whichever one is suitable at the time. Really, the only real obstacle so far is the player being a jerk and blocking the NPC...which ironically will only happen when it's me trying to break the game. XD I don't know what the full execution is, but I'm not sure if multiple paths would deal with that--even pathfinder can have trouble if the player is persistent or wiggle room is limited.

...On a semi-unrelated note, I wonder if there's a script for NPCs to sorta shove past the player similar to Stardew Valley

 

[Heirukichi]

it's basically just creating multiple paths and picking whichever one is suitable at the time.

Yes, you are right, for that particular event you should create a set of different move routes and just pick the most suitable one depending on the event current position.

the only real obstacle so far is the player being a jerk and blocking the NPC

Not really, if you set the through flag to true whenever the move route starts, that is no longer a problem. Keep in mind that you really should set it to true, otherwise the player might stand on the final destination of the event and prevent it from completing its move route. It can be done with malicious intent or without it, it does not matter, the point is that as long as they can be blocked it does not work properly.

 

[KingHazeel]

OK I think I've sorted things out. I've managed to mostly included schedules into a larger event and significantly reduce the number of events. There have been a few exceptions where I feel the event really needs to wait until it gets to its destination--i.e. interacting events or confined areas with multiple NPCs--but at least for the main map, I've reduced it from 13-14 parallel process events to 2 and now have a more appropriate waiting time. Thanks for the help!

 

[Kes]

[closed]IgnoreMe[/closed]