Ghosts on the navmesh

Good morning. I'm on my way again. The last couple of days I have been working on my characters for Holocene. First, I was building models in Blender, which took a lot of time without being successful really. Especially weight painting is terrible, when you try to keep things low poly. Shoulders are terrible to get right. After some days of trying, I decided to halt the character modeling for a while and use my proven primitive shape model in Unity.

Now that I decided that, I set that up. I have my tiles with a navmesh surface component to them, so the agents know where they can go. When I drop my guy on though, it does not really catch it. I think that is because the navmesh is above the surface somehow, making it difficult to work with. By changing the agent's offset and applying that to the prefab, I get this unsatisfactory result when I send the agent to the player position.

Note that this is not a ghost game. Floating characters are not what I need. I went to bed frustrated yesterday because all I really want is to have the navmesh right on the surface and have the agents just attach. 

While I'm writing this blogpost,  someone on Twitter just suggested I create a navmesh myself and that is certainly a thought I'd entertained for a while. It'd instantly fix the surface thing, I just don't know how to get any decent path finding to work then. Possibly with waypoints al over the surface if that does not take too much resources.

The Twitter guy said he'd send me his scripts so I'll wait for that. I really hope it helps me set up a good system without Unity's navmesh system which is giving me trouble every step of the way. I'm really looking forward to creating the actual game mechanics, so I'm hope to get the necessary technicalities over with. If this all works out, I found myself a new hero!

A little big thing

So, good afternoon.  No development today,  or at least not until the evening.  I do have things to talk about though, as I have been busy working on the movement mechanics in Holocene and there are some problems.

When a unit is selected and the player right clicks somewhere,  the unit should go there and that works for parts on the terrain where nothing already is. When there is a unit, it works too and the game knows where to stop to prevent two units to fight for the position to stand on.

The problem is when the unit wants to move to a stationary object like a resource or a building. The navmesh understands that the unit cannot just go there, so we'll have to find a place where it can go. Unity has these methods to find out the edge of a collider and places on the navmesh, but they do not yet give me what I need.  When I send a unit to an object,  it just stands next to the object on one place, no matter which is closest.

I'm not sure how the game decides that specific spot, but it's not what I want.  That is because it does not decide which place is closest to the unit. I was hoping the methode for finding the edge of a collider would fix that, but they don't.  I'm confident I will find a way, but I have not yet.

This is one of those "little big points". You might expect it to be a small minor thing to find the point where to go, but after a couple of days,  you realise, maybe not so much...

Just GoThere(place)

Yesterday evening I found and fixed the bug that was haunting me for a couple of days  and it was one of those bugs I'll probably see return every now and then, because that's the kind of programmer I am. I overused a method that did more than I intended.

You see, units are supposed to be able to go places and for that, they have a navmesh agent that moves once a destination is set and the destination is not their current position. So far so good.  Can't have that fail (well, we can, but I won't bother you with that right now).

The other main part of the unit script is a  finite state machine AI system. In short, units have a state and a task. The state says what the unit is doing and the task what its objective is.  So when we want to cut a tree over there, clicking the tree will cause the unit to have Cut as task, the tree as target and Moving as state. The moving state will find out if the unit is near enough to the target to change the state to Fighting. Etc.

Now the problem with the bug was that the task was no longer to Cut. The unit went to the tree and that was it. It turned to the Idle state with Nothing on its mind. Actually, that was easy, because I made the mistake of messing with the Moving state. It had a simple statement to set the destination and I,  thinking that it would be smart,  replaced that by a GoThere method.

And that method set the destination,  so the guy did go to the tree. That was good. It also set the state to Moving, which is fine. But is ALSO set the task to Move. That was the problem.

The unit made its way to the tree and stopped near it. That was good. Then the Moving state wondered what to do next,  so it asked the script. The script said. If you're moving and the task is to move, then once you reach your destination, you're done and you can run SetIdle(), whatever that may mean. No cutting the tree.

