How do I tweak my wall crawler?

Hi everybody,

I created a wall crawler enemy for my game. Enemy can move on the ceiling, wall and floor. Nothing special here. The reason why I’m writing this post is that I have a really odd problem with the enemy collision checks. Well, I think it’s because of collision checks. Not sure though.

First, a quick preview how everything is set up. There is a GroundChecker -sprite under the enemy. This sprite will check when enemy is on top of something and vice versa. So this sprite controls the positive corner rotations (sort of descending the wall). When enemy is not overlapping the ground, rotate it to the direction of the enemy’s movement.

There is an another sprite called WallChecker. This sprite will check when enemy is next to a wall. When it is, rotate enemy to the correct direction. Again depending of the movement direction. This sprite controls the negative corner rotations (sort of climbing the wall).

This is the basic logic. Problem is: when ever the enemy cross a seam of 2 sold blocks, it will get stuck. Sometimes it will break out from this state and continue to move forward but most of the time it will just twerk in place. I think, I THINK it’s because of the GroundChecker collision checks. So when GroundChecker is overlapping the ground and then move a cross of the seam of 2 solid grounds, it will think it’s not overlapping the ground. In fact it is, but because there was that seam, GroundCheker thinks it’s not overlapping the round and tries to rotate the enemy. Of course this will cause some problems to collision checks. But to me that sounds so odd because GroundChecker is STILL overlapping the ground. There was just that seam between 2 separate ground objects. Like I mentioned, I THINK this is the problem. It could also be that some events are causing this odd behaviour. I wouldn’t be surprised if that turn out to be the case :)

I included .capx file so everybody can check out in details the events. The enemies which are causing me the problems are marked as nb: 2’s.

h*t*t*p*s://dl.dropboxusercontent.com/u/43020976/Scirra%20forums/wallcrawler/wallcrawler_gravity_based_instant_rotation_r227.capx

Any kind of constructive help is highly appreciated. If there is something in the capx -file that you can’t figure out, let me know.

-M-

It's a collision issue of sorts, probably has to do with how the platform behavior resolves collisions.

Disabling most of the events only set the max speed and simulate pressing right. The top right slime still gets stuck on that seam. Then changing the collision polygon of the slime to a box resulted in it passing the seam but turning corners often fails due to the floating point position issues.

I've made examples for this before. Here is one possible example:

help-with-retro-enemy-behavior-move-along-solids_p713155?#p713155

It seems to jump a bit so instead I tried making it again.

https://dl.dropboxusercontent.com/u/542 ... rawl4.capx

The logic is:

move forward

if overlapping wall then back up till it's not overlapping and turn

if there isn't a wall to it's side then back up till just before there's a wall to the side and turn the other way.

In that example I back up by one pixel but it can be closer by moving by smaller steps:

https://dl.dropboxusercontent.com/u/542 ... rawl5.capx

The examples only handle clockwise motion, but it can be made to go clockwise by changing the 90's to -90 and vise versa. Also it requires the sprite to start overlapping the wall.

Anyways I hope some of that may help.

R0J0hound, Thank you for your examples! I appreciate your effort and help.

Actually, I already knew about that wallcrawler3 example :) I have also implemented that into my game. Sadly, there is also a problem. Those wallcrawler3's are moving 8 pixels above the ground object. I have tried to tweak them but I can't manage to make them to move on the correct hight. I think it's because of two reasons: 1) the grid size (16x16), is messing with wallcrawler3's origin point. 2) wallcrawler3's origin point is in the middle of sprite. Ground object's origin is in top-left corner. I think one of or both of those reasons are causing that 8 pixel offset. Not sure though.

Here is an example. Blue arrow is indicating wallcrawler3's top part (head :), NOT movement direction.

h*t*t*p*s://www.dropbox.com/s/4x059rqqa8g67l3/wallcrawler3.png?dl=0

Both of those wallcrawler4/5 examples are so simple :) They also make me realise how I could reuse the same boolean to work with multiples conditions! So thank you for pointing out that ^^

Those examples gave me so much new ideas that now I know what to do today :)

-M-