next »

[jamesprimate]

well now THATS disturbing! quite Giger-esque. motions look great though!

[Lexonite]

looks like the lizard is just floating and the legs are being dragged. There's no thrust from any leg, or pull.

[tchassin]

looks like the lizard is just floating and the legs are being dragged. There's no thrust from any leg, or pull.

If I remember correctly, it was explained in some older post (no idea when). I think JLJac explained that the legs were actually dragged forward when to stretched, so you got it pretty spot on.

[JLJac]

I'm working on it - it's going to drop your jaw when it's done 

Update 299
Not all days can be good days, and today certainly wasn't. As you can see from the earlier gifs, the steps the lizards take are too small. I set out to do something about that.

I identified the problem to be this; when the foot decides that it is trailing too far behind it looks for a new grip position. It finds one that is a good choice at the time, a grip in the terrain somewhere in front of it in the traveling direction.

The problem is that it takes a little time for the foot to travel there. When it gets there, some five frames or such later, the entire body has moved forward. Suddenly this spot isn't in front of the body at all, but right beneath it. The fact that the limbs never really get in front of where they are connected to the body makes it so that they trail behind, and look like they are being dragged rather than the source of locomotion.

My idea for a solution has been that they should have another phase except from just gripping and moving towards a new grip. This phase would be the "catching up" phase. When the limb trails behind, it shouldn't immediately look for a new place to go, first it should just focus on moving forward. When it catches up with where it's connected to the body, then it should look for somewhere to grip in front of it.

This looked very promising to begin with. The lizards stopped the tip-toeing and dragging their legs behind them, and took long, menacing, sneaky strides. Then a bunch of problems started to show up.

It only really worked on flat floors, in more complex terrain the limbs would reach for places they weren't actually able to reach. Upon closer inspection I noticed this also happened on the flat floors at times. If all the limbs were synced they'd all reach forward, but with no limbs used for locomotion they wouldn't ever get there, and the lizard would just lie there pathetically stretching all four feet towards some destination it's never going to get to. The same could happen when the direction changes, when the lizard got out of stunned mode, etc etc.

I've tried so many workarounds. The most immediate idea was to have the limbs reach far only when the lizard is moving fast, but closer the slower it moves. This worked OK, but with bad timing all limbs could still reach far at the same time, and there it would lie twitching on the floor. I tried a lot of other stuff, such as basing reach distance on how many other limbs are currently connected, and so on and so on.

You might think "only accept reach destinations that are actually within reach!" but it's not quite as easy as that. When the reach destination is determined, the body is in another place than where it will be when the foot actually touches ground. The only solution I can come up with on the go is some very sophisticated algorithm that first chooses a preliminary reaching position, and when trying and failing to reach that re-evaluates to the closest valid position...

Didn't crack this nut today o_____0 Remember kids, procedural animation isn't only fun and games! Take heed!

[Belimoth]

Why not just have the feet aim to grab a connection point that is ahead of where the body is going to be when they get there?

[JLJac]

That was the idea, and it worked! But what if the body doesn't get there? Because the whole creature decides to turn around and go the other direction, or because all four limbs aim for the sky simultaneously, none of them get a grip, and the whole thing just ends up on its belly, reaching for a future that will never come?

I think there is a solution in having it re-evaluate if it ends up in a position where it is stretching but not reaching, and the second time around only consider strictly valid grasping points... But I'll have to let it simmer around a bit until I can come up with a way of turning it into actual code.

[Christian]

Now I know absolutely nothing about programming so this idea might make no sense at all, but okay, you have a ghost system that lets the AI predict where the slugcat might be based on variables like speed, terrain, etc. Could a similar system be implemented for the lizards' limbs? Have them predict where they might end up based on the lizard's speed and other factors and have the limbs adjust to the most optimal location accordingly?

[gimymblert]

You may need to look at locomotion system, there is some on unity


