@Loren Schmidt, yeah, that sounds a lot like what I've been trying to do, but I might have to throw a few more counters in there to get a good rhythm to it o.0 Are you doing procedural animation too?
@Kytin, interesting idea! Maybe we could keep physical traits and "personality" separate, and only have the latter be individual...
Update 294I made a couple of pretty big infra structure changes, such as moving all of the lizard breed definition stuff to the same place. Now there's a static class which is fed a lizard color and returns the complete template, all of it based on one huge enum switch. Maybe not the most elegant solution, but it works flawlessly and is only supposed to run once when the game is started up.
Also got the thing where lizards have different speeds in different terrain and when moving in different directions down. At this point it averages between the terrain type that each of the three body chunks occupy.
Oh, and sometimes you just have to do something that doesn't make any sense to the schedule, but you want to do just for fun! So I made the lizards' limbs have health, and go limp and useless if they're too low.

This is going to be really cool later, when spears and stuff is in... Note how one of the front legs is sometimes working, sometimes not - when they have low health, but not 0, they're switched on and off a bit like that.
The other thing I got started on today was an obstacle tracker. Because of the physics based nature of RW, not everything is very predictable, and even after me trying to eliminate all the getting stuck scenarios, there will be some obscure getting stuck scenarios left. The obstacle tracker isn't only there to patch over problems I'm too lazy to fix, though

It plays a part in making the NPC's seem more intelligent over all, and makes them able to account for some weird unpredictable scenarios that might occur in any game session. What it basically boils down to is being able to identify that a certain move is not possible after a number of failed attempts, and trying something else.
This (rather tragic) gif shows a lizard that tries to climb up to the player, but is rather unsuccessful due to its limbs being disabled. The gif is sped up, because without functioning limbs the lizard is really slow.

Whenever a move fails, the destination tile is reported (red in the gif). After being reported a certain amount of times, the tile is marked as an obstacle (yellow) and the path finder is told to restart. This time around the yellow tiles will have a higher cost assigned to them.
This means that after trying to climb a couple of times, the lizard concludes that "OK, this isn't working" and decides to take another way up. This system works no matter what the obstacle is - if it's lame limbs, a stream of water, some heavy creature grabbing on to the lizards tail, anything.
This multiusability is both its strength and its problem - the lizard still isn't very smart about cause and effect. A smart lizard would deduce that
climbing was the problem, not these specific tiles. With this system it might very well go to another climbing pole and try that before realizing that it has to get up some other way.
The point is, however, that this is a fallback. If I want to make the lizard able to understand that it can't climb without functioning limbs, that's something I'd write specifically in the AI ( if (functioningLimbs < 4) noClimb = true; ) but for all the scenarios I won't be able to predict, this fallback solution is a lot better than infinitely trying to get past some impossible hurdle.
Before it's done I want the obstacle tracker to have one more function - it should be able to identify when the obstacle is in fact a creature blocking its way. When a huge green lizard is sitting in an opening and a tiny blue one is pushing and pushing in vain to get through, it seems kind of unreasonable for it to assume that "it must be something wrong with this specific tile!" Also, once the green lizard is gone, the blue one should really stop avoiding that tile. So I think a specific framework for being blocked by colliding in other objects might be in place.