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!

Plans plans plans

Good morning. It's Monday again and there weekend where I planned to make some progress in my game is over. What happened?

Well, Unity's been asking me to install their newest update for a couple of days, so before breakfast on Saturday, I decided to do so. I found out there is a thing in this version that I could use, so let's go for it. When I returned, there was an error message because Unity was not able to remove something. I didn't think much of it, so I just ran Unity and found out it could not start. I rebooted, same problem. 

After a bit of googling and asking around on Twitter, I found that Unity needed to be reinstalled in another folder, so I did and that worked well. That was similar lunch time.  I hooked up the scripts that I had and loaded the models that I made. Then I went for a sandwich. 

By the end of the afternoon (!) I finally got everything to work. My procedural generation requires a lot of parameters to be set in the inspector and I apparently forgot one of them that made the entire world have a "very wet" moisture rate which gave me a rainforesty world with no desserts, tundra, savanna and the like. It took so much time to find out what caused this and fix that. 

Later, I also found out I forgot to set the ground to a certain layer so that trees could find a good place to set their y-coordinate and not float over or sink into the ground.  Anyway, that was done by the end if the day. I did not feel like working on the game so I called it a day. 

Sunday, I decided to work on another tree model because I did not have a tree for the savanna region yet. Now that I found a nice trick  in Blender to make trees more easily, it did not take too long to make a nice Acacia tree. 

I'm pretty pleased with how much these tree models improve over a short period of time. I know that I'll make some more and remake some of my earlier ones and I'm happy that that should not be much of a problem. 

I also continued with the humanoid model that I've been working on lately.  I tried to rig and animate it in Mixamo but I couldn't get it to work correctly, so I decided to rig it manually in Blender. When I went to bed, this is what I had. 

It's getting near a complete rig and then I will have to add weights to different places to make sure the guy does not move weirdly in the check or the neck when lifting the arm. Last, I'll make four animations: an idle one, a walking one, one for picking up objects and one for dropping objects. Maybe I'll also make a working one at this point. Maybe later. 

Anyway, I had a lot of plans for the weekend, but most of it got into recovering what I already had, which is annoying. Yesterday evening I found out I could open my old project too all of a sudden. I could now take some of the procedural level generation parameters if I need to, do I'll not delete it yet. I also set up a source control for my project. 

Note I'm off to work. Hopefully I can get the rigging of my humanoid finished tonight. Then I can get to work getting the guys to life. 

Procedurally generated frustration

Good morning everyone. I'm in the bus to work again. This weekend was pretty rich in game development. I managed to spend quite some time on the procedural terrain generation course that has had my attention for quite a while now. I learned a lot about Perlin noise and midpoint displacement algorithms and about how top make editor scripts in Unity.

Because I don't want the game to be too complex, I'm not implementing erosion for now. For that reason, I decided to just put all the scripts on my game project and get them to work before removing unneeded stuff and tinkering with the other stuff. It seems to work for a part.

This island is procedurally generated by using a midpoint displacement to generate the heights, a water plain at a certain height level and a couple of textures like grass and rock, which seem to blend too much right now. The white line is an animated shore line and the green stuff at the bottom... those are the trees.

Somehow the trees behave differently than they did in the course, so I must have done something wrong. At 11pm yesterday I decided to delete all the procedural code from my game project (only there) and start  from scratch. I am a lot more at ease with scripts with many methods than with scripts with a few large methods, so I'll have an Awake() with just about ten lines and keep it the way I like and the course teacher does not seem to.

My point is... sometimes you spend a lot of time on something without anything to show for it. Whatever I did, at least I learned from it.  I do now get that annoying feeling that I want to start working on the actual game mechanics instead of vital but secondary stuff like the terrain. I hope I'll ferry this thing working this week, because this way it does not feel like a game.

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...

Trying a different way

So the magic phrase is "procedural level generation". I opened a whole can of worms when I told myself that Holocene needed a ground that would be different from a flat plane. It got me into a whole range of tutorials for making something that looked exactly like I needed, but really wasn't.

