Poll: merge attributes in to behaviors

I would definitely say if anything merge them with families. Provided anyway that they can in some way easily be added and removed from the family as needed. Having a trait that makes other objects react to you but doesn't actually make the object itself act doesn't seem very "behavioury".

Something I'd do with the behaviors though is not hardcode them to rely on an object being in a certain family but be able to define in the behavior settings what family (Or even families) that behavior should treat as a solid, platform, etc.

Didn't read whole thread.

So, if I want to have solid ground I'll have to assign some behavior to it, let's say Platform Beh., and disable movement? Will it reduce performance? Looks like there will be unnecessary code in runtime.

Or it will be just separate behavior, named "Solid"?

DtrQ: no, you'll just add a 'solid behavior' to it, not a platform movement, they're different things. I don't see any reason it'll reduce performance either.

Having a 'solid family' is a good idea, but I think everyone's forgetting a limitation on families: due to the way family events work, you can only have one plugin type in a family (e.g. all sprites, all tiled backgrounds, all text objects). So if this limitation is kept, you can only make either sprites or tiled backgrounds solid - not both! If this limitation is removed then there's a big question about what happens with the events. I'm also not sure what effect it would have on the runtime, which in many places assumes there's a single plugin type in a family.

Something else to consider is we're planning a new model for families when we get round to them. Objects will inherit the variables and behaviors from the families they're in. So instead of family variables and behaviors being all-those-in-common, you define them seperately and all objects in the family get them, no questions asked. In this case, you can add a 'Sprite solids' family with a solid behavior, and any object in that family also gets the solid behavior. This way you get both! You can make an object solid either by adding the behavior, or adding to a family you made with a solid behavior.

With that in mind, does this sound better?

Will there be the option to deactivate the behavior for the family?

I can see times where that might be useful, as well as a big pain.

Also how about linking "For Each" & an attribute?

->For Each Solid ordered by .x ascending
-->Send to front [/code:vhg4mm7b]
That might be quite useful as well, but again what would happen if that Solid behavior was deactivated in one or more of the objects?

Yes, you should be able to enable and disable behaviors in families, as well as on a per-instance basis. As with attributes they will appear in object pickers so you can do the for-each you proposed.

Something else to consider is we're planning a new model for families when we get round to them. Objects will inherit the variables and behaviors from the families they're in. So instead of family variables and behaviors being all-those-in-common, you define them seperately and all objects in the family get them, no questions asked. In this case, you can add a 'Sprite solids' family with a solid behavior, and any object in that family also gets the solid behavior. This way you get both! You can make an object solid either by adding the behavior, or adding to a family you made with a solid behavior.

With that in mind, does this sound better?

perfect

Also... Didn't someone mention the idea of creating behaviors/plugins using events a while back?

Yes! Do this!

Adding a group of events instead of having hidden code is also a great idea!

Hm, as regards event-based behaviors, I think you can already do this in C0.x via attributes.

Somthing like:

Add custom attribute "MyPlatformBehavior", then "For each MyPlatformBehavior" -> ...your code

I don't think so; you can't perform actions on attributes. You can't say MyAttribute -> set x, since different object types can have the same attribute.

And that sounds good Ash, I like the idea of giving families behaviors. The inheriting of variables is what I proposed before, so that's nice.

Oh, you are right, can't apply actions to attributes.

Well, at least it can be done for one-type objects with families or even families+pv