[Suggestion] Adding families to families

This is something that I notice isn't present, and I have to do some less-than-elegant workarounds as a result. This would allow for inheritance and other really powerful things - some examples in the below link.

en.wikipedia.org/wiki/Inheritance_%28object-oriented_programming%29

It would be really, really cool.

Families already implement inheritance. If you want multiple inheritance, you can add one object to multiple families. That should be equivalent to having families in families, so there's no need to implement that.

It currently isn't possible to have something like

Car

Truck (which is a Car)

Armored Truck (which is a Truck (which is a Car))

etc...

Which would be really useful. If, say, Cars can transport people and Trucks can transport people and heavy equipment in your game, you'd have to write two families, even though both Cars and Trucks have acceleration, mass, max speed and other things in common.

A family within a family...famception

Why not have separate instance variables within a single family to detect if it can do certain things, like "IsArmoured", "CanTransportPeople", ect. Then you'd only have to code for 1 single family that can have many different vehicle types with unique settings.

It is possible. In my current project I have 3 families: Doors, Doors_BG, Doors_Side

Doors family containes all sprites for doors (bg and side) and all common variables: name, key, goto, locked.

Doors_Side family have only side_doors sprites. They inherit all variables from Doors family and have few more variables itself.

With that setup and functions I can really easy control interactions between player and doors he's currently overlaping.

Not quite sure what you are trying to do, but I think for example you described you could do all of that using only one family and variables

Edit: Basically what Jase00 said... he post while I was writing

Also

Family Car -> All the things necessary to be a car;

Family Truck -> Only what you could not implement inside the Car's Family;

Armored Truck -> The same from above;

TELLES0808 yeah, but there is not need for that really. If You have only one family with all the cars inside then all You have is one text variable, for example "type"

then split your event to

var = "car" - do specific car stuff

var = "truck " - do specific truck stuff

var = "armored truck" - do specific armored truck stuff

When I wrote my post above I thought for a second and then redesign my game. I have deleted all Doors families and left only one common Doors family for all doors sprites - in events I only change few thing to use doors.variable that already exist.

shinkan that's the pure true =]

Sometimes having different families can help handle specific events by filtering objects inside both families, by checking their unique behaviors.

There is something else that adding families to families would enable though, which is better inter-family instancing. Here is an example of a problem and how nested families could fix that. Lets say 2 items from the same family collide using Physics (which is a behaviour applied to that family), and you want to destroy the one without a specific variable "can-die" and stop movement of the other but only if the other one is moving fast enough initially.

FamilyA is colliding with FamilyA

FamilyA velocity>100

FamilyA can-die=true

=

Kill FamilyA

Set Velocity FamilyA to 0

This doesnt allow us to check each item in the family against each other in the conditions, whereas if there was a nested family (which also had access to all behaviours of its parent) then we could use the tree parenting to resolve the issue. for example:

FamilyParent is colliding with FamilyChild

FamilyParent velocity>100

FamilyChild can-die=true

=

Kill FamilyChild

Set Velocity FamilyParent to 0

See how handy that would be?

It can't be done using 2 separate families as that won't allow you access to the physics behaviours from both families, where-as parenting could solve that issue

Similarly (and this is one of the issues that initially sparked this idea), you can't have cross-family interactions that both address the same variable, since a family can only check variables that it has.

For example,

You have a Yin family and a Yang family. When a Yin they collide, you want them to reduce each other's Power variable by the other's value, and destroy if it hits 0. (So if a 20-power Yang and a 10-power Yin collide, the result should be a 10-power Yang and no Yin). Under the current system, there's no way that both families can have the same variable in common.

We would have to overhaul large and complicated parts of the engine to allow nested families, so I'm afraid right now I'd say it's very unlikely we'd take this on. Hopefully it's possible to workaround by duplicating variables in families.

roxflame - you don't need families for your example, you can work around it with 'Pick Nth instance'. Instance 0 will be the first colliding instance and instance 1 will be the second, then you can handle each separately in subevents.

Similarly (and this is one of the issues that initially sparked this idea), you can't have cross-family interactions that both address the same variable, since a family can only check variables that it has.

For example,

You have a Yin family and a Yang family. When a Yin they collide, you want them to reduce each other's Power variable by the other's value, and destroy if it hits 0. (So if a 20-power Yang and a 10-power Yin collide, the result should be a 10-power Yang and no Yin). Under the current system, there's no way that both families can have the same variable in common.

ChrisAlgoo: Unless there's something wrong in the description of your example this is totally doable as it is in C2.

Each family has a different variable indeed, but I don't see it as an issue since they are different "objects" anyway.

Example capx