Stopping enemy animation upon overlap (ty Monitz87! + capx)

Just want to say thanks to Monitz87 and everyone who has helped with my screwy problems so far. I'm having some new problems that I cannot find solutions for though, and I hope by posting the .capx, it will be easier to figure out.

This is a rough 'first person fighter', a little bit like Punch Out, but movement is like Dynamite Duke where you can pan the screen and both you and enemies can move. It has a working combo system and other features, but they are not included in this .capx for easier troubleshooting.

[attachment=0:2hasv9qg][/attachment:2hasv9qg]

If you play it, you'll see that the player's bounding box (player_bbox) and the enemy_bbox only move along the x axis, and that the enemy is always trying to overlap its box with the player's, at which point it will attack. Everything works well except that when the enemy's bbox does overlap the player's, the enemy's walking animation needs to stop immediately. It doesn't, in fact it continues to play through all of it's remaining frames of animation before attacking. You can see this happening by just moving away from the enemy a little bit and watching the enemy's walking animation frames (it's really clear in the debugger).

Any help would be appreciated! If I can get this working well enough, I will try to make the basic template and combo system available for everyone to use. Thanks in advance.

Anyone? Please, I could really use some advice to try and fix this issue. I was checking tutorials half the night and couldn't find anything that helped.

Sorry to ask again, but I've had to stop using Construct until I can get this problem solved. If anyone has any ideas, I'd really appreciate hearing them.

It's not that the animation isn't stopping, it's just that your logic is somehow flawed and sets it to the "walkL" and "walkR" animations again when it shouldn't. Maybe you need a variable to track the overlapped state. Bit vague sorry, but see if that triggers any thought processes I've added a few log messages to show this.

[attachment=1:1zg2vjnt][/attachment:1zg2vjnt]

Edit: ok, so I thought I'd have a good go at this as I might learn something. See the capx below. It seems to be doing what you want.

[attachment=0:1zg2vjnt][/attachment:1zg2vjnt]

Thank you very much for responding and for the capx. It does work, good job! (edit: oh, I guess not, sorry!) I'm not at all familiar with Browser commands though, in fact I had to get an extra plugin before your capx would even open here. Those commands will still function correctly if the game is packaged as a Node-Webkit, correct?

I hate to say it, but it's actually not working properly; if you move away from the enemy once its entered the player's bounding box, it sometimes goes back into its walking animation and then freezes until the player moves back into range. I'm really surprised that something that would seem very simple is so difficult to implement.

I appreciate your help so far though!

In event 25, disable the action "enemy_bbox: Start ignoring 8Direction user input" and it works.

Thank you, disabling that does stop it from freezing. However, it also causes the enemy to interrupt it's attack animation to pursue the player if you move out of range during an attack. It is important that the enemy's attack animations are not interrupted because it allows you to avoid attacks and then counter.

You should be able to see the enemy play out it's full attack animation even if you move the player bounding box out of the way during in the original capx. So far, I have not found a way to be able to interrupt the enemy's walking animation in order to attack, but force any attack animations to play through. No matter where I use "Stop Animation", it only seems to make the enemy freeze.

That's true. It is difficult to think some of these problems through. The event based nature of c2 is like concurrent programming in other languages and not easy to get your head around.

The thing I took away from working on your capx is to separate the changing of state variables from everything else. So set state variables in one event and act on those states in separate events. I can't help thinking that using Groups and enabling/disabling them to enable or disable certain events might work here. I'm looking into using that technique more myself. The are also state machine plugins which might be useful to you.

Why not program you own overlap detection by checking to see if the enemy object exists within an x-y range relative to the player? This can be achieved with 4 lines of code.

This worked for me in your capx.

Cheers!

Dan

You might have done a little more to that capx than four lines of code because putting them in sure didn't work for me. I appreciate the help very much, but this is just getting too frustrating. I don't know why those 'log in console' commands are necessary and I don't really understand why I would have to create my own overlap detection when there are at least two ways (imagepoints and collision overlap) that *should* work. I expected a challenge when it came to enemy AI or complex combos; the fact that I'm stuck dead because I can't get an enemy to stop an animation using logic that I would think makes sense is just silly.

I'm a graphics guy, not a coder. Think I'll just wait until I can collaborate with someone and stick to what I know. Thank you all very much for your suggestions, I appreciate the time you took to help.

Joy

Don't give up. Even though Construct 2 is incredibly simple for a game engine, it's still hard to get accustomed to the event system. I had to almost scrap your event sheet and start over. It took me the better part of 3 hours to distance myself from the way you were approaching your problem, because I was stuck trying to fix your code rather than re-do it. I'd say you were suffering from tunnel vision. I have attached a working version of what you were trying to do.

