The Daily Click

::. ::. ::.

Author:	Pixelthief	Submitted:	30th December, 2008	Favourites:	0
Genre:	Engine	Downloads:	799
Rated:

This is a custom top-down (8 directional) movement engine I was cajoled into making. Its a much much improved coded version of the one that is included in MMF2; it uses angular movement & a posteriori detection instead of naive movement. It boasts this:

*Can never get stuck in walls
*Slides along diagonals
*Works with ANY angles of backdrops
*Works with ANY shape/size of player
*Uses no detectors

Actually, the only thing keeping this from being a 360 degree movement engine is the 8 directional input with the arrow keys. If you just change the angle of the players movement to whatever you want, you can move in 360 degrees with proper sliding on walls. Spiffy, huh?

Review This Download

http://claniraq.googlepages.com/MovementEngine.zip (10.61 kb )

Posted by erghhhhx

31st December, 2008

Rated :

Not perfect, but it's damn close.

When I face [<] and hit wall, the "player" moves up a pixel or two. (Same for other directions).

Posted by Pixelthief

31st December, 2008

hrmm well that occurs because the object is 'swung' at an angle from each collision until it finds the first one that isnt a collision, up to 90 degrees, so when approaching a wall from a direct perpendicular, it will 'swing' outwards on the frame where the object is still like 4 pixels away from the backdrop, but the next frame would have made it collide; it will swing to the side a little bit, which will put it perfectly 0 pixels away from the wall. That has the happy side effect of making sure that if you approach a wall, you will ALWAYS be *right alongside it*; never a gap, never overlapping.

But it does have that problem of swinging to the sides a bit when it does that. An easy way to solve this is to have the code check if you can move the object pixel by pixel from the 'old' position to the 'new' position without colliding, and then close the distance. Like how the loop checks the 2 positions on either side of the object, it could also check the *same* angle, with lowered distances from 100% to 0%, and take those if it works.

but its never going to swing more than a few pixels, so I say whatever

Posted by Rob Rule

31st December, 2008

Rated :

Yeah, it's an awesome engine. Many thanks to 'thief for making this so quickly for my proect.

Posted by Fish20

1st January, 2009

What if you need it to go slower?

Posted by Pixelthief

1st January, 2009

lower the velocity

Posted by danjo

1st January, 2009

dont like it. talk about trying to overcomplicate a simple task and still dont get it right.
Comment edited by danjo on 1/1/2009

Posted by erghhhhx

1st January, 2009

Rated :

Gotta love danjo's comment... =

Posted by Pixelthief

2nd January, 2009

what part isn't right? I don't think theres any issues besides the 1-2 pixel 'swing', and I just didn't think that was a big enough deal to fix, its not difficult at all.

It might seem complicated, but mathematically this makes much more sense than having big ugly detectors strapped to your characters, and works much more soundly.

Posted by danjo

4th January, 2009

your angled movement - the most basic thing you are trying to accomplish, is wrong.

Posted by Pixelthief

4th January, 2009

really, do explain further. The angled movement works by having the coordinates on a 1000x precision grid, and applies a direct Y = Y - Sin(Angle)*Velocity & X = X + Cos(Angle)*Velocity for movement. Thus you are always traveling at the same cartesian velocity in any direction.

the derivation where 8 directional movements used '707' is just a crude emulation of this by predetermining Cos(45) as Sqr(2)/2 = 0.707106781, and thus is less accurate, and restricted to 8 directions and not 360.

and if you looked even closer, you'd notice that for collisions that slide the character along the wall, I used vector multiplication to only preserve the parallel vector instead of swinging to the side at full velocity; when moving upwards towards a diagonal at a 45 angle, you'll swing to the side at a 45 degree ratio of your velocity (70.7%). This is because in video game movements, typically when the player walks into a wall, you don't want to shunt the player to the side at fullspeed as if he was hitting left or right instead of up, but instead slide him alongside the wall preserving only the parallel vectors; if you are playing zelda OOT and walk into a stone wall at a 45 degree angle to the left of it, you will travel to the left of it a bit slower than if you ran alongside it, whereas if you run headlong into it, you will stop.

So please do explain what in that implementation is 'wrong'

Posted by OMC

4th January, 2009