Ah, make sure to destroy the bullet before the Wait 2 seconds action, otherwise it probably will trigger other events, and no problem! I am glad to help

Move all four of those outside of the For Each (so they are on the same level). In practice the easiest way is move all for at once (hold control to select multiple) above the For Each. And it should be fine if the box is solid yes

Ah, be sure to move the "On Collision" events out from underneath the For Each, that should make it trigger only once per bullet (then you can destroy the bullet), whereas if it's under the For Each it will run for every enemy before being destroyed.

In the pink box case, change the Y value for "Set position to" from Zombie.Y to (Zombie.Y - Zombie.Height / 2)

That should center it on the zombie

Construct may not be good for really shitty devices but for all others you should be able to make even big games run at a stable 60fps and people saying otherwise are just inexperienced

Or perhaps the game they are making is truly needing that extra % performance that can slip away from using HTML5, or a specific conflict between C2 and the third party wrapper that is out of the control of Scirra yet is also your only option for distributing your game.

Ultimately, if you can keep your game at 60fps then odds are it will run perfectly fine. but 59fps and below will enter a realm of oddities. If you have WebGL access then on a GPU side you should be good, but any taxing games CPU-side will be difficult (eg: physics-heavy).

If you find that your game doesn't quite run as well as it needs to then there is the positive aspect that HTML5 capabilities are ever-improving and in a few (more) years most devices should be able to run it alright

Awesome progress I would try first just destroying the bullets when they collide first before trying those other methods, but otherwise I think adding it to the container, then on start of layout (or when a zombie is created) you position the pink box to the center of the zombie and then pin it. Hope that helps too!

Nice graphics by the way!

Frap1K Glad to see it's starting to take shape, nice looking game so far!

But remember, any objects in a container can't be destroyed unless you are also okay with everything else in the container being destroyed too. Try changing it so that the objects you don't want anymore are "Set Visible" set to "Invisible" and disable collisions (don't know that one from memory though).

Also, the healthbars being offset comes down to image hotspots, as the math for positioning the healtbar assumes it has a hotspot in its center.

As for issue #2, try adding a variable to the zombie like "alive" and have it start as 1, then in event 41 add the condition to check if alive = 1. Then you can set alive to 0 in the actions for it so it never triggers again after the first trigger

And anytime! I'm really glad to help

Sure thing Frap1K, here's a break-down of how that works:

MaxWidth is a variable I gave to the healthbar that is literally a width value for when health is at its max size (it shrinks as health decreases). This could be any number, but usually should probably be the width of the object it represents (so full health has the bar the size of the object), so it could be 32px let's say.

MaxHealth is a variable to represent what full health is (eg: 20)

Health is the current health (eg: 20 to start)

The formula is taking a ratio of current health to max health to make it a number between 0% and 100% (0 and 1).

It then multiplies that by the max width, to represent how full the bar is.

So in our examples it would be like this at the start:

Healthbar width = (20 / 20) * 32 = (1) * 32 = 32px

But at half health it would be:

Healthbar width = (10/20) * 32 = (0.5) * 32 = 16px

At 0 health it's:

Healthbar width = (0/20) * 32 = (0) * 32 = 0px

Hope that helps!

add zombieheadbox and zombiebodybox into the container for the zombie, and make sure there is only one of each type these objects in the layout: zombie_Health, zombieHeadBox, zombieBodyBox.

The system will automatically create those afterward when the game is started/running for each zombie, so you can place or create or destroy zombie objects and the other stuff will be added and removed for you <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

That also means that the actions you made for sub-events 42 and 43 can be moved straight into the "for each Zombie" in event 41. In fact, you can copy the actions from event 44 into 41 as well and delete that.

That way there is only:

41 For Each Zombie -> All the actions from events 42, 43, 44

42 (was 45) Bullet: On collision with zombieBodyBox -> Zombie subtract 20 from Health

43 (was 46) Zombie: Health < 1 -> Set animation to ....

However, that last event might be better as a sub-event to 41 you might have to test for that

Hope that helps! Otherwise, please upload your capx to Dropbox or Google Drive (free) and then share a link here (to get past the link filter replace the .'s with (dot)'s eg: http://www.google.com/ becomes http://www(dot)google(dot)com/)

Rather than doing it using UID, use containers from the properties bar on the left and add a single healthbar object into the container of the enemy/unit. Then you can just do something like this capx: https://dl.dropboxusercontent.com/u/471 ... thBar.capx (pretty much the same as the Construct Classic one actually <img src="{SMILIES_PATH}/icon_razz.gif" alt=":-P" title="Razz"> )

To learn more about containers check this manual page: https://www.scirra.com/manual/150/containers

If you only wanted enemy healthbars to appear when the enemy is being hurt, make it visible/invisible rather than creating and destroying it (as objects in containers are created and destroyed together automatically).

Hope that helps! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

Frap1K here's a cap that should be straight forward, but let me know if you have any questions <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile"> https://dl.dropboxusercontent.com/u/4714446/HPBars.cap

NW v10.5 is only version that works decently with our game, but we also found that we need to use Construct 2 r192 (anything newer or older breaks our game)

sqiddster I think he's joking about "HTML5 + WebGL with Chromium-based wrappers" being ever considered faster than native in real game situations.