I learned to work with Perlin noise maps  and how to use those to get a 2D configuration that looks random enough for my purpose. That's nice and it's also nice to use plane objects of home made meshes to get the level rolling,  but probably not in Holocene,  because I could not get the navmesh working. And by now you should know that this is a no-go.

The problem is that, no matter how hard I try, navmeshes end up below the surface of the level and not on top. That means that the characters would not be able to walk over the surface of the world in the way that I planned. I couldn't get it to work.

Yesterday I found another tutorial on putting what I learned to practise on an actual terrain mesh and that works if I use the special navmesh scripts that I found on the Unity github. The scripts allowed for baking the stuff at runtime which seems to work. All I need to do now is bake the mesh after generation.

I have a working navmesh now and I can now add the features to it. I am still not completely satisfied with the way the terrain looks. I think I need to tweak the noise script to allow for more flat regions, but for now it works. Next is to turn this into a game.

Action for actions?

Mondays,  who doesn't like 'em? The inevitability of it is quite something. I, for one, like weekends and it always gets under my skin when the weekend is over.  I usually need five days to recover and get back to normal. Mondays are the worst!

All joking aside,  this weekend has been quite productive for Holocene.  I did what I set out to do. The selection panel seems to work well. I have not yet been able to test the thing when I select at least 11 different types of units, but that's because I only have two yet. And besides,  with no box selection implemented,  who in their right mind would select that many units anyway?

With the selection panel working,  next up is showing the actions for an object. For that, I created an actions class and a display class for it. Actions are going to grow, but for now, it has a name a type (science,  recruit or special) and a prefab.  I'll first create the recruitment.  It'll just instantiate the prefab at a specific location and move it to a rally point. Should not be too difficult.

What I do think might be difficult, is how to work with these actions. The way Unity works is that to have an instance of any class be available,  one needs to make an object or a prefab of an object. I sense there might be performance issues here.

For instance,  the action "recruit a warrior" will be linked to three kinds of buildings,  meaning that warriors can be spawned by three types of buildings.  Any world object has an array of possible actions and each of these buildings will need the "recruit a warrior" one, so I'll make a game object, add the action script to it, fill out the variables and link it to the buildings.

In no time,  I'll have many objects not doing anything but just being there. To me, that seems like a waste of resources.  Is this really a problem? Are there other ways?

Dropping and the big drop

It took me some frustration and two days not working on the game, but it's working, the dropping of objects from the inventory. It was actually quite easy, but it was not something I expected to happen. You know, destroying children (which is only admissible in a software development context), it has some peculiarities if I understand it right and I needed to learn something new in Unity to find that out: The debug mode in Unity. I looked at this video and it helpen me on my way. Just wanted to share this one and others from Unity3DCollege which you should check out.

What seems to have happened if I understand it well, is that stuff happens in another order than I expected. I destroy and object and then check the state of things. Well, that was too soon, probably, because after the Destroy-command, the object sticks around for a while. Took me some time to find that out.

Now the sollution was not difficult in this case, because instead of object 0, which was the one supposed to be destroyed, object 1 was the one I needed. In the end all I did was change a digit.

And then I dropped the objects and tried to save one of them... In vain.



By the way, I think I'm going to use my YouTube channel more now. Gifs are all nice for a couple of seconds, but a longer video is better to show bigger pieces of the game's workings. For anyone interested, you can follow me here.

Do I have this or not?

Alright, before my wife gets to go on the computer, a little update. Yesterday and today, I made some progress in the Inventory GUI. I put quite some thought (and YouTube tutorials) in it but it took me a day to be where I were in the earlier iteration of my game. Now that I am there, let's build.

Like with the dialog/quest boxes, I learned it is easier to keep GUI and mechanics separate, but now that I'm working on the inventory, I see the disadvantages too. Just have a look.



The inventory screen (which needs some visual changes of course), it contains two major parts: the list on the left and the details part on the right. The list part simply lists the inventory, which contains all the objects that the player picks up, or nothing. The part on the right is going to be more flexible, but what it should have now is either nothing(if there are no objects in the inventory), or the top object in the list (if there are). The buttons in the bottom are going to be Use and Drop (or equivalent, like Equip, Eat etc. That's why they don't have text yet).

