Why no family containers?

Discussion and feedback on Construct 2

Post » Tue Jan 13, 2015 11:23 pm

Since families are restricted to one object type in C2, it seems odd to me that you can't put families in a container.
I'm at a point in my current project where this would be extremely useful and time-saving.

Is there some technical or design-philosophy reason that this isn't done?

Also, has anyone else wanted this, and come up with a substitute that isn't ugly.
B
17
S
2
Posts: 66
Reputation: 1,382

Post » Wed Jan 14, 2015 4:11 am

Yep. I think this get's requested every month.

Nope, no substitute that isn't ugly.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Wed Jan 14, 2015 6:44 am

Ah, ok. Well thanks for confirming anyway.

I always seem to struggle with making groups of objects behave as one entity, while also building simple and clean AI for these object-groups/entities.
B
17
S
2
Posts: 66
Reputation: 1,382

Post » Wed Jan 14, 2015 1:10 pm

The implementation would be extremely complicated and it could have a performance impact across the whole engine even when the feature isn't used. I think there are workarounds to make it work like you need it to anyway, so I'm pretty hesitant about adding something like this.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,351

Post » Wed Jan 14, 2015 9:25 pm

I understand, thanks for commenting. I'm not sure if it's the right direction to go in anyway.

It would actually be better if we had a generic "Object" object, to which we could add sprites, dictionaries, arrays, and such as components.

The families system is a little awkward to use, but using multiple families and sticking many objects in several of them, I can make a system that isn't too ugly, and allows for relative easy creation of AI. But this kind of falls apart when I'm trying to basically custom make a container system for half of my objects with events.

For instance, let's say I have a family called "friendly". Each object in this family has a nice pre-defined polygon used for collision, however, during certain circumstances, I also want to have each "friendly" use a second, and different collision polygon. So, I make a second transparent dummy sprite with a different collision polygon, and give it the "Pin" behavior. Now though, I'll need to create it each time an instance in the "friendly" family is created, pin it to that instance, and then destroy that same instance, if the "parent" instance is ever destroyed.

One might look at that and say, "I don't see the problem, it looks simple to me.". But that kind of "fix" is rather ugly because it piles on top of other little "fixes" scattered throughout the event sheet. And also, it's likely not very optimized if you want to have a layout with a few hundred objects with even simple AI running.
B
17
S
2
Posts: 66
Reputation: 1,382

Post » Wed Jan 14, 2015 10:14 pm

A behavior could do that in theory, but you're just trading events for code, that is just as ugly, if not harder to piece together.
Image ImageImage
B
170
S
50
G
179
Posts: 8,378
Reputation: 113,425

Post » Thu Jan 15, 2015 1:15 am

I agree with @WarpedOldMan and this root object has been on my request list for some time. I feel it's too late for C2 and legacy development. However for better design structure there should be Plugin, behaviour and WorldObject. WHere World Object is pretty much a plugin. However the difference is that

Sprite, SpriteFont, TileMap any visual should be a is a Behaviour. The Behaviour is referenced for drawing.

I like construct and I think Ashley is an excellent programming, but as a Unity game programmer C2 has some counterproductive design.

@newt I disagree. Moving Sprite and other such rendering plugins to a Behavior would have no increase in difficulty of development, but would increase flexibility of design and in fact make game dev easier. Both developers in the C2 Events and the SDK developers will have greater design ability. It sounds strange, but it's one of those dev designs that I have used to much greater effect than Containers and proper multi level inhertance makes coding complicated objects much easier. Which i accept that we cannot have Families of Families. However right now there is no reason why we can't have a version of Sprite as a Behaviour.

And to expand on the OP. Batch sprite objects would offer creative flexibility for group objects. Including grouped sprite objects. As of right now behaviors can't draw without some hacking around.
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,038

Post » Thu Jan 15, 2015 11:10 pm

@jayderyu , I just posted a behavior plugin "Container Helper" , that helps a bit with picking family instances in relation to containers. https://www.scirra.com/forum/behavior-container-helper_p874258?#p874258
Let me know if that is something that will help you.
B
47
S
22
G
65
Posts: 1,127
Reputation: 38,395


Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 9 guests