Large event sheets and perfomrance

Sorry if this is posted somewhere else, I couldn't find anything on it.

Will a large even sheet (say more than 1-2k events) negatively impact performance? Would it be better to split my event sheet into multiple sheets and include the ones I need for each specific layout?

Thanks!

1-2k events? Holy cow man, what are you making?

I don't think it would make any difference. I've gone over 1,000 events in my project, though it is down below 900 now after removing some stuff. Of course, it'll probably be back above 1k when I finish.

I don't see any reason to spread them across multiple event sheets unless you want to for organization. It'll still be the same number of events.

I like one big sheet with things put in groups because it is easier for me to maintain than jumping back and forth between a dozen event sheets.

If spreading it across multiple event sheets makes it easier for you to manage performance (like you said with including event sheets per layout) then do it.

All that matters is how many events are active and how many are affecting performance. Whether you do that with everything in one event sheet or spread across multiple ones doesn't seem to make any difference to me. Be more concerned with the total number of events that are eating away at your resources and need to be optimized. Groups can be enabled/disabled within an event sheet, and there are sometimes better ways to write your events to be more efficient.

crypticblonde

1-2k event's are not that many if you think about it. My small - medium small games are around 500-700 events (without event repetitions).

But it all depends on the way you make them. One will use 20 event to move sprite forward, other one will use only 2 event.

jlwinn8

It's always a good idea to split your code (groups, evens sheets, different variable values...) mainly for your own sake. It's easier to maintain and find what you are looking for if your events are nice and tidy.

As of the initial question, I would say yes. You can always include a event sheet (or turn on the group) only for stuff you want to happen. If something is not needed at current time in the game there is no point making C2 run through all of these events

to add to shinkan answer it also helps having separate groups/event Sheets to be able to debug events that slowing your game

I have almost 4000 in one sheet in my current game, not all of the events are being checked every tick though. If I remade it I'd probably be able to cut down the size by 20-50%. It's probably hindering performance on bad computers but I haven't done much testing yet on computers that are less powerful than an i3.

Event count should not effect performance, unless every event is actually being checked. The profiler will tell you all you need to know about event sheet performance. And having them on one event sheet vs multiple will make no difference.

1-2k events? Holy cow man, what are you making?

It adds up quickly! I'm sure I'm not doing this super efficiently, but I'm bound and determined to finish this one through the end rather than starting over because I can do it more efficiently. It's mainly dialogue that's iterated across many different characters.

To everyone else, thanks for the responses. I'm going to go back and take a look at events that are running every tick and see if those can be written differently.

I have 1,900 Events in my game right now and I have very good performance even on lower end (modern) computers.

Of course all the events are not running all the time, I think that's key.

First: every trigger does not count (apart from false trigger like on collision or on gamepad button pressed I think), they are not checked every tick, they just happen (it may be implemented to be a check but it is unlikely for things like on start of layout or on called function or even on created and on destroyed for exemple), so they are unlikely to slow anything down.

Then every event that is not a trigger will be checked by the order of the conditions, when one is false, the next ones will not be verified, so in reality most of your events should not be doing as much as you think they are, also just checking a good chunck of values (like some conditions that are easy) may be quicker than checking a small amount of collisions, so the overhead of the event existing by itself is not something that problematic.

For good measure, I suggest the following:

• think about the interactions before trying to implement them, if you do not know what you want to obtain exactly, your implementation can be dodgy, hard to read again, and not as clean and fast as it might be, if you know exactly, just implementing it can be a matter of seconds in some cases
• When something is prone to be repeted over and over, try to use a function to simplify things and make it easier to edit and use (for exemple, a function that will make a dialogue display appear, with the wanted dialogue), project files might be a nice idea to store a lot of dialogues inside texts files.