If each segment of the tail is simply following in the path of the head, can you simply make each tail segment be a delayed version of the head? So the head is the current head, the first segment in the tail is the head 1 tick ago, the second is the head two ticks ago, etc. So use a queue system that just holds copies of the head for the last X ticks.

If the tail segments are varying from the head's previous positions, then you could probably still do that but just add variations to the delayed head positions.

If you treat each body part as a physical particle, you can connect them with joints and then simulate the system. This will make your snake look a little ropey, but it sounds like that's what you're going for.

Using Verlet integration and infinitely stiff springs would probably take the least amount of time to code up.

Along the same lines, you could use an implicit integration scheme and connect the body parts with nearly infinitely stiff springs, or you could use a physics system that supports hard constraints and connect the parts with pin joints. If you're not into writing physics code, though, you're probably better off using the first option.

John Edwards

EDIT: I just understood haphazardlynamed's suggestion. I like that better. It'll give you a slightly different look than the physics route, but it's far simpler. I guess it's like the Verlet method in the case where each body part is much heavier than the one following it.

[Edited by - PistachioPro on June 12, 2006 4:12:58 PM]

haphazardlynamed's solution is similar to the one I used recently for a snakelike creature, but for mine instead of having hard-joints (which looked robotic) I set a spring force toward the next position. It looks a bit more cartoony, but with tight enough springs it gives a very lifelike snake movement.

A spring system isn't at all complex... Hookes Law:

x = -kv

Where V is the vector between the target position and the current position, and -k is a spring constant.

Not terribly complex, is it? :)

Quote:Original post by ehudros
Reana's method is the easiest to implement but what happens is that all the links just overlap each other and reach the head after about 10ms.
i cannot simply set the next link's position to it's neighbour's previous position because a link does not jump in whole width jumps (lets say the head is at (100,100) and the 2nd link is at (120,100), after the first iteration the
head would be at (101.5,99.2) and the 2nd link would be at (100,100)...
That quickly lead me to a different approach where i store only the deviation of the head (how much it moved each tick) and then use it to move the 2nd link the same amount in the next tick (and so on for all following links).
This led to another dead end, the effect of this being that the entire snake moves as if it's a solid rectangle made up of one chunk (since if the head moved 2px up, 1 left, this behaviour is then propogated to the 2nd link, then to 3rd and so on, resulting in the described effect).

I guess what I'm picturing is like this: Imagine if you just have the head on the screen moving around (e.g. like your mouse cursor does). Then imagine if you never clear the old images of the head as it moves. You'd have a trail of heads (like drawing in a paint tool). Then imagine if you started deleting old heads after X of them have been drawn. You'd end up with a trail of X heads. Where the end of the trail is deleting itself as the head moves on. So that's what I had in mind. I assume though that you are drawing the head smoothly moving across the screen and want to have X distinct links (rather than a solid trail of overlapping head images). So then you could do something like only keep every nth head image to space it out more also, and you could change how fast you delete them or how spaced out they are based on the speed of the head. I think that's how mouse cursor trails work, which would seem to sort of be what you want.

I'm not sure how you're implementing it, but it sounds like you have all the links drawn to start with. So you are still treating them as X objects that each need to move around. But I was thinking more of just a list of all head positions. So there's just one object and you are displaying it's location (with some chosen rate and number of images shown). If it's not an issue, you can just start the snake with no length until the head first moves far enough. Then start displaying the head and the nth image in the past. Then as it moves further also show the 2*nth, then 3*nth, etc. Assuming constant velocity that would have them evenly spaced following the head. If you want to keep them evenly spaced with varying head speeds you'll have to select which past images to save based on speed. If the snake does needs to be drawn completely at initialization, you'll just need to create a fake past list of positions that displays it like you want at the start.

The spring solution should work too, and that may be more of what you want if you need to keep the snake links as independent objects. As I think haphazardlynamed said in the last post, each link moves relative to the one in front of it. For the quick 180 deg change, the problem is that for springs you are now compressing the spring (imagine a slinky or real spring - if you are pulling one direction, then instantly switch to the opposite, the spring can't loop around to where the head was - it simply compresses now).

I'm not sure how springs are implemented if you want change to direction like that. I think you'd have to have each link approach the point that the direction change occurred (imagining a slinky, you'd have to somehow make the slinky loop over an object at the end point so that the tail was forced to go through that position also rather than getting compressed). So for your snake example, I'd imagine you'd have to remember the right-most position of the head and link 1 would spring towards that point until it reached it and then change direction itself and follow the head's new direction. Link 2 would do the same and approach link 1's rightmost position. So if you are wanting to turn in angles greater than 90 deg, I think you'd need some special logic to handle those cases. If you change direction alot, you'll have to be remembering lots of endpoints. If you go with the spring solution, work on forward (< 90 deg) motion only to start with, then try to implement the reversals. Maybe there's a generic solution for handling springs changing direction like you want, but I don't think that kind of motion is spring-like anymore. Maybe simply limit head turning to 90 deg if that's an option.

My list of head postions solution shouldn't have direction issues, it's just a matter of figuring out how to choose which images to display based on the speed of the head. Maybe some interpolation between images would be needed too to handle speed changes, but if you save a fine enough list of positions I don't think that would be needed.

Quote:Original post by reana1
The spring solution should work too, and that may be more of what you want if you need to keep the snake links as independent objects. As I think haphazardlynamed said in the last post, each link moves relative to the one in front of it. For the quick 180 deg change, the problem is that for springs you are now compressing the spring (imagine a slinky or real spring - if you are pulling one direction, then instantly switch to the opposite, the spring can't loop around to where the head was - it simply compresses now).

My solution for that was to put minimum-distance springs between each body part and the other body parts, so that if they snake turns quickly, it actually would push it's tail outward. It looks pretty realistic.