next »

[JLJac]

Update 302
Did some misc animation work, including the infamous blinking head! I cleaned up some of the limb movement further, made sure that green's shoulders didn't stick out through its back, hunted some bug in the obstacle tracker, etc. One new animation available to the lizard now is "wiggle", where the body wiggles back and forth. It'll do this when it's stuck somewhere, and also when it has no limbs at all to move with, in which case the wiggle animation makes it slide along the floor in an inch-worm like movement.

The big achievement of the day was setting up Visual Studio with Unity and UnityVS. After some tears and pulled hair James and I got it to work, and now I've been debugging the Unity project from VS, so it's all up and running!

In James related news the last batch of songs/music experiments he sent me contained one track that was super cool - we felt that it represented an entire style that we'd like to explore further. Maybe when he has dug a little deeper in that direction we he'll want to share some of it. It's really something else!

I've been looking at my poor little lizards, and noticed that they have some locomotion problems. In particular the green one. After the limb work of last week I feel happy enough with how the movement looks, especially if I compare with the lingo version I realize that they do feel like they have a more physical presence this time around. The problem is not in the aesthetics, but rather in the actual physics of movement. They fail at some moves they should succeed at, they get stuck way too much, sometimes they're strangely unable to move in narrow corridors. I probably need to take a long boring day to just clean this stuff up, identifying the problems one by one and doing something about them. I want my standard lizard to navigate its environment competently, any incompetence should be added by hand in a controlled manner. Let's just hope that the problems are in the movement physics, and don't have roots in the path finder 0________0

[Nico May]

just my thoughts on the tails: why not try a shader that just clamps the gradient by threshold (that makes sense right) so you maintain a gradient over the curve of the tail, but it keeps the chunky look.

[pnch]

Catching up with this ever-growing devlog is hard! Congrats on that!

Was going to mention the tail´s gradients looking off to me, when I found there were already comments on that.
On the other hand, the gradients on the paws looks great to me, maybe if you just shorten the tail gradient´s span / make it exponential? I can sure see them being fully neon for a couple more pixels at the tip, and then getting to the base color on a more abrupt way, that would be also more consistent with the paws. (Or of course, keep them as you are, since it´s both your game AND awesome.)

[JLJac]

Update 303
Cleaning up in the lizard movement wasn't as bad as I expected it to be. I'm perhaps not done, but I got some of the worst issues out of the way, and now all (as so far 3) breeds of lizards move with more ease through the environments.

On popular demand I gave the tail gradients some attention.

just my thoughts on the tails: why not try a shader that just clamps the gradient by threshold (that makes sense right) so you maintain a gradient over the curve of the tail, but it keeps the chunky look.

This I don't get exactly what you mean by? A shader that makes the gradient "banded" with fewer colors? Or a shader that draws the gradient as a circular gradient using the shape of the tail as a mask?

Catching up with this ever-growing devlog is hard! Congrats on that!

Was going to mention the tail´s gradients looking off to me, when I found there were already comments on that.
On the other hand, the gradients on the paws looks great to me, maybe if you just shorten the tail gradient´s span / make it exponential? I can sure see them being fully neon for a couple more pixels at the tip, and then getting to the base color on a more abrupt way, that would be also more consistent with the paws. (Or of course, keep them as you are, since it´s both your game AND awesome.)

Haha I can imagine! Hope it was fun or informative  It already is exponential in the old gifs actually, ^3 or ^4 I think.  Shortening the span though was a good idea, tried it out and it did look better! The paws are painted with the photoshop brush, which I believe is a gauss curve. Maybe I should calculate one of those... Seems overkill though!

In the end I restricted the gradient to not cover the entire tail (a little different how much it covers depending on breed), kept it exponential, and also added just a little bit of random noise to the gradient, especially towards the intermediary colors, hoping to approach the slightly grittier look of the photoshop brush painted paws.



And blinking heads! The frequency depends on an excitement parameter in the AI, so you'll be able to see if they're idle or up to something by how fast they're pulsing. Instead of just a sine pulse, this time it's a sine where 0<y<1 but raised to an exponent, making it so that it does drop to 0, but it's at high values more than it's at low ones. This exponent also gets bigger with excitement, meaning that when they're very calm/almost sleeping the head is dark about as much as it's bright, but if they're very excited the head is mostly lit with just quick pulses of black color. I'll do a comparison some time when there's more AI to work with. Right now they're locked at 50% excitement. Basically I figured that it's more fun to look at color than something dark, and this way I could make them more colorful while keeping the iconic blinking.

Oh, and the other effort of the day was making lizards able to handle slopes - the one part of them that had been shamefully neglected. When I was at it I also made the "grab for terrain" method of the limb object understand slopes, so now the player will also grab at them correctly when crawling.