wait till 5:00(source code available on asset store in unityscript, use a javascript to c# translator: http://www.m2h.nl/files/js_to_c.php)



https://www.youtube.com/watch?v=Y4aRhYT9BJo

also final IK is a solution for helping (but in 3D) https://www.youtube.com/user/SnuffThePuppy/videos might be an inspiration
http://forum.unity3d.com/threads/full-body-ik-mech-spiders-and-much-more-about-to-hit-the-asset-store.217693/
http://forum.unity3d.com/threads/final-ik-full-body-ik-aim-look-at-fabrik-ccd-ik-beta-released.222685/

[Lee]

The way I would have thought about doing it would be like this:

Have an aim target for each foot (obviously). Each aim target can be in one of two modes, grab mode and move mode.

Grab mode is pretty obvious, the foot sticks (grabs) to the set contact point. This target is a static anchor point and is an absolute, world based, position. Thus grab mode is not the default mode and is only a valid state for feet attached to a surface. When in grab mode the only way out of this mode is by receiving a release command (switching mode) or if the grab target becomes invalid (spear or other physics forces overcoming the attach strength).

In move mode the target location is a relative position in respect to the shoulder joint and it is also not just a static anchor and should be updated and repositioned on the fly so that you never aim for an impossible target. You specify the lizards reach radius (arm length, from shoulder joint) and every update, based on criteria you set the target to a point within that reach radius that is closest to the actual AI goal. Because the point is limited to a radius of arms length from the shoulder the position should always be valid to move to. This is the default mode for the feet, whether flailing in the air just trying to reach the closest surface.

For walking (coming from a grounded state with all able feet being in grab mode) you chose which foot goes first and set a flag stating this and set the aim target to move mode, and the same but with the opposite leg on the other half of the body (e.g. top left and bottom right are now in move mode). The target you aim for should be a ground point within the reach radius that is closest to the goal (which I assume will be towards some kind of pathing node). When both legs become grounded again that's then end of the move update and if you're not at the goal you just start it again, but last time you set a flag which stated which leg was used and you use that to take off on the opposite footing (since each update is only one stride this is important to avoid double-striding with the same leg -and getting nowhere because the reach radius should be maxxed out).

Or you can have each pair of legs work as separate units, but this could lead to desynchronising of the legs if one pair gets stuck for some reason and then it could lead to a situation where one pair of legs is able to inch forward taking smaller and smaller steps until they end up almost tapping on the spot whilst the other pair is trying to walk normally:


Also in move mode you might want a phase-based system where you first aim to a target that is floating below the shoulder, then when you reach that target aim just forward of that point by a distance equal to the size of the forearm, and then aim for ground contact as above... This is essentially doing walking animation.

[JLJac]

Thanks for the awesome input guys!

@Christian, that's a good idea. The problem is that the tracker is on another scale, it operates tile by tile, while the feet are pixel by pixel. Also the lizard knows where it is going most of the time (forward) but in some scenarios such as turning around the prediction turns out wrong - it can try to predict, but it can't see the future!

@Gimym JIMBERT, as always, thanks a thousand times for the interesting resources!

@Lee, wow! That's awesome! Actually what you describe seems rather close to what I have, except that you describe some kind of "overmind" controlling all the four limbs, making sure that they move cross-wise etc. In my solution the limbs are more autonomous, which has good parts and bad parts. The good part is that they are less static - they don't need permisson to move, making the movement less of an "animation" and more intelligent. The bad part is that they're not intelligent, and I end up with stupid bugs. I actually implemented something similar to your solution, but instead of placing it in a coordinator object I connected the feet into pairs and enabled them to know some stuff about their partner, changing their behavior depending on what the partner is up to.

Update 300
Ok, so I haven't really had a huge break through, but I've moved forward through blood sweat and tears instead. The new solution has many little mechanics in it, but the core difference is this: The first time a limb tries to find a reach position, it reaches too far in front of itself, to where it expects the body to be in the next couple of frames. If the body does catch up and the position actually becomes reachable, all is good, it goes there and grabs the terrain.

If the lizard changes direction or some other weirdness however, so the target never becomes reachable, a counter starts to tick. Every frame that the reach target is outside of the limb's reach this counter increases. When it reaches a certain number (I used 15 frames) the limb decides that OK, this target is probably not going to be within reach, ever. It then tries to find a new target, this time playing it super safe, only going for terrain that is strictly within reach.

On top of this other systems are implemented to smoothen the walk cycle. One such is that if every limb is grabbing terrain, the one that has been doing so the longest will automatically let go and go find a new target. This keeps all four limbs from syncing up in the same cycle of grabbing and moving.

Another one is that the front limbs and hind limbs are connected into pairs. Or rather, one of them is aware of the other. The one hind leg that knows about the other hind leg will try to be at the opposite of the other's cycle, and the same for the front legs.

Slow motion of pink lizard moving (and looking up, I have my mouse pointer up there):



The steps are longer, and the movement is smoother. There are still problems in more complex terrain though, but I feel this is a good start.

For the green lizard I don't want the movement to be smooth, and have allowed the limbs to sync up:



I'm still not entirely happy with it though. The legs should move at the same time, but not sync up so perfectly. I'll look into making them have just slightly different grabbing targets. Also the foot should obviously not move above the hip making the leg turn like a wheel.

The blue lizard takes smaller steps. It looks kind of strange now because the limbs are as big as those of the others - that'll become more proportional once I get the movement down.



In 2D terrain that isn't just a flat floor many of the problems become evident. The limbs have a bit of flailing, and some hesitation when they try to reach for terrain but fail and change their minds. For these specific climbing scenarios the limb movement actually looked better before I made the changes, so I'm contemplating making some kind of differentiation between floor crawling and climbing and using different systems for limb movement depending on the situation.

Hahaha and also, I've finally encountered the backside of inheritance! All this messing around with the limb code has somehow made the poor slugcat's arms disappear! Don't worry though, all the code I wrote is intact, so getting them back again will probably be a quick fix

Getting there!


Another thing!
Monday I'm going to do some serious relocating of myself to way over in Seoul! The idea is that I should get to work as quickly as possible, but there will probably be a lack of updates at the beginning of next week. Travelling will take something like a day and a half in itself, then comes being jetlagged, re-adjusting, finding somewhere to sit and work, etc etc. But by the end of next week I hope to be back in business!

안녕히가세요!

[Lee]

@Lee, wow! That's awesome! Actually what you describe seems rather close to what I have, except that you describe some kind of "overmind" controlling all the four limbs, making sure that they move cross-wise etc. In my solution the limbs are more autonomous, which has good parts and bad parts. The good part is that they are less static - they don't need permisson to move, making the movement less of an "animation" and more intelligent. The bad part is that they're not intelligent, and I end up with stupid bugs. I actually implemented something similar to your solution, but instead of placing it in a coordinator object I connected the feet into pairs and enabled them to know some stuff about their partner, changing their behavior depending on what the partner is up to.

To explain better, in my idea the controller initializes by saying simply "okay leg(s) start moving", sets the controller state to moving, and saves which legs were moved to avoid another stride with the same leg (if unwanted). Then all the controller does in the movement state is to check for an end condition which would be "all legs have stopped moving" or something, and that's it, that's all the control it has.

The intention of the controller is purely for synchronisation purposes and doesn't actually handle any leg movement itself. It simply sets an amount of legs to start moving then chooses which of the legs should be set to move. How many legs are moving at the same time and which ones specifically depends on the overall AI state (0 for idle, 1 for climbing, 2 for walking, 4 for flailing ... L and R alternating for walking, leg with oldest grab target for climbing ...).

The actual leg movement would be completely handled by the legs themselves. I went on about "move mode" and "grab mode" before but really it's just basically "should I be moving to a new foot target (yes/no)" and this boolean state is all that the controller "overmind" handles. In move mode it finds the best move target within it's reach range for the AI state/behaviour and moves to that point. In grab mode it simply does nothing (unless the grab target becomes invalid, in which case it automatically switches to move mode -or perhaps a special invalid mode indicating invalid grab).

As I said before you could easily change this to one controller per pair of legs, I just don't think it's a good idea for reasons I've mentioned. And you can't avoid both right or both left legs moving at the same time in an unbalanced way (you can see this happen in the first gif in your post, for most of it both blue legs are striding at the same time) without some cross-leg-pair syncing.

[JLJac]

안녕! I'm arrived in Seoul, and spending my time trying to sleep during the night and not sleep during the day, both of which are easier said than done. But I think I'm getting there. I've also been (sleep)walking around my new neighborhood, and checked out where there might be some starbucks or something that could be suitable to sit and work. Other events include realizing that any small bit of Korean I might have ever known is now gone, so getting food at a restaurant is a sort of culinary Russian Roulette. Actually every interaction is like a sort of Russian Roulette if the only two words you know are "Yes" and "No" and you're just trying to sprinkle them somewhat evenly throughout the conversation. My landlady seems somewhat annoyed with me, but as I have a very dim idea of what she's actually saying I don't know for sure. Tomorrow I hope to have an actual update for you guys!

@Lee, hm, OK, I think I get it now. But wouldn't this mechanic mainly be about smoothing the leg movement? Smooth leg movement is not really my main concern here, rather the opposite - if the legs are too smooth the lizard will just look like it's floating with the legs tapping along under it. Some unevenness to the grabbing cycles is not really a bad thing. Rather my main concern is to make the steps as long as possible, and considering that, wouldn't a steering system like this only allow for the steps to be shorter? Like, to get the longest possible steps I should only let go when the leg is positively too far behind, giving up a grip any earlier than that would just make the step shorter, right?

[jamesprimate]

yay! jac's back! ...in a starbucks 

[Lee]

Rather my main concern is to make the steps as long as possible, and considering that, wouldn't a steering system like this only allow for the steps to be shorter? Like, to get the longest possible steps I should only let go when the leg is positively too far behind, giving up a grip any earlier than that would just make the step shorter, right?

Well if you just chose a grab target for the leg at the beginning of the movement then it's easy to see how that would be the case, but if you keep updating to the furthest possible reach or try to predict where it will be and adjust for that then I don't really see why it should be an issue... That said it's all well and good talking about the concept but the implementation is everything.

[JLJac]

"keep updating" seemed to be the key, actually

Update 301
Ok, so I think I found a solution on the leg AI problem, and it was rather obvious and sitting there all the time. The solution was to keep looking for a grab spot every frame when the leg is lifted. That way it will start moving towards some place rather close to itself, and thus too far back, but as it approach it other more progressed spots will become accessible, until it's stretched all the way forward and can evaluate grab spots that are in front of the lizard. When it finally reaches a grab spot, it goes into grab mode and just relaxes until it's too far behind again. I don't quite know why every iteration of this solution I came up with had just one or a few checks for grab spots, when continuous reevaluation seemed to be the trick.

In other news I've colored the paws of the lizards, and made the leg size change according to breed:



I don't know if you can notice, but the pair of legs that are further away from the camera are slightly darker, I hope that this slight color difference will make it appear a little less like a flurry of color and make it possible to at least get glimpses of the leg movement.

The mystery of the slugcat's disappearing arms has also come to a conclusion. At one time or another when doing the lizards I told all limbs to go into retract mode when the creature enters a short cut, so that was what happened to the slugcat as well, only that the slugcat didn't have any way of un-retracting them.

[Rojom]

I noticed when climbing against the wall, two of the legs are still shaded, despite both being on the same "plane". Is that intentional?

[DarkWanderer]

I hate to be a naysayer but I'm personally not digging those gradients in the lizard tails. The lizards used to have a cel shaded look to them, but now there's a sort of roundness to them that appears to be a sort of faux-3D. Compared to the rest of the world, it looks a little out of place. Maybe it'll grow on me, but it is a stark contrast to the rest of RW's aesthetics.

[jamesprimate]

I hate to be a naysayer but I'm personally not digging those gradients in the lizard tails. The lizards used to have a cel shaded look to them, but now there's a sort of roundness to them that appears to be a sort of faux-3D. Compared to the rest of the world, it looks a little out of place. Maybe it'll grow on me, but it is a stark contrast to the rest of RW's aesthetics.

idk if you recall how the level art is made, but "faux 3D" describes it almost perfectly, so hopefully this actually moves to tie everything together! but I suppose we'll find out. we're still missing a few subtle components so it feels a bit "off", but i think once Joar gets the lizard head blinking / color shifting weirdness happening, it's all going to fit right in 

[Nico May]

honestly I agree, its not that its faux 3d, its that it seems to break the awesome pixel look, its just a bit too smooth...But hey everything you've done so far is awesome so I'm sure whatever you end up with will be gorgeous:D

[JLJac]

I noticed when climbing against the wall, two of the legs are still shaded, despite both being on the same "plane". Is that intentional?

Nope, thanks for the heads up. Know what it is, getting at it.

On tail gradients, James and I have actually had a brief discussion ourselves on that - I tend to agree with you in that it looks a bit too... Idk, computer-y. A bit too perfect, perhaps. James is fond of it, and I can totally see its potential though, so maybe with a bit of tweaking! I don't know if you've noticed, but the art restrictions I'm keeping to is single color flat surfaces but with occasional gradients in the surfaces - never between two "mundane" colors (black, brown, whatever the level geometry is), but between a "mundane" color and an "effect" color (neon colors such as pink). So the gradient is technically within the restrictions, as are the colored feet. But I see your point - it does look a little bit different from the gradient in for example the plants, which is created with a mask. Let's see where it ends up! Right now I'm just constructing all the pieces, there'll be plenty of re-adjusting and tuning later.