Getting a multi-part enemy to sync

0 favourites
  • 6 posts
From the Asset Store
Give Sound to the enemies that are part of your game! :)
  • I've got a plant enemy. It has a stationary plant sprite, and a head sprite that rotates and fires spores at the player. Simple enough, right? Well, no.

    The plant starts at 1% Size, when it comes on-screen it enlarges to 100% size and begins it's normal behavior. When it takes 4 shots from the player, it shrinks back to 1% and Destroys itself. That's the theory anyway.

    I've got both sprites in a family, with health, size and enemy phase all in Family Instance Variables. All code regarding it's size and health only reference the family variable.

    Everything works as it should BUT, when the player kills the enemy only the part that took the hit will shrink (both will destroy once it hits 1% size) and I need both parts to shrink the same way they both grew at the start.

    I'm sure my code is rather un-streamlined, but I've tried to annotate everything to help.

  • Family instance variables mean that each object in the Family has its own version of that instance variable.

    Like, the Family has a Health variable. But if you shoot the head, only the head loses Health - not every object in the family. The body has a different Health value that isn't affected.

    You could use containers for this. If you put the objects into a container together, you could have it so that their health values always match. Or that a hit on the body always takes Health off the head, and then you can scale them both based on the head's value.

  • Ah, I thought containers might be the answer. But I'm afraid I know even less about them than Families. Looks like I've got some studying and coding to do. Thanks for the advice.

    Would you recommend that the two sprites be put into an invisible container sprite that handles the variables for both? Or just use one of the sprites themselves (the body)? Or would it make any difference?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I would just use the sprites themselves. It's fewer objects for you to keep track of and means using fewer objects at runtime. I'd recommend deciding for yourself which part you will treat as the 'main' part and making all of the other parts follow its lead. Otherwise you might get confused later if you're mixing and matching which things you're comparing to which other things.

    Eg. you might do it so the head controls everything. Hits on the body affect the health stored in the head, the head stores the current behaviour state for all parts, the body always inherits scaling from what the head is doing, etc.

  • Thanks for the help. I made one of the parts a container and pretty much swapped out the family reference for it across the board and it appears to be working perfectly, with only minor extra code changes.

    I went with the base part of the sprite as the container, since it allows me to spawn the base on the floor. Which will be quite the help.

  • Makes sense! Glad you got it working :)

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