Last for today, I'm asking for some programming advice.

Path finding towards a target is relatively easy. Basically flood fill outwards from the goal, when the fill reaches the player, keep going "downhill" node by node until the goal is reached.

As I'm closing in on it, I've come to realize that "path finding" in order to flee is probably much, much harder. If you just turn your back at the thing you're fleeing from and leg it you will inevitably end up running in a corner, and you're an easy snack. If you path towards the closest room exit or something like that, that path might very well take you straight into the arms of your pursuer. And also, how do you know that you even want to go to the other room? If it's a dead end you're in a worse pinch when you get there and the pursuer comes after you. And all of this is still just considering one pursuer, if there are two of them and you for example only flee from the closest one, you might very well end up flickering between fleeing from one and the other, and end up eaten by both.

Are there any special tricks for fleeing AI behavior?

I did have a pretty solid algorithm for the flies in the old build, but it was very dependent on they being able to go somewhere you weren't (down in the ground), they weren't as much fleeing from you as to the best located refuge. Are there any solid algorithms out there? Do they all depend on managing ridiculously expensive "danger maps" where every tile's distance to every threat is mapped and need to be re-calculated pretty much every frame?

[gimymblert]

Well danger map is the common way of doing it and also marking "spot" (refuge) like you did.

Or just simply distance keeping.

In fact reverse danger map (flow map with Dijkstra) centered on the player is use for managing pathfinding of hundred of enemy character with perfect knowledge. You may not need to update every frame, just under a spatial windows, and may not need to search the entire map, just a distance.

The way I see it is to mark node that are dead end and branch, and have the agent move from branch to branch avoiding dead end.

I'm sure the best approach is a blend of all of that depending on the situations. It's a reverse of the occupancy map problem.

EDIT:
what I found on the net
http://gamedev.stackexchange.com/questions/43947/pathfinding-for-fleeing
http://gamedev.stackexchange.com/questions/16600/how-to-prevent-fleeing-monster-from-backing-himself-into-a-dead-end

[Nico May]

I meant making it banded, like how 8bit gradients look, but with possibly less restriction, but its looking good so I'll shut up:)

[jamesprimate]

ohhhhh, the "cornered state" suggestion from that second link sounds SO right to me:

One thing I've done in the past is add a cornered state to the enemy. Put yourself in the shoes of the fleeing enemy. It is scared, it is hurt, it is fleeing and trying to just get away! Perfect mindset to get yourself cornered, which can be really fun for the player.

Once cornered, the enemy can do different things, ideally depending on the personality of the enemy itself:

They can cower and duck into the corner and wait for death. Only really works if you can convey those emotions. A single-character rogue-like enemy probably can't convey that without text or something. From here, the player could decide to leave the enemy alone, showing compassion. Could be really neat if the enemy then becomes passive. Or if healed, even become an ally of the player.
They could go into a blind rage and launch a last-ditch attack against the player, or unleash some kind of escape spell or skill; such as a squid squirting ink, or a lizard playing dead.
These are really more interesting than avoiding the corner in the first place. And are probably faster to compute, which will let you spend those cycles elsewhere.

https://gamedev.stackexchange.com/questions/16600/how-to-prevent-fleeing-monster-from-backing-himself-into-a-dead-end

[JLJac]

@Gimym JIMBERT, Thanks for links! Yeah, a mix of those solutions is basically what I've been thinking about as well. Just wanted to make sure that there wasn't a super obvious go-to solution I was missing here!

Update 304
Today was spent in thinking mode.



I've been able to outline a few methods for keeping distance from threats - I think I could make something work that would be an approximation of an occupancy map setup. Creatures can't share these, as they all have different ideas of where all the other creatures are, so they'd have to be rather optimized as many creature might be updating them often. My idea is some sort of heuristic version that for the most part just uses 2D distance (getting away to the other end of the map is rarely a bad idea) but very close to the creature can overlay this with a small dijkstra map for some smarter behavior when it comes to walls.

The main issue though is the question of how to avoid dead ends and corners. I think this is going to be the main factor in whether or not the behavior will look decently intelligent - running straight into the closest corner is going to look dumb. After some contemplation I came up with this: What is a dead end? It is not a loop. A loop in this case being a group of allowed tiles that encircles a group of unallowed tiles.



A real scenario might not be as black and white as this, for example I don't think most people would consider a big open room a "dead end". But let's not give any benefits of doubt here - for simplicity, let's write off everything not a loop as a dead end. The purpose will still be served - if you can get to one of these loops, you will at least have the benefit of being able to run away for ever rather than ending up with nowhere to go.