It seems the display objects have a hard time communicating with the objects themselves. There's dropping mechanics in the actual objects that place the object in front of the camera and remove them from the inventory, but then... Somehow the game does not yet understand which object to work with and when to update the view.

It'll all be fine, but this is not ready by far. I'm probably making a thinking mistake, but you know how it is with thinking mistakes? You're thinking wrong, so they're especially hard to spot. I'll be back working later. Hopefully with a fresh look and it I'm lucky, I immediately see where I botched it. Wouldn't be the first time and certainly not the last either.

Objects and children

So, yesterday I added a lot of AI behaviour for the Unfriendly Guy, the guy in the red capsule and it went quite ok. I had some code from my old iteration of the game that had a finite state machine in it and I copied it to the new one, with some additions and changes. When I tested the patrolling behaviour, this happened:

When I could not immediately spot it, I decided to call it a day and have a look later, because it was already quite late and I was tired, but I found it oddly regular what Unfriendly Guy was doing, so no worries. I can fix this easily with a fresh look.

So I turned on my computer this morning and this is what I saw:

Here is the problem. The fact that all was so regular and nice was because the script was working just fine. The NavMeshAgent (the green cylinder) was doing exactly as planned and walking from waypoint to waypoint, avoiding the walls. All I needed to do was make sure the guy was at the same position and rotation. The body was at a different place than it was supposed to be. So I put the Z and Z axis of the body to zero and moved the cylinder to the place where the body was standing, taking the body with me. Now it works.

So, note to self and my first tutorial-a-like thing: when you move objects, make sure you move the right object if they are connected and you want them to be at the same transform.

Scene Management Trouble

Another technical post today, because I'm having problems again. Yesterday evening, I started trying to get the rotation right when getting through a door to another scene.I have this GameHandler singleton that controls some things that should not be lost when changing scenes. In this case, it's a door number and a rotation .

When changing scenes, the plan is that the GameHandler gives information to the player-scripts to put him on the right position (which often works) and rotation (which does not seem to work).

In short: I have two problems. 

1. First I can't figure out why sometimes the scene puts the player on the 0,0,0-position when loading and how to fix that.
2. Second, somehow I can't get the rotation of the player to work to look at the door orientation point or to keep the rotation that he had in the previous scene.

Here's my project on GitHub: https://github.com/Xrocetoxtos/RPG2

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?

Fixing the view

Somehow, in the last weeks, I found out that my player character suddenly looked somewhere else entirely. It did not happen when I were running around in the field with all the room in the world, but it did happen when there was more subtlty needed, like in the maze. Since I was trying to get the quest system to work, I hid a sword in the maze and went looking for it. That was nearly impossible. Imagine walking around a small hallway where all the walls and the ceiling have the same colour and suddenly you stand the other way around. I had to fix that, but that'd be a pain for years to come.

I refuse to use the Standard Assets first player controller because I don't really understand what is happening there and I want to be able to add features later. I need to understand what is really happening, so that I can do that correctly and efficiently. That's why I watched the First Person Controller tutorial by Acacia on Youtube in the beginning to get a good grip and be able to add things later.

I learned a lot, especially about controlling speed and the overall concept that we have two objects to control: the camera and the player himself. This tutorial is really helpful, also fixing a problem for when the ground is sloping downwards, teaching me about raycasts and physics laws that this historian does not even dream about. But somehow it was not working like I wanted it to, so I looked for another tutorial to guide me.

This one was by Holistic3d, a very welcome female voice in this male world of tutorials and a nice and well-explained one. Not sure what made the difference, but it fixes my problems. Now I only had to make sure that I could not look over my head and see the world behind me upside-down. That was easily done by clamping the rotation of the camera. Nice. Now I can carry on with the quests and fix the fact that somehow the inventory does not show up anymore. Enough to do.

Anyway, I also got a github thing to work. Appeared easier than expected. Makes me wanna take a little more risks, because I can always turn back, which is nice for the creativity. 

All in all, a lot of work done and a lot of work to be done in this game.

A collision problem with monsters and walls

