Nested Families

[F3der1co]

Reviewed guidelines

• [X] I have read and understand the suggestion guidelines

Checked for duplicate suggestions

• [X] I checked for existing similar suggestions

Summary

A feature that allows us to add a family as a member of a family would enhance the usability of c3 tremendously and would be great to write very organized and efficient events.

This is a suggestion that has been one of the most voted suggestions on every suggestion platform.

Possible workarounds or alternatives

Currently you have to do a ton of picking and complex logic to have a family affect something that a member has in another family, as you cannot directly access any of variables, effects and properties.

Because of this limitation I often end up having repeated logic as I don't want to deal with the picking nightmare, a basic example: Currently I have a walking enemy, a flying enemy and a crawling enemy family with a lot of repeated logic or complex picking trickery. With nested families I could create a family enemies and add families crawling, flying and walking as child families and write much cleaner events as I would have access to their properties with way less picking.

Proposed solution

• When a family is added as a member of another family, the parent variables, effects and behaviors would be accessible to the child family.

• Custom action overrides from the child family would be hugely powerful

Why is this idea important?

It's important so projects can scale without huge amounts of complex, performance intensive and error prone picking.

Additional remarks

No response

[Jase0000]

I get this is going to be considered very complex, but this affects me often and I'd love to see something like this.

I end up adding variables into families that I didn't want to, picking all over the place, sometimes having duplicate variables just to save on picking (esp when 100's of instances to pick from), which then leads me to have to set these variables throughout events which ALSO requires more extra picking all over the place.

Would be an excellent addition and would grant us so much more power and make our events more fluid.

[AshleyScirra]

Families code is already complex and touches on a wide range of features in both the editor and runtime, so this would likely require a highly complicated and extensive reworking of a lot of existing code, and could involve months of work.

[Jase0000]

One idea, although it's just popped into mind and not sure on the complexity:

A sort of "family" system for families, let's say it's called a Family Tree, or "Relatives", or something better named.

Which could essentially leave families mostly intact the way it is, but can have a new Project section for "Relatives", allowing us to add families into groups. Perhaps this avoids the complexity of having to merge families alongside objects, might keep things separate and clean?

Probably just as complex, but trying to think of ways to avoid deeply modifying existing families.

[ruskul]

I'd like to argue that even though this would take a work, it is more important than any other feature (for a particular set of users). Part of the reason construct gets passed off as a learning tool and that you can't make serious games with it is largely due to issues of scaling smartly.

Where I taught, our beginner game making classes were with construct. Advanced and intermediate classes were mostly in unity, largely because of construct not having strong oop or component architecture. At a certain point, learning construct just makes you better at construct as the patterns and techniques just don't apply anywhere else. You can, of course, use JS in c3 which does apply beyond just c3. Basic logic, problem solving/debugging skill, and functional/routine style programing methods transfer from construct, but abstraction is limited.

I understand the sol paradigm is its own thing. But if we get sol and abstraction... construct would be not only fast and easy, but in the hands of advanced users it would be a real powerhouse and techniques of abstraction, in principle would also transfer nicely to other industries.

[ruskul]

I am curious, not knowing the back end, but a partial solution would be to figure out a way to transfer picking from family to family. In traditional OOP, if FamB is derrived from FamA, then we know all FamB is also FamA.

It wouldn't solve every issue, but a built in way to simply tell construct all FamB is in FamA, and giving us a system condition to transfer picking from family to family in such cases would be a huge boon. This might literally involve the same amount of work to pull off efficiently, but just a thought.

[ruskul]

It is also super painful that we CANT nest families, while at the same time, for some reason c3 doesn't allow two families to define the same behavior or family. If that was allowed, we could at least then communicate in one family to another via shared instance variables or behaviors, which wouldn't help too much with polymorphism but it would add alot towards transfering picking in conditions.

[alvaromartmart]

[...] for some reason c3 doesn't allow two families to define the same behavior or family.

How would c3 know which behavior parameters to use for an instance that belongs to several families?

[ruskul]

[...] for some reason c3 doesn't allow two families to define the same behavior or family.

How would c3 know which behavior parameters to use for an instance that belongs to several families?

I'm not sure I understand specifically what you are asking, but I'll take a stab.

there isn't two behaviors anymore. If you have FamA and FamB and both have platformerA on them, any object type added to both those families will still only have one behavior on them (platformerA). If you pick FamA and change platformerA property... its no different than picking FamB and ding likewise because they both refer to the same behavior.

If you are referring to default properties when creating new instances, they wouldn't have two behaviors to pick from, they only have one. If you want two to pick from you have to add another behavior and name it differently. The same goes for instance variables. The default can be described by the object type (which is already the case I believe) anyway.

Families just describe common functionality. There is no reason why that common functionality can't include a reference to external common functionality (other families, behaviors, instance variables). Instead families are isolated islands with very poor workarounds to connect them. The more complex the game, the more scale or performance matters, the more asinine those work-arounds become.

Put in context of programing, behaviors are a type of component architecture. Families function (in some ways) more as components as well rather than classes as well, since they do not subclass and only recently have been granted a small bit of polymorphism with custom actions, but with the restriction that they can hold no reference to the same component on the object. Its quite backwards. Given families cant be nested, there is no reason they shouldn't be able to reference each other distinctly.