Performance question

viking

I am making a game and I am starting to dip below 60 FPS and therefore need to streamline my code, but I am not sure I understand the underlying structure of GS well enough to optimize it properly.

For example, I have a lot of logic in a ball actor, which is partially necessary since I am accessing information about the ball physics, collision with other actors etc. But not all the logic I currently keep in the ball actor must be kept there since I am using game.attributes which means that the logic can be placed in any actor in the scene. I keep the logic in the ball actor because it is easier to organize it that way.

However, should I try to keep the ball actor as lean as possible and instead put this logic in another actor?

Does moving the logic change anything?

I was under the impression that GS runs my project 60 times per second and that every actor is updated 60 times per second no matter what. But I wonder... The ball actor is the only actor moving in the scene and could potentially become a bottleneck so I could imagine that keeping this particular actor as lean as possible would give me a performance boost. Anyone knows if this change will have an effect one way or the other?

Socks

@viking said:
My ball actor has more than 54 rules in it, so I don't know if it would be practical to share the logic on the forum.

The very fact that it as 54 rules makes it a likely candidate for optimisation. You'd be surprised at the various tricks and techniques you can use to slim down code, with such a large rule set I suspect you'd get various suggestions from a range of people. But I agree 54 rules is a lot of screen shots !

@viking said:
I will try to ask the question differently: I thought that every actor was scanned on every frame. Is that correct? If it is not correct, then how can I prevent an actor from being scanned?

Yes, every actor in the scene is scanned on each frame.

The second part of your question makes less sense - it says 'if it is not the case that every actor in the scene is scanned on each frame - then how do I prevent an actor from being scanned' . . . . . ?

The two ideas don't seem related (to me at least) !?

You can prevent an actor from being scanned in all sorts of ways, only spawning it into the scene when needed, placing conditions at the top of its rules that define when it is scanned (a crude example - an actor with 1,000 rules and behaviours - that starts with 'when game.time>600' won't even be looked at (past the first condition) for the first 10 minutes of the game), you can prevent an actor (an actor's code) from being scanned based on just about any condition you can imagine - from the angle the user is holding their iPad to the distance of the actor to the hero.

A typical example of this last method (distance of the actor to the hero) would be a massive scene with hundreds of actors, each with complex rules, but they only spring into life when they are near enough to the hero (and camera focus) to be seen on screen, when they are off screen they are dormant with none of their rules triggering, so even though you have a massive scene with - for example - 400 actors - only the 12 that are on screen are using up processor cycles, the other 388 only have a simple magnitude calculation at the start to scan, after which they are ignored.

Socks

There's too little information to go on here, but generally speaking if a bunch of code needs to be scanned on each frame draw its location within the code's structure won't make any difference to the overall performance, although it might effect communication within the structure.

I was under the impression that GS runs my project 60 times per second and that every actor is updated 60 times per second no matter what

GS can drop below 60fps when overloaded.

The ball actor is the only actor moving in the scene and could potentially become a bottleneck . . . .

Why would the ball actor become a bottleneck ? And how is its movement related to this ?

so I could imagine that keeping this particular actor as lean as possible would give me a performance boost

What would cause the performance boost ?

Maybe post the rules for the ball and so people can make optimisation suggestions ?

viking

Thanks @Socks.

My ball actor has more than 54 rules in it, so I don't know if it would be practical to share the logic on the forum.

I will try to ask the question differently: I thought that every actor was scanned on every frame. Is that correct? If it is not correct, then how can I prevent an actor from being scanned?

The_Gamesalad_Guru

Any range between 56 - 60 is normal range of performance. Especially if it's up and down between those numbers. If an actor is on the scene they will be scanned. The idea is to find way to integrate that code. That process is a learned experience and hard to explain. The best way is to combine duplicate processes. Say for example collides. No need for 20 collide behaviors in an actor simply group them all under one tag and then select collide with tag. That's a very simple example.

viking

Thanks guys!

Socks

@Lost_Oasis_Games said:
Any range between 56 - 60 is normal range of performance. Especially if it's up and down between those numbers. If an actor is on the scene they will be scanned. The idea is to find way to integrate that code. That process is a learned experience and hard to explain. The best way is to combine duplicate processes. Say for example collides. No need for 20 collide behaviors in an actor simply group them all under one tag and then select collide with tag. That's a very simple example.

Yep, that's the kind of thing - iterated dozens of times, for every actor, checking for possible ways to slim down what each actor needs to do - that makes a difference.

Another example - a maze game - you have 160 actors making up the walls, when the player touches a wall he loses a point, it might be tempting to place a simple rule in the wall actor [when colliding with player, change points to points-1], but this means that condition needs to be checked 160 times on every code cycle, each wall actor needs to see if it is in collision with the player . . . . whereas if you place the rule in the player actor [when colliding with wall, change points to points-1] . . . you save 159 checks, the checks themselves will be incredibly fast, even for 160 actors, but it will make a tiny difference, add all these small improvements up and suddenly your game is running a few frames a second faster, which is often all you need.