Bouncing off obstacles with 8-dir movement

Is it possible to stop player objects repeatedly bouncing against obstacles when you move into them?

I'm using the built-in 8-direction movement as it's easier (I think) than doing custom movements for 4 players - plus I'm building in XNA, so objects are limited and events and objects need to be kept to a minimum. Also, I'm taking advantage of conditions such as set maximum speeds, etc - so I'd like to keep these in if possible.

I've tried using the property 'stick to obstacles', but as soon as you touch a wall, you literally get glued to it unless you move the controller in the opposite direction.

Does anyone have any good methods to resolve this without having to build a custom movement from the ground up.

Hmm, I remember back in the 90s this being one of the reasons I got into manually programming 8 direction movements back when I was first getting into TGF... But try setting it to 'stop' when it hits a background instead of 'bounce', if I remember rightly that tones down the bouncing slightly? Also try increasing the deceleration.

Hi DJ, thanks - yeah, I had them stopping not bouncing, and they just seem to spaz out on the walls. I gave the deceleration a try and that's had no effect unfortunately - was hoping that was a special trick that would work.

Is there a way of just enhancing the standard 8-dir movement by adding another movement on top, such as vector or bouncing ball, and then making conditions on that instead of using a standard stop event on the 8-dir movement?

Not really, sadly the "obstacle jiggle" is something which comes with the 8 direction movement. You could use this as an opportunity to learn about X/Y positioning, markers and fast loops though. Check to see if there are any examples around for custom 8-direction movements,