Especially places where many loops intersect would be attractive in a fleeing scenario. Imagine the center point in the character "8". That's two loops intersecting - if you're a paranoid creature fleeing from foes and you're in an 8-shaped room, you'd probably default to that center point where you have the most options for escape to pick from, right?

So, how do I find loops? The first thing I though was that I'd identify every continuous blob of unallowed tiles using connected component labeling.

When I'd found every such shape, I'd let all of them grow at an even pace into the allowed tiles, until they hit each other. Those edges would be the loops.




I was really enthusiastic about this approach for a while, but then I realized that my path finding map isn't that simple. For example I have connections that are valid one way but not the other, and connections that takes the creature across unallowed tiles, messing up the blob integrity completely. These shapes of unallowed tiles probably could be defined still, but they'd be multi-dimensional objects that I wouldn't have a chance against.



So what I'm thinking about now is a slightly different approach. I'll map the allowed areas instead, using a dijkstra's algorithm-like method (essentially a flood fill where you keep track of where each tile was filled from).

When filling the tiles, if I encounter a tile that's already filled, I do a common ancestor check. As all the tiles are filled from one original tile, and the dijkstra method keeps track of the "parent" of each new filled tile, you essentially have an ancestry tree. If I'm in one branch of that tree, and collide with another branch, I can check how far back these branches have a common ancestor. If that's not long ago, they are basically siblings, part of the same "frontier" filling in an area. If their ancestor is far back though, that means that we have a loop!

By moving from the collision point to the common ancestor through both branches, the loop can be identified tile by tile.



What do you think? Is it going to fail for some obvious reason?

[kruxus]

Interesting, I'm also working on pathfinding and Dijkstra maps at the moment, but in a much simpler environment.

Wouldn't the common ancestor idea fail a bit if the "frontier" is very wide? The distance to the common ancestor might be quite long, but that doesn't mean there is a loop around an obstacle. Maybe it would still work, as a loop inside a big room is better for the fleeing creature than a narrow corridor at least.

Otherwise I guess you could add some checks to see if there is an obstacle inside the loop.

Also I think you should keep the quote from james above in mind. A creature that is fleeing would not always make rational decisions, it would be believable if a creature in panic runs into the corner rather than trying to run past the beast that blocks it's way. Of course it's better to have the "best" solution available though, and let some "panic" value of the creature decide if it's capable of making rational decisions. 

[Lee]

A loop is definitely a dead end when two creatures are chasing you. That's the problem with theory vs implementation, it can be extremely difficult to think about the same process happening simultaneously with multiple things, so you focus on the singular case.

[BartsBlue]

Hi Joar, one of the backers here. I have been following these updates with a lot of interest in lurker mode. Blinking heads, however, have made me come out of hiding and register just to say "no, please, don't". 

Seriously, this looks bad and takes away all the credibility these creatures might have. Instead of thinking animals I'm now thinking blinking robots. It made me recall second Oddworld game, called Exoddus, if I'm not mistaken. Instead of mudokons showing their emotions via sounds, mimic etc, they became color-coded in second part. The feeling that these are real creatures disappeared. I might be just a singular voice, but please, don't go this way.

Otherwise, great job and good luck in Korea.

[jamesprimate]

Hi Joar, one of the backers here. I have been following these updates with a lot of interest in lurker mode. Blinking heads, however, have made me come out of hiding and register just to say "no, please, don't". 

Seriously, this looks bad and takes away all the credibility these creatures might have. Instead of thinking animals I'm now thinking blinking robots.

whoa hey! thanks for the feedback! its legit awesome that you are passionate enough about the project to not only read the devblog, but actually SIGN UP FOR TIGSOURCE too. i appreciate it!

this isnt a change however, the lizards have pretty much always had blinking heads (as far back as 2 years ago!) and they are shown as such in all the kickstarter materials:





http://youtu.be/dVXfrSLeLNo?t=30s





http://youtu.be/XvMZNVCmd_o?t=44s

so too late to turn back now

it may look out of place a bit in the gif you are talking about, since they are being shown in debug mode without level backgrounds or environments or the behavioral AI that dictates the blinking, but we still have a ways to go with them yet. give us some time, they'll look as good as the lingo ones i promise. right now were just happy to have them running around the screen with their heads attached ;]

[Rebusmind]

I know you said it's not finished yet and will look better later on, but I'm also not a fan of the idea that the enemies have blinking heads. There must be a better way to show their mood or their states of alarm. And just because it has been in the game forever doesn't mean it couldn't be changed.

[Thomas Finch]

I don't know what you guys are talking about, I think the blinking heads look great.

[Lucs]

I really hope the lizards will look as they used to be in the Lingo version. Blinking heads are a great idea but look weird on the last gif Joar showed (maybe the transition between black and colored is too long). I don't like the new tail color neither but as it has been said, AI and behavior is the priority at the moment.