Alright, I knew the monster would come back to bite me and it's giving me problems. I had a factory script build me a small 10x10 level which looks like this:

The stick figure in the left bottom corner, that's me. There's a couple of walls, a door, a health box and two monsters. I already made a script allowing the stick figure to walk through the level using keys, avoiding the walls and the door.

Now I added a script (bottom of this post) to the Monster class that makes it walk in a random direction (up, down, left or right) until it hits a collider. Then it decides another random direction (never the one it was already going) and moves on. I have this script. Note that Monster inherits from Enemy. All Enemy does is make sure a variable level contains an animation from the factory class. That happens in the base Awake.

This code results in the two monsters moving which is correct. The monster in the middle-right of the screen will go up and down and the one at the top will start moving places until it gets stuck in a corner like this:

As you see in the code, I added a Debug.Log to find out what is happening and it appears that the monster not only collides with the wall to its left and top, but also the one to the top-left.  I suspect that the monster had its direction until it hit one of those walls, backs off in the OnCollisionEnter2D function and decides to hit the other two walls.

My question is if there's a way to get this thing to work: when the moveDir is decided, can the script predict immediate collisions without triggering them? I have this thing in the DecideMoveDir-method where I make sure the randomNumber is never the same as previousNumber so that the monster does not re-bump into the wall and get stuck. Can I broaden this while loop (or other thing) to make sure the resulting moveDir does not cause problems?

Or, maybe I'm just thinking wrong, does this phenomenon have another cause? Is that fixable? All I want to have here is the monsters walking in a random direction and chancing course randomly when they hit a wall, a door or each other. When they hit the player, something else will have to happen, but that's gonna be ugly.

Here's the entire Monster class script:

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class Monster : Enemy
{
    private Sprite[] currentAnimation;
    private int currentFrame = 0;
    private float frameRate = .2f;
    private float timer;
    private SpriteRenderer spriteRenderer;

    public Sprite[] monsterIdleAnimation;
    private Vector3 moveDir;
    private float speed = 2f;
    private float speedTimer;
    private int previousNumber;
    

    protected override void Awake()
    {
        base.Awake();
        monsterIdleAnimation = level.monsterIdleAnimation;
        HealthSystem healthSystem = new HealthSystem(50);

        currentAnimation = monsterIdleAnimation;
        spriteRenderer = gameObject.GetComponent<SpriteRenderer>();

        moveDir = DecideMoveDir();
    }

    void Update()
    {
        MoveMonster(moveDir);
        DecideMonsterAnimation();
        AnimateMonster();
    }

    private void OnCollisionEnter2D(Collision2D collision)
    {
        Debug.Log(gameObject.name + " / " + collision.gameObject.name + " nr:" + previousNumber);
        transform.position -= moveDir;

        moveDir = DecideMoveDir();
    }

    private int RandomNumberGenerator(int a, int b)
    {
        int getal = Random.Range(a, b);
        return getal;
    }

    private Vector3 DecideMoveDir()
    {
        Vector3 direction = new Vector3();

        //nooit twee keer dezelfde richting bepalen.
        int randomNumber = RandomNumberGenerator(1, 4);
        while (randomNumber == previousNumber)
        {
            randomNumber = RandomNumberGenerator(1, 4);
        }
        previousNumber = randomNumber;

        switch (randomNumber)
        {
            case 1:
                direction = Vector3.up;
                break;
            case 2:
                direction = Vector3.down;
                break;
            case 3:
                direction = Vector3.left;
                break;
            case 4:
                direction = Vector3.right;
                break;
            default:
                direction = Vector3.zero;
                break;
        }

        direction *= speed * Time.deltaTime;
        return direction;
    }

    public void MoveMonster(Vector3 direction)
    {
        transform.position += moveDir;
    }

    private void DecideMonsterAnimation()
    {
         //does nothing yet.
    }

    private void AnimateMonster()
    {
        timer += Time.deltaTime;
        if (timer >= frameRate)
        {
            timer -= frameRate;
            currentFrame = (currentFrame + 1) % currentAnimation.Length;
            spriteRenderer.sprite = currentAnimation[currentFrame];
        }
    }
}