Fair enough - time to stop being lazy then :(

Pretty frustrating that the built-in movement is so jank though

It's good really, it's just the jitter/bounce is the nature of how the movements work and... Well, the more you get to understand MMF's engine the more you understand why the built in movements have their little quirks. I've actually found it useful in the past, it really came in handy in a sidescrolling shooter I did where I could adjust the deceleration so the ship/character properly 'bounced' off of the walls, recoiled from enemies and the like, which would have been more complex to do with a custom movement. There's also the issue that we're dealing with 'legacy' movements, these movements have been in the software since it was called Klik & Play in 1994 and have remained relatively similar so that updating users can keep re-importing their old projects without breaking them (though a lot of glitches were fixed in the likes of the platform movement).

But there's only so much the 'bounce' or 'stop' commands can do. See, when creating your own movement, you basically say "When I'm holding up, move the character upwards, UNLESS there is a wall above him", meaning that the character won't move any further if he is walking into a wall. When using the 8-direction movement it's moving the character, detecting that it overlaps a backdrop and then 'pushing it back out' of the backdrop in response. That's why you get the 'jitter'.

A manually-created 4-direction movement is very easy to pull off actually, 8-direction slightly tricker due to having to use either fractions or a little bit of sine and cosine to get the diagonal movements (without this you'll find the character moves twice as fast diagonal than horizontal or vertical).

For a very simple movement (no acceleration/deceleration) you can simply make it so that when up is pressed, the object's Y co-ordinate is set to it's current Y co-ordinate -1, when down is pressed, +1, when right is pressed set the X co-ordinate to current X co-ordinate +1, and -1 when left is pressed. This will give you a very simple movement, but as mentioned before, the character will move faster diagonally than straight, so you can mix it up a little by saying 'up is pressed but neither left nor right are pressed' and such for these events, which will turn it into a 4 direction movement, then you can add the diagonals by doing 'Up+right are pressed: Set X co-ordinate to X co-ordinate + 0.5, Set Y co-ordinate to Y co-ordinate - 0.5' and so on for each direction.

Then you'll find you have a really nice simple 8 direction movement, but the character walks through obstacles. So, there are many ways to do this but the simplest (and best for beginners) is to set up four small invisible objects and stick them at the edges of your character. One as a horizontal 'bar' across the top of his head, one below his feet, and vertical 'bars' either side of him. It should look almost like a 'frame' around your character when you're done. These are your detectors. See them as a sort of 'barrier' protecting your character from walking through walls; 'wrap' them around the character. You can make them smaller, move them inwards etc. to adjust your character's 'collision box'. A shorter looking box with the character's head poking out of the top will allow the character to slightly overlap walls from below creating a 3D effect for example. Use trial and error to get a collision box that feels right. Start with them visible to check you are positioning them correctly. Do an 'Always' event, and set the objects' positions relative to the character so that they are 'protecting' him at all times. Run the app with these objects visible to make sure they are positioned properly and stick to the character properly. If you place this 'Always' event AFTER the events where you move the character, it will ensure these detectors don't lag behind at all. Name them appropriately, 'Top detector', 'Bottom detector' and so on. Then we can go back to the events and check for collisions like so: Change the up movement events to read 'Up is pressed + [X] Top detector is overlapping a backdrop' and so on for each appropriate detector for the events (the [X] means "NOT" and is achieved by right clicking the event and going to 'negate').

Finally, you want to separate the diagonals out into two events each, like this:

Up is pressed + Right is pressed + [X] 'Top detector' is overlapping an obstacle: Set Y co-ordinate to Y co-ordinate - 0.5
Up is pressed + Right is pressed + [X] 'Right detector' is overlapping an obstacle: Set X co-ordinate to X co-ordinate + 0.5

This keeps your diagonal movements at the right speed but moves the object on the different axis' separately, so that you can continue moving right if diagonally pushing against a wall from above, if that makes sense? Think of the way Link 'slides' along a wall if you are pressing diagonally against it in Zelda.

And there's a simple custom 8-direction movement.

You can add 2, or 3, or more to the co-ordinates instead of 1 to make the character faster, just make sure diagonally it is half of that, but you should learn about fastloops to prevent the character from getting stuck in walls if you move the character more than 1 pixel at a time.

If you want to add acceleration and deceleration, what I tend to do is have two internal values, maybe Xspeed and Yspeed, when the player presses up, add to Yspeed until it reaches a set maximum, when the player presses down, subtract from Yspeed until it reaches a set minimum (so up is a positive value down is a negative value), and when neither up nor down is pressed, let it drop back to zero (subtract when > 0, add when < 0, or if you're feeling fancy, divide it to have further control of the deceleration). Then the same with left and right and Xspeed. Then, when up/down are pressed but left/right aren't, add Yspeed to the object's Y co-ordinate, and vice versa for Xspeed and X co-ordinate, and if both up/down and left/right are pressed, add Yspeed/2 to the Y co-ordinate and Xspeed/2 to the X co-ordinate. Again, you'll need to look into fastloops to avoid the character getting stuck in walls here.

The reason we only add to the co-ordinates and never subtract is that the two 'axis' go positive or negative, so if Xspeed is -2 it will add -2 to the co-ordinate, resulting in subtracting 2. This method saves us from using four separate values and allows us to use acceleration and deceleration (by adding to and subtracting from Xspeed and Yspeed).

Great post thanks DJ - I tried adding the manual 4 collision boxes last night and made it so that your x & y pos changed if any of those overlapped backdrops, and it worked perfectly in conjunction with the built-in movement - until you increased your speed stat, which then allowed you to ghost through the walls. Was gutted as I thought I'd cracked it.

I'm worried that because it's a 4 player local game and on the XNA exporter (which appears to need coding extremely effectively), adding the extra objects and code will seriously drain resources. Will give a manual one a try and see how it affects things, otherwise I'll just have to live with the jitter - or some how make it look deliberate!

To be honest, some X and Y co-ordinate coding isn't going to slow anything down much. :) An advantage of the built in movements is that by default they are 'timer based', meaning if the game is slowing down they speed up accordingly, giving the appearance of 'frameskip' instead of 'slowdown' on older devices. You can set custom movements to do this manually if you're clever but it takes some learning. If you think using the built in movement has enough of an advantage to stick to it, then perhaps consider masking the bounce effect somehow, add a sound effect or something to make it look intentional?

I think I've seen something about avoiding slowdown by having a counter which increases every frame, then basing movement off that counter, so slowdown will affect the movement as well.

I do love the idea of using a sound effect to make it look deliberate though - cracking idea. I've also tried some hotspot manipulation, but the jittering doesn't happen uniformly enough to resolve the issue.

I have actually had a lot of progress experimenting with using 4 collision detectors - but you can force yourself through a corner using boost at full speed, and it seems to ignore the overlap conditions when two of the collision detectors are firing - i.e. if you force into a corner and stop moving, you'll stay still - but if you move until you're overlapping just the one wall, then it will force you back into the play area. I'm hoping with enough playing around I can get this hybrid movement system working, so if there's any useful suggestions or alternatives to using 4 collision detectors, that'd be great.

There are a few cases where you can make it so that the collision detectors move further away from the object the faster it is moving, to help prevent it from overshooting backdrops, perhaps give that a try?

I've been reading this thread, is this a MMF bug or a way you want your game to function?

There is a bug with the MMF Pinball Movement that Francois is going to look into, see:

http://community.clickteam.com/showthread.php?t=78490

If this thread deals with a "bug" in MMF, it should have attention called to it to be fixed, however if it's just a feature of how you want your game to work, then scratch this last line. ;)

Quote:

---

Originally Posted by DistantJ

There are a few cases where you can make it so that the collision detectors move further away from the object the faster it is moving, to help prevent it from overshooting backdrops, perhaps give that a try?

---

Thanks DJ, will have a go of that.

Quote:

---

Originally Posted by OldSchool80s

I've been reading this thread, is this a MMF bug or a way you want your game to function?

There is a bug with the MMF Pinball Movement that Francois is going to look into, see:

http://community.clickteam.com/showthread.php?t=78490

If this thread deals with a "bug" in MMF, it should have attention called to it to be fixed, however if it's just a feature of how you want your game to work, then scratch this last line. ;)

---

I think it's difficult to classify as a bug or not mate - as DJ says, it's likely to be an issue coming from the KNP days, so probably impossible to fix until MMF3 framework - in fact I think I might have seen a thread somewhere explaining why collision detection is ropey. Something to do with when an object moves faster than 1 pixel every frame, when it collides with an obstacle, it would be 2 pixels into that object when the frame is redrawn, so the system compensates by moving it back to its original position before it tried moving those pixels - something like that.

It's just something I need to work around as it looks terribly unprofessional to have objects jitter around the backdrops and speeding along walls when you move into them.

I'm going to have a shot at some multiple movement ideas, whereby colliding with an obstacle will switch your movement type to pinball or something, and move you away - then revert back, see if that works.

Here's what I've managed so far with the collision detectors:

http://www.youtube.com/watch?v=uqycY...ature=youtu.be

Attachment 8839

I've attached a quick capture direct from my xbox using Elgato, and have added the code I've added for the collision detection.

Everything seems to work fine apart from when you move diagonally into some obstacle blocks - and then for some reason, as mentioned above, it stops the collision detection? Is it my code?

Hmm, ya know, I do think a custom movement (set it to static and build your own with X and Y co-ordinates) would be favourable here. It won't slow the XNA exporter down enough for it to be a problem. The game looks great, I think it'd be worth doing so, you'll have full control over it too.

Fair enough thanks DJ - time to bite the bullet and put something together; sooner it's done the better I guess.

Ah - actually DJ I managed to resolve that diagonal movement problem with some flag checking in the debugger.

Turns out my collision detectors were too large, so when you moved into a diagonal set of blocks with at least 2 blocks each side, all 4 of the collision detectors were firing at once rather than just the two that I thought were overlapping.

So at the moment a hybrid system seems to be working perfectly, giving the best of both worlds - thanks for your thoughts and suggestions, certainly helped me out.


edit: for anyone who wants to use a similar system, it's vital that the events are in the order above. If you have the always position check after the collision events, it still jitters around.

Glad to help! Keep me up to date, I'd like to play the game when it's available, I have an XBox 360 and play the indie games on it (but don't yet have a developer account with MS).

Sure, no problem :)