Why no family containers?

0 favourites
  • 8 posts
From the Asset Store
A collection of various zombie characters sprites for creating a 2D platformer or sidescroller game
  • 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.

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

    Nope, no substitute that isn't ugly.

  • 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.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • 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.

  • 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.

  • 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.

  • 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.

  • 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.

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