eli0s's Forum Posts

  • You want something like this?

    http://eli0s.com/Tests/Zombies.capx

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • For the first part you could try comparing the critical ability of the player and the enemy with the "system compare 2 values" and then add the following to the damage value: choose(0,0,0,normalDamage*2).

    The logic behind it is that you are already subtracting a normal damage value on every strike, so when the critical hit condition is met, add to the normal value some extra damage (normalDamage*2), but do it by chance of 4 to 1. The choose expression will do exactly that, every time it will choose between the values within the parenthesis, in our case we have (0, 0, 0, Xdamage) so, 25% chance of getting extra damage.

    For the second part, I am not sure what you mean, but perhaps you want a short period of invulnerability for the enemy between each time he gets hit? If yes, you could either add an "is animation "enemyHit" NOT playing" condition (invert the is playing by right click on the condition and choose invert), or add a Boolean instance variable (e.g. "hit") to the enemy and a timer behavior, and each time the enemy is hit (add a condition to check if he can be hit using the Boolean), set the Boolean to "true" and start a timer countdown. On the countdown end, restore the Boolean to false, so the enemy can be vulnerable again.

  • If you are still interested, you could also use an opaque layer to change to the night time. The fade-in logic however is the same as with a sprite:

    http://www.eli0s.com/Tests/NightTime.capx

  • Hmmm... It's more complicated than I expected. I like what you already have set up. I can't figure out how to make the instances behave separately with an Instance Variable and the "For Each" loop gives me an error at run time.

    The only thing I am confident that it will work is to use different objects for each enemy, but this isn't very practical if you have a lot of enemies. Actually, it's rather dumb...

    Perhaps an advanced forum member can help here..?

    I am sorry for not being able to help

  • This is the best I can do. It works, but there must be a more elegant way to do it.

    http://eli0s.com/Tests/EnemyHealthBars.capx

  • Make sure that the lifebar object exists on a layer with its parallax values set to 0,0! You can get access to a layer's properties by clicking on a layer and then look at the properties panel.

    All objects within a layer with 0,0 parallax values will not be affected by the scrolling. They will remain at their initial position on the screen, something that is ideal for HUDs.

  • I am not sure if families are available on the free version of Construct 2.

    Anyhow, I guess you are using instances of the same object and that is why they behave the same. You can either:

    1) Create a separate entity (clone object type) so that they'll be totally independent from each-other

    2) Create an Instance Variable (perhaps a text so to give your enemies names) and in the event sheet create conditions that check (compare) the Instance Variable (name) and add actions accordingly for each enemy.

  • Beaten at the finish line

    But the "trigger once while true" should be also valid.

  • I believe what you see is the result of new sprites being created every tick on top of each other and playing the animation with a phase difference of one tick (so you see all the frames overlaying).

    You can confirm that easily with the debugger, just see the number of objects, it should increase rapidly over time.

    This is happening because when the condition '"is Group "mole1" active" becomes true, it stays true, thus performing the same actions over and over again.

    Add a "system | Trigger once while true" condition below the "is Group "mole1" active" condition, to make sure that you create only one "Mole9" object.

  • Perhaps with an instance variable, a Boolean ("Collected") set to false..? The ones that weren't collected and still have the Boolean set to false, could be checked upon start of layout and set hidden/invisible.

  • Since you spawn the enemies at run time, obviously you can't see them on the editor. Perhaps if you assign an Instance Variable on the object(s) that you use to spawn the enemies, and use the variable to define which instance spawns what enemy, then you could have a better sense of the spawn objects and their role in creating enemies.

  • The Set Position should suffice for the first layout. I think that the anchor behavior was messing around with the position. You don't really need it, I think it's useful in circumstances like when the browser window change in size and you want the objects to dynamically adjust within the screen. Since you are interested in 0,0 coordinates, these do not change no matter what, so if you set the position once per layout you are ok!

  • Ashley I stand corrected, I understand now the flaw in my logic. The result is indeed much smoother. But the stutter remains at the same levels as I describe it on the other post. In a little more complex scene (with a platform behavior and a couple of solid objects), every now and then there is a gap in the fluidity of motion. It's very small, not necessarily tied with a drop in frame rate (just enough times to raise suspicion) and, to my eyes, annoying. I tried to capture my screen at 60fps to show you what I mean, but using a screen capture software really destroyed the frame rate.

    Perhaps it's just me. I am one of those guys that was annoyed with the old CRTs because of the flickering.

    Thanks for your response, I learned something again today!

  • Hmmm... The top left of the screen should always be 0,0 on a 0 parallax-ed layer.

    Make sure that the lifebar object exist on a layer with 0,0 parallax and 0 scale factor and on start of every layout set its position to 0,0.

    You can do that with code so it happens automatically for all layouts:

    On Start of Layout---> system | create "lifebar" on layer "HUD" at (0,0).

    Of course this means that a layer named "HUD" should exist on every layout with its parallax and scale factor values set to 0.

  • Ashley In rayrays' example I notice the same stutter phenomenon that we discussed in this topic https://www.scirra.com/forum/viewtopic.php?f=146&t=99765.

    In general, the fastest the movement is, the more evident the discontinuity gets. Surely, there has to be a way to overcome this, I mean, I am previewing this on a very decent desktop, the fps are fixed at 60 and yet, if I stare on one point on my screen, the stutter is very prominent and it occurs constantly, some times even more than once every second.