Objects and Instances

This forum is currently in read-only mode.
From the Asset Store
Hand-painted tiles, objects, animated objects, and background to build a colorful Mayan civilization environment.
  • Construct's treatment of objects and instances has been pretty confusing for me, so far. Maybe it's because I've been programming for a long time and see a very sharp distinction between classes (Construct objects) and objects (Construct instances). Construct seems to treat the two concepts as the same thing, at times. Specifically when defining event actions: Does the "Cruiser" in "Create object Asteroid at Cruiser.X, Cruiser.Y)" refer to all cruisers, or the first/last one that was spawned? I'm sure I'll figure it out eventually, but it's just giving me some trouble right now. It seems like both cases are true, depending on the situation. A System:Destroy command for a given object destroys all instances, unless it is immediately after a spawn action that created a specific instance.

    In any case, would it help if I consider that all instances of the same type have the exact same properties and event handling? Only the private variable state is different?

    In other words, if I want the player to fly around in a spaceship, and the enemies to fly around in the same spaceship, would I want to create two separate Construct objects? Both would share the same source image and probably have similar collision and image point settings, but one would have player input-related event actions and the other would have AI event actions?

    That seems more in line with how Construct works, and I wouldn't need to worry so much about which instance is being referred to in an event. I could simply assume that the Ship in player actions is the player, and the Ship in enemy actions is all enemy ships.

  • Cruiser.X, Cruiser.Y refers to whatever cruiser has been 'picked' through condition. For example:

    + Cruiser.X > 100

    -> Spawn Asteroid at Cruiser.X, Cruiser.Y

    In this example, the Cruiser.X > 100 condition picks all cruisers with X greater than 100. That's what 'picking' is like, it is rather intuitive - it is basically filtering, so actions are executed on the objects you want

    If there is no condition or such, all instances of the Cruiser will be picked by default.

  • I think you should read the wiki article on Conditions, it should help clear things up for you. The details may be confusing at first, but Construct actually has well-defined behavior in most situations involving object instances and object types.

    Does the "Cruiser" in "Create object Asteroid at Cruiser.X, Cruiser.Y)" refer to all cruisers, or the first/last one that was spawned?

    From the article:

    [quote:2nykc8o4]The Expression rule

    The expression Object.X will retrieve the X co-ordinate of the first instance of Object that is picked. If Object is unreferenced in the event, it refers simply to the first instance to retrieve the value. This is worth bearing in mind. See the examples for more information.

    (remember 'set X to .X + 1' will move all instances to the right because expressions which refer to the object owning the action refer to each object separately)

    [quote:2nykc8o4]A System:Destroy command for a given object destroys all instances, unless it is immediately after a spawn action that created a specific instance.

    That's right, the create and spawn actions pick the object created, and that is intended, so you can use events to modify that object.

    [quote:2nykc8o4]In other words, if I want the player to fly around in a spaceship, and the enemies to fly around in the same spaceship, would I want to create two separate Construct objects?

    Yes, but mainly because they are logically separate objects. The player spaceship is controlled by the player rather than AI and that's enough to justify making them separate.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks for the replies, guys. That helps a lot.

    [quote:1s7x086n]Yes, but mainly because they are logically separate objects. The player spaceship is controlled by the player rather than AI and that's enough to justify making them separate.

    That makes sense. I really like the idea of not duplicating stuff like the image points, collision settings, and behaviours, though. Right now I'm playing with storing a global "PlayerUID" variable that is then used as a conditional for apply player input to the one instance. Or, even better, I could have an "Is Player" private variable in the specific instance and avoid having a global variable.

    I'm also playing with attaching ship-specific stuff like exhaust (particles) to the ship, since it looks like containers automatically handle the spawning of "child" objects in the container.

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