Is efficiency important?

All,

I'm not much of a programmer, so thankfully C2 is here to help. That said, this question is for the experienced programers out there.

Let's say you have 3000 events and things work great. What (if any) would be the advantage of cutting those events down to 2000, if the end result would be just as before - things work great?

Thanks!

You might want to read our blog post Optimisation - don't waste your time. If you're already getting 60 FPS there's not much reason to optimise, and even if you wanted to optimise, rendering is the best place to start.

There's efficiency, and then there's "wtf, how did you get to 3000 events?"

While the game may run with a lot of events, the time spent setting up so many events might be quite questionable.

Especially if you were to want to edit said capx at a later time.

So best advise, if you see a more elegant way to set something up, you should try to figure it out as best as you can.

If your game is complex, rendering might not be the only problem. Anything involving intensive loops will heavily impact performance. The events that you should be particularly careful with are ones which are computationally expensive, and are called every frame. For example, a loop that iterates through 500 sprites every frame, and then checks collisions with each one against 4 objects. You should absolutely try and optimize events like these, because "1" simple expensive event like that might cut your fps in half if left unoptimized. It's not the number of events that matters, it's those which are expensive, and those which are called every frame.

"Things working great" is entirely platform specific, so those 1000 events you removed might not have an impact on a fast machine, but you'll notice a difference on slow hardware.

You see, each machine has a critical point where your events (or game engine: i.e having too many objects existing at once) start using too much cpu time, and it drops below 60 fps. Any optimizations made when above this point are unnoticeable, because 60 fps is the same as 100 fps, or even 1000. Your screen only runs at 60 fps (most do), so anything faster is not noticeable, in practical terms. But once you drop under 60, the game is "lagging", and isn't running at full speed. If you develop on a fast machine, the critical point may be so high that you're unable to see any poor performance, even if your code is horrendous. Switch to a slower machine and you might see a difference.

I've got 10,000 events in loot pursuit. Still runs smooth.

Good advice has already been given - there are lots of ways to optimize, some events like collision detection take up more cpu time, etc - but I want to bring your attention to wisely using subevents and groups. A big part of the reason that loot pursuit plays smoothly even with about 7,000 events in one layout is because construct is skipping over most events each tick. For example:

mode="action"

• game subevents

mode="paused"

• paused subevents

If mode="paused" all of the game logic is skipped without you needing to disable any groups or anything.

If you structure your code right, thousands of events won't matter.

Thanks guys! This is great!

Don't forget using power of 2 textures intelligently. IE, a 256x257 sprite will be read on the gpu as 256x512--double the vram use. For many games this won't cause much of an issue, but larger graphics can be taxing.

One nice way of cpu optimisation (particularly for loops), is consider how often it REALLY needs to be checked. Do those collisions need to be check every tick? Or would every 10 ticks be sufficient? Simple changes like that can have drastic framerate results on slower machines.

The most important points on optimisation are already posted. I just want to point to an additional argument that is most often underestimated. You asked if there is any advantage in reducing from, say, 3000 to 2000 events, even if everything is working as before, game-speed-wise. There is! The leaner your event sheets the lower the risk of losing overview. You might not be able to maintain your game with redundant or not-so-optimised events.

Let's say you have quite a few events for the movement of the player char. You can of course enter those events over and over again, wherever they are needed. But if you create a function instead and call that function wherever needed, you gain massive programming advantages. For example, if a change is to be made you only need to change once. Just that one function, no matter how often you use it in the event sheet.

And if you put those functions on their own event sheet and include it into each layout where it is needed, it is again a lot easier to maintain the code.

In addition, add comments as much as possible and enter a description for your groups. You might think that you know what the groups are for or those special events do. But if you release the game, work on something else and then later need to go back to the other game, because players reported bugs, you might not exactly remember.

In short: Less and good commented code = better maintainability

tulamide has excellent advice