SYN TIP: A "better" way to make cloned actors behave in a unique way.
synthesis
Member Posts: 1,693
Perhaps you want clones of an actor to do different things...but modifying them in a scene will break their seed - clone relationship and making changes down the road can be AWFUL!
To avoid breaking that seed/clone relationship...consider this:
Use an actor attribute called "actorID" to allow clone actors respond differently depending on their ID. Once the actor is in the scene, modify the actor ID number within the scene to make that clone unique. Then any unique actor rules within the actor can be wrapped in a rule that only fires off if the actor ID is equal to the rule ID assignment.
This allows you to keep actors in their original/unmodified form within a scene and they will receive continuous rule revisions throughout development of your game. This also allows you to avoid unlocking the rules of the actor...which once that happens...the actor is no longer tied to its seed actor and revisions get more complicated and time consuming down the road.
In the event you have TONS of unique rules...I recommend separate actors in this case...but if you want "subtle" variations (such as sprite images, minor AI characteristics, or physics settings)...the actorID attribute is a great solution.
To avoid breaking that seed/clone relationship...consider this:
Use an actor attribute called "actorID" to allow clone actors respond differently depending on their ID. Once the actor is in the scene, modify the actor ID number within the scene to make that clone unique. Then any unique actor rules within the actor can be wrapped in a rule that only fires off if the actor ID is equal to the rule ID assignment.
This allows you to keep actors in their original/unmodified form within a scene and they will receive continuous rule revisions throughout development of your game. This also allows you to avoid unlocking the rules of the actor...which once that happens...the actor is no longer tied to its seed actor and revisions get more complicated and time consuming down the road.
In the event you have TONS of unique rules...I recommend separate actors in this case...but if you want "subtle" variations (such as sprite images, minor AI characteristics, or physics settings)...the actorID attribute is a great solution.
Comments
In your last sentence, you mention that you can use this method to change the images and physics settings to create subtle variations of the instances...
Just to be clear for the beginners, If you don't need those to be dynamic during the game, you CAN change the physics settings and images of instances without breaking the seed-clone relationship. Also any custom attribute you make, or any attribute for that matter... Basically you can change anything in the Instance on the left side of the Editor (anything NOT under the padlock) without breaking the relationship.
So let's say you have a bunch of trees in your game. And the only thing that is different between all the trees is the tree image, and maybe the size or rotation of each tree. To accomplish that, you simply need to make ONE tree Actor. Drag out a bunch of instances of that tree, and then change each one's image, rotation, size, etc...etc...
However, like synthesis says, if you want each tree to follow different Rules - which change as you play the game - I definitely recommend this method. It will be MUCH easier to troubleshoot.
Could prove to be helpful to me!
The point about image assignments would be...
Say you have an actor. In "round 1" its a tomato. In "round 13" its an orange. The only difference is their "character" and not their Rule Functions. And maybe the tomato flies slightly slower than the orange.
Using Actor ID...you can set the actor rules up so that if actor ID = 1...then show a tomato image and set its "speed" to slow. In round 13, the actor would have ID = 2...and a rule saying to show the orange image and set its speed to "fast". This way...all the other rules set up the same and you drag and drop the same "fruit" actor into each scene - change its ID and voila. This makes level building much faster and debugging/optimization seamless.
If the orange and the tomato had more complex differences...then you would need separate actors...but if all that changes is a few settings .... then actorIDs are the way to go.
For example, in my game Stunt Squirrels, I only have one platform Actor that I use throughout the game. And in Danger Cats, I only have one Actor that represents every single object in the game - all the shampoo bottles, bamboo poles, coconuts, etc. are all the exact same "object" Actor. I just change the images. (and the collision shape if necessary). The physics stuff cannot be changed dynamically at runtime anyway.
Anyway, I was agreeing with you. Your tip is a nice way to bring subtlety into the game.
Just clarifying the tip for the newbies!
(excuse the double post, see below)
after much experience with this approach here is why I wouldn't recommend it:
All the extra rules, even if not evaluated, make the actor instances "heavy" and you can't have a lot of them on the screen. "lightweight" actors, i.e. actors without a lot of rules are better if you plan on having a lot of them on screen at once.
even if an actor only ever executes 1 branch of it's logic tree, the entire logic tree still takes up memory space. Each instance of it bloats the GS engine and causes framerate drops on iPhone.
I would recommend scene actors with custom rules for increased performance.
I'm not suggesting OVERLY complicated rule options...but for small variations...I still think actor IDs are valuable...as opposed to expanding the actor library counts.