[Suggestion] Adding families to families

Discussion and feedback on Construct 2

Post » Sun Mar 31, 2013 4:15 am

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.

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

It would be really, really cool.ChrisAlgoo2013-03-31 04:16:24
B
17
S
4
G
4
Posts: 143
Reputation: 4,004

Post » Sun Mar 31, 2013 11:54 am

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

Post » Wed May 08, 2013 6:15 pm

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.ChrisAlgoo2013-05-08 18:19:36
B
17
S
4
G
4
Posts: 143
Reputation: 4,004

Post » Wed May 08, 2013 6:51 pm

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.
B
45
S
19
G
10
Posts: 562
Reputation: 9,543

Post » Wed May 08, 2013 6:59 pm

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 writingshinkan2013-05-08 19:00:42
ImageImageImageImage
B
140
S
58
G
36
Posts: 2,547
Reputation: 31,170

Post » Wed May 08, 2013 9:33 pm

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;
ImageImageImageImageImageImage
B
93
S
20
G
12
Posts: 1,211
Reputation: 18,480

Post » Wed May 08, 2013 9:57 pm

@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.
ImageImageImageImage
B
140
S
58
G
36
Posts: 2,547
Reputation: 31,170

Post » Wed May 08, 2013 10:59 pm

@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.
ImageImageImageImageImageImage
B
93
S
20
G
12
Posts: 1,211
Reputation: 18,480

Post » Fri May 17, 2013 4:08 am

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
B
2
Posts: 1
Reputation: 152

Post » Fri May 17, 2013 4:52 pm

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.
B
17
S
4
G
4
Posts: 143
Reputation: 4,004

Next

Return to Construct 2 General

Who is online

Users browsing this forum: eli0s, Lof, RageByte, Yahoo [Bot] and 8 guests