Poll: merge attributes in to behaviors

Hey everyone,

As I was working on behaviors for the next build, I had an idea. Previously in 0.x attributes have been added as a series of predefined checkboxes in the properties, such as 'solid' and 'centre view on me'.

It seems to me kind of pointless having a separate set of checkboxes for this. I think a better way is simply to merge them all in to behaviors. In other words, to make an object solid, you'd add the Solid behavior to it.

IMO this simplifies the editor - there's no distinction between behaviors and attributes - and this is simpler to write as well. (No need to program attributes as a separate thing.) It also could add some flexibility - if you can enable and disable behaviors at runtime, you can enable and disable attributes like solid.

The only thing I can think of that's lost is user-defined attributes. However, families (when they get done) pretty much substitute them completely.

This seems like a pretty good thing to do to me, but I thought I would check and run a quick poll to see what people think. I like polls anyway If you have any suggestions or variations on this which you think would be good, do mention it in a reply!

I'm going to have to vote

maybe...

Would it still be possible to do a condition like "Sprite is overlapping "Solid""? That is the main (only?) situation I use attributes, since unlike families no picking occurs and objects using different plugins can have the same attribute.

Actually a condition like "Sprite overlaps any object with behavior "Solid"" would remedy those two issues.

Also custom attributes could be solved by allowing the behaviors to be renamed at design time. So one behavior called attribute that can be renamed to whatever attribute: "solid", "platform",etc...

On second thought I'm voting yes, the idea has a lot of potential.

Set activated / deactivated "center view on me" does sound good, but when you think about it its still kind of limiting.

I mean would you want really want center view on me every time?

Then again as a behavior the plug could include some sort of scroll, or are you thinking more along the lines of having the possibility of a "scroll to me" behavior as well?

Ok yeah, there's some potential there, way beyond just solid, and center view.

What's still kind of limiting about it? How is adding it as a behavior more limiting than ticking a checkbox?

I'm surprised anyone is voting "no", because this is actually a good idea. Might as well, families pretty much serve the exact same purpose as custom attributes, which means attributes like Solid might as well be behaviours anyway.

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

What's still kind of limiting about it? How is adding it as a behavior more limiting than ticking a checkbox?

Its not, this actually could fix a lot of issues.

Like the fact that center view on me is pretty much useless as an attribute if you have more than one object you want to follow. Same goes for solid, adding or removing the attribute was always buggy in C0.xx.

More importantly I think this will add the possibility for many more types of attributes, like an outer bounding box attribute for example.

Unlike solid or, per pixel, or bounding box, outer bounding box would only detect collisions around the perimeter of the object, IE no collisions within the box.

Instant borders from one object instead of 4.

Behaviors can act as attributes. I say yay.

I'd keep it as it is. Attributes have only two states, on and off, without any more options to change like behaviors speed, acceleration etc., so I think checkbox is enough.

On the other hand, if it's easier for you to make and probably in the future easier to add/remove, and enabling/disabling at runtime sounds great.

I voted "maybe" for now...

I don't know, so you're saying, a character that has platform behavior but acts as a platform for other things too jump on that's destroyed on startup has to have platform behavior, is-a-platform behavior, and destroy on startup behavior?

Maybe behind the scenes its nicer, but I think these attribute behaviors shouldn't look the same in the editor as regular behaviors. Clutter for the property pane under behaviors and in ace dialogues where you have 3 tabs with only enable/disable on them

Well, I think you could argue all behaviors could be a list of checkboxes that you tick as well. It's not what you're used to, but I think it still makes a lot of sense - an object behaves as a solid, so it has a solid behavior.

Or use variables.

Hard-coded attributes that can't be altered at runtime are kind of... pointless.

In fact, attributes are redundant. I'd rather see the missing essential features to be developed before redundant features like attributes.

Just my 2 cents

I see what you mean ash, but my only concerns are not having several tabs in the ace dialogue, like if purely attribute behaviors should just take a single tab.

Another...it just seems like a lot of overhead for a single value. The entire plugin sdk compiled for a boolean, although you can probably afford it most situations still seems a little wasteful

And I disagree with mipey I think. I mean...what? How would you define a solid object for platform behavior to jump on?

Easy. Add platform behavior to it, tick solid. Everything that a behavior requires should be provided by the behavior itself.

That way you could have moving platforms etc., sprites that act as solid ground to walk onto (viking with up shield) etc

What if someone wanted an object to not become solid at some time? What if he wanted to make the object solid for some, but not solid for others (ghosts)? Hardcoded attributes would be a bad idea, as they wouldn't be as flexible as a behavior.

I guess this means we can now test for conditions with behaviors? Like for example: "sprite overlaps platformer behavior"?

But come to think of it... Shouldn't attributes be merged with families, not behaviors? It just makes more sense. "Solid" and other attributes should be pickable anyways. Object overlaps solid: solid -> destroy just makes more sense as a family, and is useful. Behaviors do things. Attributes are testable but unpickable groupings of objects, nothing more. Families are testable and pickable groupings of objects. Why do attributes exist again? If anything, when creating a family, you should be prompted to define the family as attribute or not, which just means it can't have family variables. Then again, I only ever used attributes because they were less buggy than families and simpler to add remove (no messing with variables etc.). Also, this time around, please don't mix family variables with normal private variables. They should be in separate lists (the family vars in the family dropdown, and the normals in the pv dropdown). And don't make families inherit already created variables of objects, keep those two variable lists completely separate.

It's weird to have attributes as behaviors. And then to user-define a behavior just so we can test overlapping with them but not pick them? I don't see the point. Attributes are like mini families currently, just make them real families. It would also be cool if when you add the family for "destroy on startup" or other predefined ones, it adds the corresponding events to the project, maybe at the end of the event sheet or something, or it makes a new event group called "pre-defined families". So you actually see the code which is in your game. I've sometimes forgotten about "behind the scenes attribute code" when I was newer, which runs invisibly when you tick one of those boxes, leading to long bug hunts just to figure out why something is destroying on startup because I forgot about attribute code. If the events were actually added to your sheet, then you would see the code which affects your game. You would also be able to edit how the "center view" code and others behaves etc. because it would just be events referencing that family.

Actually, couldn't this replace families as well?

Perhaps a s a non layout object. Matter of fact that might take care of family variables as well.

Variables for the family object, and instance variables for objects within the family.

Question is would you assign attributes to the family or to the members?

Oh and what about containers?

Guess in theory you could do something like the object pairer.

But that does kind of leave the "start of layout" attributes out in the cold without some sort of check box for them.