efficiently handling multiple instances of the same object.

This forum is currently in read-only mode.
  • whats the most efficient way of handling multiple instances of the same object?

    for example, creating 2 of the same object at different image points and then setting their positions to stay on these points via an ALWAYS , or getting them to behave differently, like changing their angles independently.

    thanks

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Recently, there has been a lot of discussion of things like that. If you have to do something to a independent instance, you must pick it. The actions in an event apply only to picked objects, so you must ensure that only the instance you want to manipulate gets picked. You can pick with Unique Identifer, for example. For each -condition is also a lifesaver, it loops through every instance of an object so that the event is performed once for each instance.

    I'm in uni now and I should be studying (deadlines :S), so can't blabber more. Sorry :D

  • Picking is handled automatically for a lot of things.

    For instance, if you say "sprite is overlapping ground -> destroy sprite" then only the sprites that meet the condition are picked and destroyed.

    If you know the unique ID of an object, you can pick it that way as well.

    If there are no easy ways to pick like that, or you know you will have situations where some objects might meet similar criteria, you can make your own ways to pick with variables. Give each of your sprites a private variable, and make it unique. Then you can do "sprite.value('myvariable') equals whatever -> do something."

  • Idea of sub-events, sub-animations and stuff seems to cover this problems. But while its usage is still unclear to me, it'd be good for someone from DevTeam to tell about it ^^.

    Theoretically when conditions needed to make two objects are met, then you would have to make two parallel sub-events - both "always"-ed. First one will handle making first object and initializing it, second one: handle second object.

  • Theoretically when conditions needed to make two objects are met, then you would have to make two parallel sub-events - both "always"-ed. First one will handle making first object and initializing it, second one: handle second object.

    Yep :). That's because Selected Object Lists descend to subevents, but not back from subevent to parent event or sibiling event.

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