What is the best practice of spawning 'invisible' logic managing actors

rotor

I am working on a system which spawns in numerous managers that manage simple or complex tasks. One manager may spawn up to 3 other type of manager, and overall I may have up to 6 or 7 managers active any all time.

I was wondering what the best practise is for setting default attributes for these actors each takes up minimum resources.

The_Gamesalad_Guru

Turn off moveable and set density, friction and restitution to 0

rotor

Thanks, I did that now.

I was wondering, since these actors require blend functions, size and other visual attributes, is there any optimisation to be gained by spawning these outside of the camera view?

ORBZ

Turn off visibility in graphics for those actors then the rendering engine skips them entirely.

Also, once you unset movable there is no need to bother with the other physics properties like density, etc. when the movable flag is off the physics engine ignores that actor.

lanmind

@orbz out of curiosity how did you know that the physics engine will ignore a non-movable character?

I know that's common sense logic but I'm not finding as many resources as I'd like about GS.

rotor

Thanks ORBZ!

@Ianmind, yeah, I agree, maybe we can gather more optimization tips and tricks and some some one from the development team to do some myth busting in this thread!

The_Gamesalad_Guru

It's not true that it ignores it. Do a simple test. Make two actors collide one movable and one not and set the bounciness higher on the non-movable actor. You will see it get's bouncier. This is because those attributes control how two actors interact not for influencing their movement.

Here straight out of the CookBook definitions.

Density: Density refers to the heaviness of the actor. A higher value will make the object harder to move by less dense actors. A value of 0 will make an object immovable (but still affect other actors in the scene.) Density can be set to any real positive number. (i.e.Density>= 0)

People say stuff like they know and most times they don't. There is more miss-information that floats around the forums and becomes fact.

rotor

People say stuff like they know and most times they don't. There is more miss-information that floats around the forums and becomes fact.

Yeah, that's mostly due to a lack of technical documentation. That's why it's good to have some of the devs do some Myth Busting It would be great to have some more observations people have made that help optimisation!

The_Gamesalad_Guru

It seems most people want this stuff step by step but most of the information is there you just have to read the materials. I see this all the time even with iTunes connect as apple has well documented it but people don't bother to read the iTunes guide.

lanmind

@FryingBaconStudios You are absolutely right that many people want step by step instructions to build many things in GS. At the same time though there can be more documentation and thorough explaining of many aspects of GS.

For example there are many video tutorials that include statements being edited in the expression editor. Sure lots of it is simple math etc but to the beginner user who's never written any code those statements can be quite confusing. Maybe that's part of the reason why many people are requesting guides on everything they build with GS.

They see these confusing statements, functions & other coding terminology and really have no idea how to create their own. So they copy from tutorials and ask for more when there's a feature they want in their game but no tutorial on it.

I think it'd be very useful for GS as a whole, the company and the community to point other users to beginner guides elsewhere to help them understand logic behind what's going on in GS and the terminology being thrown around.

The average beginner has no idea that there is an "if" statement out there in programming languages or what a function even is. Not to mention the correct syntax that is required in the expression editor. How are they supposed to ever do their own developing beyond basic dragging and dropping?

I do very much enjoy Gamesalad but I think there could be better education about it.

@rotor I'd very much like to gather optimization tips & tricks. I'll see what I can think up and post them here soon

rotor

My personal experience with GS is that it's very designer and user friendly. And I literally got into in a matter of hours.

But as an advanced scripter with a lot of experience scripting and system designer in other languages there are many things I encounter that are specific to GS that I need to figure out finding disjointed on the forums or through extensive testing with the debugger. It just worries me that I may run into unexpected bugs because I'm lacking a more indepth official version of what's going under the hood.

I don't think that a technical documentation would shy off beginning users, but it would be all the more helpful for those of us with a technical background and commercial ambitions.

ORBZ

Well yes, technically the non-movable actor still participates in collision testing with movable actors. The assumption I was making is that he is spawning manager actors and they are probably not colliding with anything so setting density and bouncyness is irrelevant. Obviously if you are making a non moving wall then those params still matter.

What I meant by "the physics engine ignores it" is that the physics engine doesn't bother computing it's vector forces since it's static.

I figured this stuff out through trial and error and experimentation.

creativeapps

@ORBZ please check your message I sent you..:)

Thanks,
John

ORBZ

Furthermore, I should clarify. Movable is something that can only be set at design time. Density can be set at runtime. Therefor the movable flag is determining the type of physics object to create for Box2D. When movable is true it's probably spawning a dynamic object. Which is more CPU intensive. When it's false it's probably spawning a static object which is less CPU intense.

You can make a dynamic object behave like a static object at runtime by setting density to 0. But it's still a CPU heavy dynamic object. You can't make a static object behave like a dynamic object though as it has to do with how the object is instanced by the underlying Box2D system.

This is all my educated guess as a 20yr programmer by trade.

[Edit: I did some testing, what I wrote above is incorrect]

After doing some testing it seems that I was mistaken about how density works. Setting it to zero does not make the actor immovable. Instead, it just locks its rotation but it still freely bounces around. This seems like a bug. I'm using v0.9.94. Also, I was mistaken about being able to set density at runtime. It can't be changed at runtime. That probably also goes for friction and bouncyness. However, what I said about non-movable actors being low CPU and movable actors being high CPU is still true.

The_Gamesalad_Guru

I set all my non movable actors to zero friction, density, bounciness it's a good habit so if they are hidden in the scene area they don't conflict with other actors.

ORBZ

@FryingBaconStudios

Collision detection only happens if you have colliders. Friction, Density, and bouncyness have no effect if there are nothing set to collide with the actor via the Collide behavior (receiving or sending). However, if the actor is Movable it still has heavier CPU usage than if it's non-movable.

Also, while I'm speaking of collision optimizations. If you have, for example, 10 actors of type A that are going to collide with 2 actors of type B it's better to have the collide behavior on actor B than it is on A because B has less instances whereas A has more instances and therefor more instances running collision checks. It's especially not a good idea to have Collide behavior on both as that's just redundant and can cause weird collision glitches.