Most CPU intensive behaviours?

3absh

Hey guys,
I'd like to know what are the behaviours that eat up the most RAM and cpu in GameSalad. I think it's very important to know these for the developer to find a way around them and make his game perform as good as possible.
I'm currently making a complex 1 scene RPG/puzzle which has tons of timers, particles and other behaviours which I believe to be causing my game's low frame rate while playing.

From your own experience, what do you think are the top 10 most cpu intensive behaviours?

The_Gamesalad_Guru

Gamesalad is working on all this. But the reason most games lag is becuase of bloated code. I use all the behaviors, timers ect. I have yet to have anything lag horribly. Most of my stuff runs at 57-60 fps. Slim, integrated code is the way to build a game with no lag. All these other methods only help those who build bloated logic. It's a bandaid on the main issue which is not understanding how to build proper logic.

I've been using GS for nearly 5 years. It took me about a year to learn how to build proper logic in GS. Since then I have never had lag issues.

Armelline

It's not really about which the most CPU intensive are, it's about how they're used. In your RPG, for example, do you have actors that are off screen that contain lots of logic, like your timers, that are running when the actor is off screen? That kind of thing will contribute to your lag far more than any specific behaviour.

zweg25

@Lost_Oasis_Games said:
Gamesalad is working on all this. But the reason most games lag is becuase of bloated code. I use all the behaviors, timers ect. I have yet to have anything lag horribly. Most of my stuff runs at 57-60 fps. Slim, integrated code is the way to build a game with no lag. All these other methods only help those who build bloated logic. It's a bandaid on the main issue which is not understanding how to build proper logic.

I've been using GS for nearly 5 years. It took me about a year to learn how to build proper logic in GS. Since then I have never had lag issues.

Yes, this is true, but for most it is actually due to big images and sounds. Slim code does help, but it is not the only thing that slows down FPS.

Franto

If you go into the actors folder, you can check what actors are taking up a lot of memory, and if most of that code is running, it can slow things down.

Although, of course, as you mentioned, some behaviors have a higher "cpu drain" than others, the more processing power a game takes, the greater the device/machine needed to run it smoothly. If the rules are setup inefficiently as well, this creates the perfect storm of a lagiriffic game. {An example of inefficient rules would be to have 10 different rules, each with say "facingright" as a condition they have in common. If you delete that condition, and make a new rule with "facingright' as the only condition, then drag the 10 rules you removed it from into the new super rule, you will cut down on computation time for the system, enhancing run speed. If you keep doing this until everything is organized, you will not only get the game to run super efficiently, but you will also remove any errors with something, like the "animate behavior" use to "glitch" on me and be stuck on a sprite, but before I could even "fix" it, after organizing the code, all animations worked as originally intended, due to being within close proximity of their related animations, leading to instant switches between animation, as well as rubber banding back to any intended sprite such as standing still, instead of being stuck on "run" or "jump" animations.}

For example, older versions of my game where so inefficient, that they could only run smoothly on a powerful computer, but on devices, would slow to a crawl with not only the framerate, but the actual speed of the game would go slowmo, with everything running at 1/5th the speed.

Basically, make sure to use the "else/otherwise" part of the rule to connect related rules, as well as the other part I mentioned of gathering all rules that share similar conditions, without repeating the condition under any other rule, under the same conditions, and running rules from there.

Because if you have, as in the earlier example, running 10 rules all sharing a condition within themselves, the system will keep checking them, creating a greater strain on processing power.

The_Gamesalad_Guru

@zweg25 said:

@Lost_Oasis_Games said:
Gamesalad is working on all this. But the reason most games lag is becuase of bloated code. I use all the behaviors, timers ect. I have yet to have anything lag horribly. Most of my stuff runs at 57-60 fps. Slim, integrated code is the way to build a game with no lag. All these other methods only help those who build bloated logic. It's a bandaid on the main issue which is not understanding how to build proper logic.

I've been using GS for nearly 5 years. It took me about a year to learn how to build proper logic in GS. Since then I have never had lag issues.

Yes, this is true, but for most it is actually due to big images and sounds. Slim code does help, but it is not the only thing that slows down FPS.

That is not true I just did a project where I animated image that was About 400x500 with nearly 400 frames and had tons of interpolates doing all kinds of stuff at the same time as well as timers to control everything and it ran at 56fps. the issue is people think their code is slim and it is not. I've seen this myself looking at others projects where they swore the code was slim. In my experience this just isn't true and I've been using this software for nearly 5 years. How is it then my projects, even doing everything that many would say are inefficient behaviors et.. I have no issues as to lag. Loading time are an issue on GS's end as we can't control that. But as to lag, it's all about your code.

Our game Puck it has play by play in it and has nearly 100 sounds and runs fine.