[request/alternative found] Family Inheritence

0 favourites
  • 5 posts
From the Asset Store
Template for an alternative to falling shapes, fully documented in comments and video
  • The recent thread about Families reminded me a request I would like to see.

    I create various objects that get stacked into a family. However, I can't access the objects own individual Plugin.

    If for example I have shootable FadeWall with a Fade Plugin and have my bullet's check for WallFamily. I don't have access to the Fade Plugin if i'm doing collision check on WallFamily. However if I check for FadeWall. I get FadePlugin and any plugins of the WallFamily. However, the innate problem with that. Is that I need to add extra lines of events to not only check against WallFamily, but also FadeWall. So i'm not really making it more effective as I need the extra events.

    When checking through family I should have access to any specific Object plugins that are in the immediate family, objects own plugins and including related family if the Object is part of 2 or more family.

    Also an event that checks the Family should have a way to identify which Object in the family has been triggered.

    Doing this will increase Family productivity by a large amount :)

  • You can do this using the "pick nearest" action.

    Like this:

    <img src="http://i.imgur.com/gGJBO8B.png" border="0" />

    Here's the example:


  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • hmmm, looks inefficient, but it also looks to be a solution. I think I will try it out and see how well it works. Though I still think having it built in naturally is a better design.

    Appreciate the tip :)

  • I'm not sure I understand - isn't the solution to use family behaviors, which you can then reference through events for the family?

  • To an extent yes, but not every member of family will have the same response.

    If there are a number of different Wall types that behave differently based on being shot. Then I don't need a Wall family to have both plugin behaviours.


    -KnockBackWall(has bullet)

    -FadeWall(has fade)

    -BounceWall(nothing special)

    In this situation KnockBackwall doesn't need fade, and Fadewall doesn't need Bullet plugin.


    On Collision Bullet to FamilyWall

    -> FamilyWall do (and has no access to Bullet, Fade and do not innately know which wall was hit)

    If I give WallFamily Fade and Bullet, but there is still no innate way to determine which wall object had the collision. However andreyin solution to pick nearest sounds like it will work. Haven't used it yet :D

    You know what. I think I found a solution to the design around not knowing the object.


    instance variable - typefunction

    on collision bullet to WallFamily

    Function Call (WallFamily.type, WallFamily.uid)

    On Function "foo"

    choose wall based on UID Function.Param(0)

    I think that solves the inherent lack of knowing or access to the object in the family and access to plugins in the object not the family.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)