TIGSource Forums

(I didn't know whether to put this in Art or here, so I decided to place it here.)

I've run into a curious problem with an isometric game engine I'm working on. As you can see from the two below screenshots, I've got walking vertically and horizontally working fine. I've managed to get the step length to fit, so that walking to a horizontally or vertically adjacent tile fits with one full walk cycle (left foot, right foot).

(http://img268.imageshack.us/img268/3516/92772230.jpg) (http://www.postimage.org/)

(http://img198.imageshack.us/img198/9355/48174535.jpg) (http://www.postimage.org/)

However, when I try to do the walking animation for walking diagonally to an adjacent tile, I can't get the step length to fit. I tried shortening it to allow for a full walk cycle, but then it just became these funny looking baby steps. I also considered lengthening the stride, so that half a walk cycle would take the character to the next tile, but then I'd have to alternate between left foot first and right foot first, which would cause problems when having the character walking to a diagonal tile and then a horz/vert tile in one fluid movement, as he would have the wrong leg in front.

I can only imagine that most isometric games with both horz/vert and diagonal walking run into this problem. Anybody know what they do?

Make the animation such that the character doesn't change position, but walks on the spot (walk in place).

When moving, you change the position of the character while playing the walk-on-the-spot animation. That way, you can move it a different distance depending on the distance between tiles on the screen. Essentially, this means that the character will move slower when walking between tiles where the center points are closer (like your bottom screenshot) - and that's ok, it is the simulated perspective. But you still use the same animation (so no baby steps).

Even better, and what a lot of isometric games do, is track the world position separate from the screen position. This will allow you to move the character at constant rate in world space, and then you get the compensation for the perspective when you transform it to screen space.

I considered that (I'm already just moving the "walking-on-the-spot" animation), but then the character's feet will slide, as the step length of the animation won't match the actual length he's walking. It looks kinda bad. Like moonwalking.

Some problem with your implementation then, probably...

Best advice is to do it properly: all movement in worldspace, then transform to screenspace. Is overall a "cleaner" way of doing it, and you can more easily see where things might be going wrong.

You have separate animations for each angle, right? You just have to animate the diagonals in the same way - feet on center of tile and edge of tile. It may look shorter, but that is just optical illusion.

In your case, foot is on center of the tile and other foot on corner. You can use the same rule for diagonal movement - other foot on middle of the edge.

Just a thought.

That's what I'm doing. That's not the problem.


No, it is shorter. The diagonal distance through a tile is ~1.4x the vert/horz distance. That's the problem.

Yeah, I think people are failing to grasp the problem here: the distance of movement is different, and the desire is for no footskate.

I don't know what you can do to fix this though, aside from "design around the problem". Currently you're using strides that are 0.7 tiles long (so, two strides for axis-aligned movement) which is awkward for diagonals.

If you change the character's scale so that their stride length is ~0.5 tiles, then axis-aligned movement will take ~3 strides and diagonals ~2 strides. Playing around with the values will hopefully let you find a place where sliding is minimal for both types of movement, i.e 0.47 will look best for axis-aligned, 0.5 looks best for diagonal, somewhere in between is hopefully good enough for both :)

I would say that probably most older games just didn't care about footskate. For instance I just played Nox, and the footskate was awful. A less realistic-looking style and/or zoomed-out scale would help make footskate a non-issue (i.e the infantry in Advance Wars have a totally non-sync'd walk animation, but it doesn't matter).

Precisely. :)

I really want to avoid half of the directions using 3 strides, since that will mean I won't be able to loop the same animation (as he will then end up with the wrong leg in front), and will cause trouble when walking along a diagonal and changing directions to horz/vert (or vice versa). I guess I'll just have to find some acceptable balance between correct stride length and footskate.

There is no solution, accept the sliding for diagonals.

Yeah, I'm probably just trying to find a solution that's impossible with my requirements (no sliding and same stride length -- I guess that's trying to fit a square peg into a round hole). Anyway, I've done some testing with various stride lengths and sliding, and I've found an acceptable balance.

You should be able to blend between movement directions, you just need to take care to sync both animations (i.e so that the same feet are down at the same time), see "How to Walk" http://home.comcast.net/~tom_forsyth/papers/how_to_walk.ppt.zip (http://home.comcast.net/~tom_forsyth/papers/how_to_walk.ppt.zip)

Regardless of stride length you'll need a walk->stand transition where the back foot moves forward to rest next to the front foot; the 3/2 cycle setup just means that you'll need two, depending on which foot is the front foot. I guess it does open a big can of worms though :(

Yeah, exactly. If you move beyond the basic "each movement from one tile to another starts with the left foot and ends with the right" it truly does open a can of worms, so I'm sticking to keeping it simple. I'm pretty pleased with the walking animations I have now, so now I can move on to running... :)

It doesn't open a can of worms. If you are doing the "animate in one place, and move linearly at the same time", then you are just repeating the walk cycle over and over, you don't need worry that while walking through a square he starts on a particular foot, or indeed any particular part of the walk cycle. You just need be concerned he starts and ends on one.

Suppose your walk cycle is tile long, and contains two strides, and has auxiliary animations to come to a stop from either the 1 tile mark, or the 0.5 tile mark. Thanks to bilateral symmetry, this is usually little extra work.

Then you could do the following. Determine the total length of the path to be walked (not just between two tiles). Round that to the nearest 0.5, and scale the animation (so there's a bit of slide). Then use the appropriate end animation, depending on how you rounded.
I.e.
walking to an adjacent tile is 1, rounds to 1. No scaling necessary, so he behaves as before.
Walking to a diagonal tile is 1.41, rounds to 1.5. You need to down his stride by 10% (either by moving him fractionally slower (causing sliding), or animating him fractionally faster, probably both).
Walking as a knight moves (1 adj. 1 diag) is 2.41, rounds to 2.5. This is scaling of 4% - smaller because we've spread out the error over the entire journey.

But it's not possible to determine the total length of the path to be walked. That depends entirely on how far the player wants to go and isn't fixed. The only fixed thing is that the character/player will always walk from one tile to an adjacent tile, so I have to do my animation based on that and just loop that.

That just results in the same kind of slide, so what's the advantage of doing this on the fly?

Sorry, I was thinking of some sort of "tactics" game where there is an entire path to animate. And I wasn't avoiding sliding just mitigating it. Single diagonals are still the worst case, so the suggestion doesn't help at all there.

Ah, yes, that would even out the sliding over the entire path instead of just across 1 tile. That makes sense. Too bad I can't use it for my game. But good idea, though.

Too late to move to using hexes?  :P

Waaaaay too late! :D