Poll: merge attributes in to behaviors

Discussion and feedback on Construct 2

Post » Mon Apr 04, 2011 12:49 pm

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 :)
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Mon Apr 04, 2011 4:13 pm

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?
Spriter Dev
B
88
S
21
G
12
Posts: 3,240
Reputation: 16,486

Post » Mon Apr 04, 2011 4:59 pm

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.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Mon Apr 04, 2011 5:41 pm

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.
B
25
S
3
G
6
Posts: 1,197
Reputation: 5,620

Post » Mon Apr 04, 2011 8:11 pm

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.
Image Image
B
161
S
48
G
91
Posts: 7,358
Reputation: 67,271

Post » Tue Apr 05, 2011 1:43 am

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.
B
51
S
10
G
7
Posts: 184
Reputation: 6,825

Post » Tue Apr 05, 2011 5:03 am

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"?
B
2
S
2
G
2
Posts: 158
Reputation: 1,366

Post » Tue Apr 05, 2011 12:29 pm

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?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

Post » Tue Apr 05, 2011 12:48 pm

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?
[code:vhg4mm7b]->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?
Image Image
B
161
S
48
G
91
Posts: 7,358
Reputation: 67,271

Post » Tue Apr 05, 2011 1:21 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,600

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: dadanwsd and 8 guests