health bar for each enemy

0 favourites
From the Asset Store
Be discreet and rescue your friends from behind enemy lines.
  • How do i health bar on top of opponent, i mean health bar for each enemy

  • You can do it the same way I made the shadows for the coffee beans on the Monjava website I just made:

    <img src="http://dl.dropbox.com/u/604141/Public%20CAP/images/For-Each-Bean.png" border="0" />

    This should help somewhat, hopefully. I got rid of any events that aren't really important. ;)

    ~Sol

  • Ok i will try this :)

  • I'd like to point out that you can simplify it by taking advantage of the way events work. When there are an equal number of Bean1's and Bean1shadow's then this will pair them.

    Every Tick:

    --Bean1shadow| set position to (Bean1.X, Bean1.Y+14)

    --Bean1shadow| set angle to Bean1.Angle

  • I'd like to point out that you can simplify it by taking advantage of the way events work. When there are an equal number of Bean1's and Bean1shadow's then this will pair them.

    Every Tick:

    --Bean1shadow| set position to (Bean1.X, Bean1.Y+14)

    --Bean1shadow| set angle to Bean1.Angle

    I actually tried this method, and all shadows went to a single bean.... at least in C2. Lucid wrote me a up a quick pairing example, and it worked awesome :)

    ~Sol

  • It works, here is a example as proof:

    http://dl.dropbox.com/u/5426011/examples%209/container.capx

    Using the UID instead has certain advantages like when you want a certain object paired with another. My method is if you just need another object type paired up and it doesn't matter if it's always the same one.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Yeah, you could always use the object index as well.

    Still, containers are absolutely perfect for this.

  • It works, here is a example as proof:

    http://dl.dropbox.com/u/5426011/examples%209/container.capx

    It looks like this shouldn't work and yet it does.

    In conditions 5/6 you pick the first instance of healthbars / shadows why does this destroy the one that matches the underlying object and not the first instance created ?

  • Anyone?

  • R0J0hound or Ashley probably could give a better explaining.

    As far as I can word it, I guess the pairing code Ashley included in C2 makes it so that instances of different objects get associated when created in the same event.

    So when you filter Sprite instances (health <=0) and then run through all the instances resulting as picked (for each sprite) in the subevent picking the first instance (index 0) of another object type returns the associated instance with the current sprite instance.

    That's surely not clear, I'm sorry I don't know how to word it better for now.

    As rojo said, it has to do with how events work and are processed.

    One condition after the other from top to bottom and subevents pick up with the instances already filtered from the top level event.

  • The objects are not exactly paired to each other, it is enough to just delete one of the instances.

    To help illustrate what is happening you could replace "Every tick" with the more verbose version here:

    System | For "" from 0 to Sprite.Count-1

    System | Pick Sprite instance loopindex

    System | Pick shadow instance loopindex

    System | Pick healthbar instance loopindex

  • Does C2 maintain one SOL per object type?

    Line3 sets the Sprite SOL to the one we clicked on. So that array will usually only contain one Sprite.

    Line4 checks that picked Sprite (array) against Health<=0. So far so good. Then we have the ForEach condition which according to the manual does not reset the SOL, thus by doing ForEach Sprite we would only iterate over that one sprite coming from line 3.

    Then we get to line 5 which is System.Pick Healthbar instance 0. So far we have not filtered any healthbars so I would expect System.Pick to operate on ALL healthbars in the layout, and instance 0 of all healthbars could be any which one not necessarily the instance we are looking for <img src="smileys/smiley5.gif" border="0" align="middle" />

  • Yep, that is all correct. The purpose of the "for each" is for the situation multiple objects were clicked on at the same time.

    It does not matter if the shadow of another sprite is destroyed. The shadow is paired in the "every tick" event.

    For example if you have four sprite instances:

    Sprite1, Sprite2, Sprite3, Sprite4

    And four shadow instances:

    shadow1, shadow2, shadow3, shadow4

    Then they will be paired Sprite1:shadow1, Sprite2:shadow2, ... etc.

    If Sprite3 is clicked on and destroyed and the first shadow instance is destroyed.

    Then the instances will look like this:

    Sprite1, Sprite2, Sprite4

    shadow2, shadow3, shadow4

    Which will still work fine even though different instances will be paired together. The effect is purely for a visual effect so it does not matter if the the same instances are paired together.

    If you want the same instances to be paired together then you would need to use the UID method.

  • Thank you R0J0hound for taking the time to explain this! Now it makes perfect sense.

    I thought there was some special trick going on in the destruction part, but we just destroy arbitrary healthbars/shadows and then grab whichever one is available for display purposes during the next tick.

  • It does not matter if the shadow of another sprite is destroyed. The shadow is paired in the "every tick" event.

    Gaaah, that's what I was overseeing.

    Thanks for the clarification R0J0hound, always much appreciated.

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