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

Get help using Construct 2

Post » Sun Jul 06, 2014 7:03 am

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.
B
4
Posts: 37
Reputation: 276

Post » Sun Jul 06, 2014 3:54 pm

@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: https://www.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!
You do not have the required permissions to view the files attached to this post.
B
6
S
2
Posts: 79
Reputation: 608

Post » Sun Jul 06, 2014 5:45 pm

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!
B
4
Posts: 37
Reputation: 276

Post » Sun Jul 06, 2014 7:05 pm

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
B
6
S
2
Posts: 79
Reputation: 608

Post » Mon Jul 07, 2014 4:08 am

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!
B
4
Posts: 37
Reputation: 276

Post » Mon Jul 07, 2014 4:49 am

Tell me what you had trouble understanding and I'll try explaining it in more detail :D
B
6
S
2
Posts: 79
Reputation: 608

Post » Mon Jul 07, 2014 5:59 am

Haha, I don't even know how to explain what I don't understand. ;) If coding isn't your thing, everything just stops making sense after a few sentences. I can tell what you're saying is correct, but there's no way I would ever be able to figure any of it out on my own.

When I get the sprites ripped and can post a more working playable capx, I'll upload it and maybe you can take a look at it and make a few fixes if you have time and wouldn't mind. I think the basic engine itself could be useful for several types of games (like Lethal Enforcers, Nam '75, or Punch Out), but it's just not something I'm going to get right without help.

Thanks again. :)
B
4
Posts: 37
Reputation: 276

Post » Mon Jul 07, 2014 6:08 am

Sure thing. I'll see if I can help you then
B
6
S
2
Posts: 79
Reputation: 608

Previous

Return to How do I....?

Who is online

Users browsing this forum: No registered users and 8 guests