Behavior Vs Script File.
by rennie moffat · in Torque Game Builder · 08/10/2010 (1:17 am) · 12 replies
Hi,
Just wondering a quick computing question. If I have a 100 objects all with an identical behavior Vs the same hundred objects but with a script file called via game.cs and there class, which is more pressing on the system? Or are they equal?
Just wondering a quick computing question. If I have a 100 objects all with an identical behavior Vs the same hundred objects but with a script file called via game.cs and there class, which is more pressing on the system? Or are they equal?
About the author
My thanks to Garage Games and the Garage Games Community combined with owned determination I got one game up, Temple Racer and I am looking to build more interesting, fun games for the mass market of the iOS app store.
#2
If you always have Behaviors "A", "B", "C", and "D" attached to the same objects, you could combine the logic into one class. Depending upon what those behaviors did, you could save a significant amount of time.
08/10/2010 (4:00 am)
I totally agree with Kevin. The only exception I can think of is if you have many of the same behaviors attached to those 100 objects.If you always have Behaviors "A", "B", "C", and "D" attached to the same objects, you could combine the logic into one class. Depending upon what those behaviors did, you could save a significant amount of time.
#3
08/10/2010 (12:06 pm)
When I have multiple classes that use identical (but separate) code, is it worth the effort to convert that code into a behavior?
#4
Thanks guys.
I do have one more question tho, if the behavior in question does not require any movement, any processing unless on screen and interacted with by the user, if I created a system which disabled various sections, so say of the hundred I have group A, B, C and D. Each group is a quarter of the objects. At the most only 2 groups could be active. the other 2 (and three at times) are setEnabled(false). by disabling these objects when not needed, even tho they are not actively processing anything, am I saving computing power? And am I saving much computing power?
08/10/2010 (1:56 pm)
Hmm ok. So all I have is one behavior so I guess I will go with 100 pounds of feathers. Thanks guys.
I do have one more question tho, if the behavior in question does not require any movement, any processing unless on screen and interacted with by the user, if I created a system which disabled various sections, so say of the hundred I have group A, B, C and D. Each group is a quarter of the objects. At the most only 2 groups could be active. the other 2 (and three at times) are setEnabled(false). by disabling these objects when not needed, even tho they are not actively processing anything, am I saving computing power? And am I saving much computing power?
#5
@Rennie - Your question is highly dependent upon the situation (a "how long is a piece of string" kind of question). It could save you TONS of time or it may not save you much. Unfortunately, sometimes you just have to implement an idea to see if it works.
One way to test your idea is to make 3 of the groups inactive and just force yourself to play in the area of the 1 active group. If you see a speed-up, then your idea is valid. If you don't, you can skip implementing the harder details.
08/10/2010 (5:53 pm)
@Kevin - Why not use superClass and put the common code into that namespace?@Rennie - Your question is highly dependent upon the situation (a "how long is a piece of string" kind of question). It could save you TONS of time or it may not save you much. Unfortunately, sometimes you just have to implement an idea to see if it works.
One way to test your idea is to make 3 of the groups inactive and just force yourself to play in the area of the 1 active group. If you see a speed-up, then your idea is valid. If you don't, you can skip implementing the harder details.
#6
08/10/2010 (6:03 pm)
Ok, I may very well test it out. I was just trying to figure out some ways to save computation. Thanks.
#7
My understanding of behaviors is limited: developers that use the level editor exclusively are the primary users of behaviors?
08/10/2010 (6:55 pm)
Will, I agree a superClass makes more sense in that situation. I successfully implemented a superclass in my current project (not Fangorodrim). My understanding of behaviors is limited: developers that use the level editor exclusively are the primary users of behaviors?
#8
In reality, there are so few differences between a behavior and a class that it takes all of 5 minutes to change a behavior into a class.
Behaviors are nice in that they come with a pull-down in the editor and have the dynamic variables pre-defined. Plus, since they are more like interfaces, you can have a button, a tool-tip, and a button-with-tool-tip by simply having 2 behaviors: button and tool-tip. You have two classes implementing onMouseEnter, but they each can do their work without knowing about the other.
Still, I find classes to be light-weight (compared to behaviors), and it fits with how I like to implement games. To each their own!
08/10/2010 (7:27 pm)
I would say that your assessment is fair. Behaviors are components that make is possible to add code through the level editor. If you can find a Behavior that meets a need of one of your objects, you can just drop it into a directory and immediately add it; no coding necessary.In reality, there are so few differences between a behavior and a class that it takes all of 5 minutes to change a behavior into a class.
Behaviors are nice in that they come with a pull-down in the editor and have the dynamic variables pre-defined. Plus, since they are more like interfaces, you can have a button, a tool-tip, and a button-with-tool-tip by simply having 2 behaviors: button and tool-tip. You have two classes implementing onMouseEnter, but they each can do their work without knowing about the other.
Still, I find classes to be light-weight (compared to behaviors), and it fits with how I like to implement games. To each their own!
#9
I do have a hypothetical question tho as to to why I would think a script, on a 100 objects would be better than behaviors. Pre testing of course... but in theory, if I have 100 objects, each of AClass, referencing AClass.cs. AClass.cs is called once ( i would think) and then ran out to each object of AClass, while with behaviors, ABehavior.cs is called each time it is attached to an object, so a 100 times.
Make sense? But is this theory flawed?
::)()(
08/10/2010 (8:12 pm)
This is good to hear. From others, I pick up the sense that behaviors bog down the system, are some "new thing" that only newbs use and aren't really true coding. Anyhow, as long as they do not bog down the system I am ok with that.I do have a hypothetical question tho as to to why I would think a script, on a 100 objects would be better than behaviors. Pre testing of course... but in theory, if I have 100 objects, each of AClass, referencing AClass.cs. AClass.cs is called once ( i would think) and then ran out to each object of AClass, while with behaviors, ABehavior.cs is called each time it is attached to an object, so a 100 times.
Make sense? But is this theory flawed?
::)()(
#10
If you have a sprite and attach a behavior, you create two objects: the sprite and a copy of the behavior.
Fortunately, behaviors are pretty small. At a quick glance, I'm guessing they are on the order of 320 bytes. So 100 copies of a behavior would be 32k. It looks like the first generation iPhone had 128MB of RAM. Even if I was 10 times off and 100 copies of a behavior were 320k, that's still only one-quarter of one-percent of the memory.
Then again, without testing, it's hard to know.
08/11/2010 (7:08 am)
If you have a sprite, and give it a class name, you only create one object: the sprite.If you have a sprite and attach a behavior, you create two objects: the sprite and a copy of the behavior.
Fortunately, behaviors are pretty small. At a quick glance, I'm guessing they are on the order of 320 bytes. So 100 copies of a behavior would be 32k. It looks like the first generation iPhone had 128MB of RAM. Even if I was 10 times off and 100 copies of a behavior were 320k, that's still only one-quarter of one-percent of the memory.
Then again, without testing, it's hard to know.
#11
I know it would be easier to test, I I think I may do just that. Pre test questions
A. does it (having them all vs some rendered (setEnabled(true)) effect game speed?
B. if I setEnable(true) some then, later setEnable(false) some and setEnable(true) others, like lights in a room and turning them on and off when necessary, effect game play?
C. and does the actual act of turning them on and off cause any major pauses in game play.
Just my thoughts as of now.
Thanks.
08/11/2010 (1:36 pm)
Hmm, great William thanks. But what about the sprite itself? The sprite in question is only 4Kb's but is it's simple existence a factor in memory/computing? I know it would be easier to test, I I think I may do just that. Pre test questions
A. does it (having them all vs some rendered (setEnabled(true)) effect game speed?
B. if I setEnable(true) some then, later setEnable(false) some and setEnable(true) others, like lights in a room and turning them on and off when necessary, effect game play?
C. and does the actual act of turning them on and off cause any major pauses in game play.
Just my thoughts as of now.
Thanks.
#12
08/11/2010 (4:02 pm)
It's a matter of using the right tool for the right job. If you feel like it'd be more convenient to be able to edit certain flags and whatnot for an object in the editor it makes sense to use a behavior instead of a class. I use a LOT of behaviors in my project and it still runs great :) So don't be too afraid of them. 
Torque Owner Kevin James