I'm awfully sleepy so I won't explain what I did in detail (in any case, the capx is pretty much self-explanatory). If you have any doubts, just leave a reply here and I'll get back to you.

The only thing I think needs mentioning is that I removed the Wait actions you used and replaced them with a 'wait' animation that lasts 0.1 seconds. I'd advise you to steer away from the Wait action unless completely necessary (it is prone to cause unintended behavior unless you are really familiar with it and most of the time it can be sidestepped).

For more information about the Wait action, read this tutorial: scirra.com/tutorials/56/how-to-use-the-system-wait-action (as you can see, it isn't as intuitive as you might think).

I hope this helps you,

Happy Coding!

Thank you, that works perfectly. I feel bad that you worked for three hours on it though! Construct is definitely the easiest of the game engines that I've used, but that makes it even more frustrating when something simple doesn't work the way you expect. It's also difficult when you're trying to do something that hasn't been done many times before and can't find a lot of examples to learn from (if only I were making a top-down zombie shooter or platformer!) I'm still not entirely sure why the problem is *not* happening in your fixed capx (was it the direction variable that fixed it?), but at least I can clearly understand what you did here. Great work, I really appreciate it.

I hope you won't mind if I have any additional questions in the future, but I won't ask until I feel ready to give up again. Thank you very much!

Actually, there were several problems with your implementation.

The Wait action does not put the whole event sheet on standby for the supplied duration. It only queues the actions that come after it in that event block (and subevent blocks that branch from it) to be executed after the delay. The rest of the event sheet runs normally while you're waiting for the queued actions to execute.

You had events that queued the walking animations to start after 0.1 seconds, and your 'attack' event only started the attack animations when a 'on any animation finished' trigger was fired. This was wrong for two reasons:

1) Let's say that the enemy is already walking left and on a certain tick you enter the 'chase' event and the enemy is still to the right of the player. That would satisfy the criteria for the event that queues the walking animation (which was already playing) to start again after 0.1 seconds. Let's say that on the very next tick the enemy bounding box is overlapping the player bounding box. You stop the walking animation, but since ticks normally take between 0.02 and 0.016 seconds, you still have a 'start walking animation' action queued (several, actually), so when the 0.1 timer is reached, the animation starts again. Since your 'attack' event only starts playing the attack animations 'on any animation finished', it has to wait until the 'fresh out of the queue' walking animation ends before starting any attack animations, which caused your problem.

2) If you had started using Wait correctly to fix that, you would have still had problems because you stopped the walking animation within the 'chase' event, so the 'on any animation finished' trigger subevent on your 'attack' event would have never fired (triggers as subevents only fire if their condition is met while inside their parent event). In fact, if you disabled the Wait actions in your solution, the enemy got stuck at the end of a walking animation even if it was in attack mode.

Aside from that, you were using wait every tick, when what you intended (I assume) was for the enemy to wait only the first time he found himself out of the player's range (that's why I used Trigger Once in the attached solution). You were also restarting the walking animations every time you did that, which would have looked awkward when you started using real sprites. The sensible choice there is to have the walking animation loop and only stop on command.

The 'direction' variable was necessary in order to use the waiting animation* properly, because you only begin movement when the waiting animation is over, so you need some way of knowing the direction the character has to walk to when the 'on enemywait animation finished' trigger fires. The only alternative would have been to place the trigger inside each of the events which compared the positions of the bounding boxes, which is a bad practice because you have to duplicate actions and that is never a good idea.

The event you were using to change back to chase mode was also a bit flawed. It worked, mind you, but it was confusing since it bounced the enemy back to chase mode even if he was still in the player's range, which would bounce him right back to attack mode. This could have caused you problems in the long run if you ever wished to add more complexity to the enemy AI.

I don't know if I'm missing something, but I'm guessing you can understand now why your approach wasn't working as intended.

Cheers

*: you can replace it with a Wait action in the solution with very few modifications. I still don't recommend it, I find that using Wait is less clear, and you can use the wait animation to have the enemy look confused or whatever, so it's an added bonus

I probably am going to have to quit for now because not only do I not quite understand some of your explanation (despite you explaining it all very well), as soon as I put the player's attack animations back in and set up the hit detection, the enemy won't revert to the 'chase' or 'attack' modes after getting hit. It worked in my original capx, but now that the enemy behavior has been rewritten, I don't know what to do to get it working again.

I can't keep asking every single time I get stuck and I'm not having much luck figuring it out myself. When I can, I'll try to add sprite rips from a similar existing game and make the unfinished capx available here for anyone to try to improve upon or fix.

Thank you again for your time and expertise!