But I'll keep in mind James promised they'll look as good as the old ones.  

[BartsBlue]

@james

Wow, you're right! I've never noticed their heads were blinking. I guess the background really does make a change. I'll just shut up then and you keep making that game!  

[jamesprimate]

its all good! and seriously, thanks for your opinions. something is making it stick out for you guys to notice the difference, so we'll be sure to scrutinize it further now that you've brought it to our attention 

Joar is all wrapped up in fleeing AI, so this might be on the back burner for a bit, but I stared at these gifs for a while, and here are some thoughts:

* i think, sadly, everybody else is right and the tail gradients probably have to go. i got attached to them while they were just TAILS (no heads), but i have a suspicion that the visual contrast between them and the blinking head is probably one of the reasons its not sitting right with people. it just looks funky. (im sure we can use that trick on another creature to great effect though!)

* the new bodies really need to be lowered closer to the ground. they just lack that threatening sneakiness of the lingo. Seeing both pairs of legs for the walking animation also probably contributes to the visual color noise similar to above. And the droopy tail that results from the taller stance just doesnt feel "predator" at all.

* also reduce the size or amount of color on the feet to further eliminate the color noise. The originals benefited greatly from a less is more visual approach, and the small bits of color for feet allowed the viewer to sort of imagine more movement than was there. It seems contradictory, but even with the new well-defined feet and MUCH improved walking animation, the result winds up looking less natural, because the brain is silly like that.

* less stubby tails on the blues. the originals were lean and lanky which was threatening. its possible that might be solved just with the "lower the body" thing though.

OK! THUS SPAKE JAMES

[JLJac]

Haha wow! Good morning everyone!

@kruxus
I think (think) that if the frontier is wide, the tiles next to each other on it will still have close relationships. And yeah, of course I'll add animation fluff, but as a fellow programmer you understand that I want to actually solve the problem 

@Lee
Ugh you're right! But when chased by two enemies, a loop isn't worse than a dead end, right, just equally bad? Given that both the enemies don't decide to take the same route, in which case it's still preferable. And intersections between loops would still be a good idea to get to if you can do so while staying clear of threats?

On blinking heads! I think the black background makes it more visible - against the grey background the heads oscillate between two colors that have about an equal contrast against the background, one through hue and one through darkness. With the dark background the dark state of the head blends much more, which might make the blinking more in-your-face and appear more as blinking rather than a color change.

The robot analogy is actually not entirely out of place... The way I think of them is as Neon Lizards - they're definitely not robots, but they're not animals as we know them either. There's a slight biotechnological theme in the game, but not in the "cyborgs" sense - rather a smooth blend between one and the other, a seamless transition between skin and plastic. You're supposed to not really understand what you're looking at. Most of all though, this world is viewed through a cartoon "filter", and then a pixel "filter". When looking at a cartoon you rely on having seen most of the objects on screen in real life. They look nothing like reality, but you can deduce what they're supposed to symbolize. What I'm trying to accomplish here is a cartoon rendering of something that you've never seen before. In a situation like that you have to backwards engineer a reality from the meager clues that the cartoon gives you. Is this chameleon skin or light emitting diodes? The image is too simplified to know, so everyone has to make their own interpretation. That's what interesting to me about this visual style - things are just hinted with barely enough fidelity to try to piece together an understanding of what you're looking at.

So give me the benefit of the doubt! You could interpret what you see as "Boring robot" or "Game NPC cheaply announcing its AI state", but you could also project whatever trippy cool shit you want on those images, and I'm hoping you'll go with the latter

James animation notes:
Noted! All of these seem super valid. The new body elevation makes them appear more dog-like rather than lizard-like, so that definitely has to be tuned down. Looking at the old gifs I realize that the old lizards were much more of just a colored head and a black body "sticking out of it", the new ones have become more animal-shaped. New ones are better in a few ways, but the old ones had a point that has gone missing. I'll take a good long look and try to incorporate the best of both.

[Fermenter]

oh man, the snakey animations of these guys looks so rad and fun. keep up the good work!

[DarkWanderer]

So their heads don't blink when their in a passive or idle state? If it's used to denote alertness, health levels, anger, & so on, I don't think I have an issue with it. I didn't recall lizards having blinking heads in the old version til James pointed out, but I do think I remember seeing intervals where their heads weren't blinking, too, so if it isn't a complete clash with the established aesthetics I can't complain much. I still prefer the look of the old lizards, however. Their movement was more rigid, making me associate RW's aesthetics with that of older games with hardware limitations. They look way too fluid now, but if it's an inevitable trend of this game's development I'll just have to be content with it. (I would like to get my hands on that alpha down the road, I did back this you know )