Can One Actor Set/Read Another Actor's Attributes?

netdzynr

Like the title says, is it possible for one actor to set or read another actor's attributes, without relying on global game attributes?

I have a scene with 36 actors, each of which can be set to 1 of 3 "states". I want to somehow query the states of all 36 actors and compare them to a stored master state. The problem is, I don't want to have 36 game attributes each tracking the actor states -- this will get messy quickly as this is only one scene in the game, and the game will have multiple scenes.

Alternatively, I see that Scenes can have custom attributes applied, but how the heck do you read/write to them? The options in the Attribute Browser only seem to list options for the Game, not the Scene.

(Arg, I wish the GameSalad folks would update their development app already.)

Thanks for any suggestions.

JackBQuick

As far as I know, no. There has been a recent forum about this:

http://gamesalad.com/forums/topic.php?id=4065#post-24062

firemaplegames

No. You must use game attributes for actor to actor communication. Not easy! You might want to rethink that part of your project...

As far as scene attributes, only instances in the scene have access to them. I use a "scene controller" actor, which is just a simple box with no code. I place this actor in the scene but outside of the viewing area. Double click on this actor to set its instance behaviors (click the padlock). This actor now has access to things like the camera, and can set scene-specific attributes like the current level and the number of bombs for this level, etc. Those are global game attributes though. Whenever i need to reset a level, this actor takes care of resetting all the attributes.

rebump

You can have actor-to-actor access of each other by way of editing their instances (not the prototype) within a manually setup scene. You basically navigate down through "scene->layers->..." to the other actor object's attributes. This can cause problems if you ever want to change actor prototype behavior and have it propagate down to the now "broken" (i.e. break the padlock) actor instances. It also requires setting up these connections in each scene and on manually placed actors (for now).

firemaplegames

Ooh, I didn't know you could do that!

rebump

I haven't used it but noticed you could navigate down to other actors from within an actor. It truly is similar to instantiating objects from class definitions in computer languages. The only problem is, you only have access to manually placed (or re-used) actors. There is no way to discover a spawned actor (at the moment) to use it's attributes (although spawned actors can use game/global level attributes as you state above).

It could open up some doors in sticky situations I suppose.

But if you can get by using the usual method (i.e. the one you outlne above), maintenance will be easier (for now).

* I hate saying "for now" and "at this moment" but being in Beta, I would hate for folks to read the old forum posts and think things were one way when they end up being another way down the road. Oh heck!

netdzynr

Thanks for the responses. @FPG -- I would be happy to rethink my project. Essentially, I have a combination lock with 36 characters. How can I get the values of the characters and compare them to a master value? There are no arrays in GS. There is no way to read attributes of an actor. There is no way to update characters in a string. I don't see any way to create such a mechanism other than 36 game attributes. [sigh] Guess that's the route to take.

netdzynr

@ rebump -- Thanks for pointing out the method for accessing actors' attributes. That is exactly what I need, but as you said, it's a problem if one ever needs to change the attributes of all related actors. The thought of pasting updated behaviors 36 times makes me cringe :-)

Given the responses above, I think I'm going to set up 50 or so generic game attributes that are reused in each level. It's tedious to set up, and a pain to write rules for checking them, but "currently" (following your lead here) there doesn't appear to be any other option.

netdzynr

DUDES! A combination of your ideas (rebump's actor attribute access option and FMG's scene controller) solved the problem! I have one hidden controller actor in the scene whose job is to check the attributes of the 36 main character actors. The controller reads/checks custom attributes of the character actors and determines when a match occurs. Setting up the rule is a bit of a chore only because the paths to the actors' attributes is so deep, you can't see them once you've set them. But still, since there is only one controller, changing its behaviors is no big deal. And best of all, no need for custom game attributes!

This is almost as good as having arrays! Thanks guys!

ORBZ

This works, but be super careful about not deleting any of the actors on the scene. You'll fry your scene controller's path and get no warnings except for the game not running.

beaudoin_n

Did you try this on the device?? From my experience many actors = slloooooowwwwww

adado

@beau: Actor count depends on how complex the actors are in terms of image, rules/behavior, and motion. The more of any one (i.e. actor count, image size, rule/behavior complexity, or motion complexity) typically means the less of the others to some degree.

As always, experiment and test (on multiple devices).

netdzynr

You're right of course -- testing is key. In my case, however, there's no motion at all, only image flipping (puzzle game) so I think the solution will work. And I won't be able to test on a device until April (shooting for iPad first, iPhone after). In any event, I imagine there's probably a way to make the behavior touch/click based, rather than constantly on.

JackBQuick

I hope you don't mind, netdzynr, but I was curious about how to go about creating a game like you described. This is what I came up with:

http://gamesalad.com/game/play/48416

I took individual actor attributes (for example: 'A', 'B', 'C', 'A' and 'B'); concatenated them ('ABCAB'); and then used a rule to compare it to the actual combination ('ABCBA').

(I only used five actors instead of thirty-six but it's scalable, I think.)

Was this something like what you were thinking?

netdzynr

Yes, your version is exactly like what I am doing -- I was heading this direction. But if I correctly understand how your setup works, each of your 5 actors has custom behaviors to change game level attributes. In my case I wanted to avoid both situations: 1) I wanted one actor with a common behavior for all of the "keys" -- if the behaviors need to be updated, only the original actor instance needs to be changed; 2) I was hoping to avoid using game level attributes because some scenes in my game may have up to 100 attributes to check, and if multiple scenes need their own attributes, the huge list of game attributes will become unwieldy (for me anyway).

In my arrangement, there are only 2 actors with custom behaviors for any number of "keys": the prototype actor, and a "scene manager" that keeps track of the instanced actors' values.

So yes, I believe your setup is scalable, but requires some careful planning. Who knows, I may fall back on this method if I run into some issue with my direction.

(The bottom line is, I think we all know the GS options for setting/getting variable values are in need of a significant update.)