Now, dear rubber duck, this is a clash of principles.  We have the DRY-principle (Don't Repeat Yourself) that will stop you from writing the same code multiple times. I try to live by this principle as much as possible.

Then there is this programming thing to keep things small. I wrongly assumed that the GoThere method would just set the destination even though I just added the messing up code for another aim. I wanted to make things consistent, but did not think about it enough. Because some things should be different from other things.

Lesson learned,  but by no means expecting not to make the mistake again.  I do think it should now be easier to detect.

Can't do, sir!

It's funny, learning a language or a framework while working on an all-in application of the thing. Today was one of those days with a big job and a good end, because I fixed it in a way that I understand myself. Luckily Unity has a very good documentation to work with if you understand what questions to ask. I think I might be getting better in that and in the end, that's a very powerful skill if you ask me (or is that a wrong question to ask?)

I already had the mechanism of moving to a certain place via Unitys in-built NavMeshAgent. I also have had a system to make resource numbers cross over from a resource object to a guy, so the guy is harvesting some resource. Next thing which took me the better part of a weekend (bless christian holidays for that and bless my wife for not forcing me to go furniture shopping like the rest of the dutch) was hooking these two behaviours in a meaningful way.

To be specific, when the player selects a worker and right-clicks a tree, the worker should go there, gather resources, find the nearest drop-off-location, go there, drop the stuff there in the stockpile and return to gathering. Sounds easy, but I found it is not. At least, it took time to find out what was wrong.

In the beginning, the worker looked like his arms were stuck in the tree after gathering. So I made sure that didn't happen. The guy kept his distance by making the NavMesh agent wider. That did not solve anything, because the guy did not move anyway, just sloooooooowwwwwwllllllllllyyyyy turn in the direction of the cube building to the left. After a lot of time, I found out what seemed to be wrong. I point the guy to move to a place that is an obstacle. Normally, units move around the building and that's how it should be. I was asking the guy to do something he couldn't. when I turn of Navigation static on the building, my guy started running, but that would mean anyone would be able to do that.

I had a couple of options. First, I could try and make the building accessible to just this guy. I was trying stuff with extra objects with area masks and certain stepping heights, but that did not only not work, it felt and still feels like a wood-rope solution (like we dutch say). It was too much a move to something strange to avoid the problem, not a solution.

The other thing I tried was find a spot just outside the building and move there. Unity seems to have a lot of ways to do that and I only got one to work. A building object always consists of at least two child objects. There's the healthbar on top and the graphic/collider thing below. I had a method to find the nearest building object with certain attributes and that object was input in a new method to find the nearest place just outside it. I found out which of the child objects was lowest and asked the Physics engine to find the nearest spot outside.

To that spot, I sent the guy, let him do his dropping magic, update the UI and return gathering. That works and I'm happy with that.

Typing and rubber ducking this, I found out that I could better tag an entrance child for the delivery object and take that one instead of finding out which is lowest. I'll do that tomorrow. For now I'm happy with the solution and going to sleep. Tomorrow, the office is there again.

Combating the NavMesh dance

Just a little thought from the bus to work. I'm writing this on my phone, so I dont have access to my game right now,  but I do have some of my tweets.

As I said the other day, I started my RTS game that I'll call Holocene. It'll be about setting up a civilisation.  Kind of Age of Empires, but with a twist, because I'm not planning much medieval stuff, just ancient, where my passion and expertise lies.

I had some time to build the beginnings of the screen over the weekend and, with placeholder graphics, it will be something like this:

There's a resources panel at the top to show how much you got. There's the main window with units and the like and there's a selected objects panel at the bottom of the screen. 

Selecting by clicking on an object works now. I found a tutorial to make the square things around the unit that is selected. For placeholder purposes,  I got the bottom panel to view the selected unit or units up to ten. In the above example, 11 are selected, so the 10th has a "more selected" sprite that will later be cluckable to view a detailed list of objects. 

Anyway, what I wanted to say,  when an object is selected, the player right clicks somewhere and the selected thing can move (is a unit) the unit will go there. Neat! But now...

Join the #navmeshdance!
#gamedev #madewithunity pic.twitter.com/fWiaIaoTUt

— Tommy van Son (@DeOudheid) June 2, 2019

When I select multiple units and click somewhere to send them there, most will never get there, because only one unit can be at that specific point. Because of this, my units will dance around one another trying to get closer and pushing each other out of the way.  Nothing productive is happening and that's not good.

Now I thought of two ways to fight that. I could keep track of the distance from the object to the point and see if it gets smaller in any meaningful way.  If it does not, either there's something wrong with the NavMesh pathfinding in Unity, or the guy just can't get closer for this reason.

This could be difficult because often the path is not a straight line and the agent will first get further from the target before getting closer. I should look for that.

The second thing is to save the configuration of the group of units and have them move in that configuration.  Units will then not move to one spot, but all go to a spot that is just for them.

I will need something like that anyway, for moving in formation later, so I might as well implement that right away,  but how to get the right configuration? In the above examples,  it could just be copied from the current position,  but it will not work when converging units to a central location from different sides. I'll have to find out a way to do that.

Thinking about this, I'll probably do the second thing, but it won't be easy,  I think. Does not matter. I dont mind a little puzzle.

Back to where I were

Alright, good stuff. I'm back to where I were when I started with the NavMesh, but now with NavMesh agents implemented for both the Maze Guy and the Forest Guy. They can both walk their patrol routes without dropping half way into the ground and getting stuck. Ánd, they can navigate the terrain when I put obstacles in their way. A copuple of days ago, they could too, but then they just pushed the walls over or kept humping into them with a small angle until they slide past. This looks better.

I needed to rebuild the stack of shapes (two capsules, a sphere and an enlongated cube) and tinker a bit with the height of the NavMesh Agent. This, and I had the Parent gameobject a physical one. While MazeGuy and ForestGuy were empty game objects with a bunch of children, the new ones (with a space in their name) are actually capsules that aren't rendered. 

I might tinker with the walking stuff again, especially the sideways rotation. I'm not yet sure how this simple object rotation works with movement by the NavMesh. It looks like to goes great, but maybe that might not work later, so I'll keep a careful watch over it.

Tomorrow I'll not be working. Maybe a little bit in the morning, but we're going to a wedding and we'll be back late at night. Sunday'll be my birthday, so we'll have visitors. After that, I'll see if I could make a paralel AI system with an Animator with a FSM (I think of it as the Flying Spaghetti Monster, but it's Finite State Machine here). If that works alright and is really better,  I'll replace what I have now.

Next I'll be building on it. What will the guy do when he sees you, does it make sense to freeze all activity when the guy is miles away? Do I find more interesting stuff in my book? Or do I have new toys to play with for my birthday? See you in a couple of days!

AI frustration

Today, I've been reading about AI and navigation in specific.  NavMeshes in Unity.

What I saw the last couple of days was that patrolling NPC's don't really care about obstacles. I had the Forest Guy walk between two waypoints and that went like a charm as long as it was all a straight line.  Now, being a Skyrim veteran, I know not even Lydia walks in straight lines all the time,  so let's see.

I'm supposed to either work everything out myself, or use these NavMeshes. I "bake" a NavMesh and have agents like Forest Guy navigate that.

And then, whatever I do, they drop waist down in the ground and get stuck.  Weird and frustrating , because I have no idea what causes that. Now I have very few time this weekend.  A friend's wedding and my birthday,  so  now I go to bed a sad man...

Anyone any ideas?