Accessing Self Attributes from Prototypes of other Prototypes

Twayne2

@adent42, I was wondering if GS has any intention of ever implementing this idea? Or at least if not, what are the issues with it? It really is a feature I would love to see. If I am not clear, I can elaborate some more about what I mean if you want.

tatiang

+1

adent42

I assume you are asking for support for actor inheritance?

tatiang

@adent42 I could be wrong but I think what @Twayne2 is suggesting is that you could access another actor's self attributes without unlocking the actor.

So for example, change attribute self.hitPoints to self.hitPoints - actor1.damage

Twayne2

@tatiang Exactly. It would unlock BIG potential for things such as TDs, which you all may have seen me talk about before. It would also allow for fighting based off of damaging directly to the enemy troop's health, or from their image they are on. (So instead of collision boxes for example.)
I don't know if it would be hard to implement or not, it's just something I would like to see added sometime.
I don't think I am talking actor inheritance, but I don't really know what that is too much.

tatiang

It would have to be each instance's self attribute though. I don't think it would help much to have access to another prototype but NOT its instances.

adriangomez

We already have bit of actor inheritance with the properties. I guess @adent42 was suggesting was also to have it for the action. Something you click a box and the child actor inherits the prototypes items but you can also add more.

I think the only way you can do what the original question would be storing the values in a table. Actor 1 cast a spell. Any actor with x range of Actor 1 receives a buff of 2 health.

adent42

@adriangomez ugh, my longer post was deleted before i posted. I meant the ability to have a prototype inherit from another prototype.

The short answer is, no. Basically it doesn't make sense with the structure of GameSalad's logic system as it is.

If you reference other prototypes, what happens when those prototypes go away? Or the event triggers for an actor that doesn't have that attribute? (BTW the names of user defined attributes are just friendly labels. The engine resolves attributes by a globally unique ID).

So this won't be happening until we consolidate onto one tool. Off the top of my head, here's some takes on how to handle it:

Event Attributes
The collision behavior (among any others that trigger Rules), would have the ability to declare "event attributes". So when you declare in Actor1 that it can collide with Actor2, you can also declare that Actor 2 will receive, in the event object an attribute named "damage" whose value is self.damage. Actor 2's collision rule allow expression access to an "event" object. The expression would access event attributes through a function: eventAttribute(name, defaultValue). So the expression in Actor 2 would be: self.hp = self.hp - eventAttribute('damage', 0). The function would return the actual damage if it's in the event and default to 0 if there's no 'damage' attribute in the event.

Message Passing
GameSalad would have a message bus and behaviors to "Post Message" to the bus. Either there would be a new Rule Condition or a new container behavior called "Handle Message".

Inside the scope of the "Message Handler" you'd have access to a "message" object and accessing message attributes would be just like above.

This is more flexible as you could use it in many more situation, not just in GameSalad "events" like collision.

In the case of collision, you just Post a Message on one half of the collision. And the other actor you'd just handle collision messages.

While I'm partial to the Message Passing system, the event system could enable some more interesting behavior in GameSalad, like having keyboard input include an event object. This would enable logic to use "event.key" or "event.keyCode" to perform based on expression evaluation of the event attribute, rather than having to handle each key press in a separate rule.

In any case, these features would both need behavior improvements, so they likely won't be happening until we complete Creator 2.0 as a replacement for the two existing creators. I'd also like a chance to look at the notes of the original architects of GameSalad, because I'm pretty sure we had talked about this kid of feature before and just never got around to implementing a fix.

Thanks for bringing the idea again up though, I'll keep thinking about how to best handle this.

adent42

I just realized you could, in theory, create your own message bus with tables as a stop-gap. The idea would be to have one half of the collision add a row to a table like "damage" on collision.

Then have the other half of the collision could detect a change in tableRow length and run a loop over table and subtract 'damage' from 'hp' before clearing the table.

RThurman

@adent42 -- yes, yes, yes, Message Passing please!

Twayne2

Thanks for taking the time to address this @adent42!

(I got lost on the "Event Attributes" section, but that's because I stink. I do know about self.attributes though. If we could have an actor be able to access another actor's attributes during the collision, (or other rule triggering behaviors like you brought up), that would be like what we were talking about probably, but it would work to. So, once actorA collides with actor B, rotate to vector, (instance's position x-self.positionx, instance's position y-self.positiony), in relation to actor.)

Thanks again!