Selecting units

It's been quite busy lately and I have not been able to get a lot of work done after the gathering mechanics that I made this week. Because it's been four days ago, here's an update.

The thing I'm working on right now is the GUI for objects being selected. I already had some of it, but that was always intended to be replaced by the thing that I am making right now. It is supposed to be a lot more flexible and reusable.

Take a look at the screen like it is right now:

We're talking about the panel at the bottom of the screen. It shows images of the nine first selected units plus an indication that there are more. Nothing is interactive. It's just an array of sprites that shows up when the number of selected units is greater than 1.

Now what am I going to do? First, I'll have another panel showing the same kind of thing and I'll replace the current one as soon as the new one works. The new panel will have five different ways to show stuff. I'll have to find out how to get that to work technically,  but that'll be ok.

There is:

• One object is selected: the sprite for the object will be quite large and there will be information on the selected object. Clicking the image will deselect the object. On the right of the panel, there will be buttons for actions that the object might be able to perform,  like building. This will give full access to the object.
• Between 2 and 10 of the same object are selected. Like in the above example,  only green guys are selected, but just maximum 10. The panel will show small images like in the screenshot. To the right, there's a bit of info and possibly buttons for actions that would make sense to perform as a group. 
• More than 10 of the same type. The first 9 will be shown, plus an indication that there's more. Clicking the indication willshow a details screen with the complete selection.  The rest of the screen will be like the above way.
• More than one unit of 2 to 10 different types.  Those will be grouped by type. There's one sprite plus a number for how many of the units are selected. So if you select one worker and two warriors, you will get a worker symbol with '1' below it and a warrior symbol with '2'.
• When there are more than 10 different  types selected,  heaven forbid, the first nine will be shown, plus a more-button to a details screen.

It's all going to a lot of work and testing should be vital, because this looks like asking for bugs,  but when it's finished,  it should be nice.

Last thing, because the bus is almost at the destination, I'll start with just the viewing of the info and possibly selection. Actions will be implemented as we implement the actions themselves. 

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.

Unnecessary complexity

Well, today there's just some small stuff I worked on. First think was that I needed healthbars for all the units and buildings and some of the resources. For that, I took my HealthSystem script from my RPG that I got from a Code Monkey tutorial. No bad words about this tutorial and I would point anyone to that one for making a healthbar, but I think I'd better not use it this time. The reason is the complexity and the extra level of code I need to have it work.

You see, my other game is about one player fighting one enemy at the time (if at all). Besides, the guys involved have health, fatigue and oxigen to work with. Now, in Holocene, Every unit, every building and quite some resources have health. No fatigue, no oxigen. Just health. And health is two numbers: a current health and a maximum health. All I have to do now is work with these in the unit itself. It has a current health that should not go below zero (because then the guy is dead) and not above the maximum health (or why else should we call it "maximum"?). That's all.

It's funny to see that in my drive to set things up in modules, I end up with complexity in layer upon layer, while that's often totally unnecessary. I don't need a complete class of HealthSystem objects. All I need is a couple of floats to track if the guy is dead yet, a method for dealing damage and healing health and a reference to a sprite that gets bigger and smaller if something happens. Nothing more complex than that.

Now that the guys can die and be destroyed, I can go on with the AI that I started with the other day. First job is to find out what right-clicking means when a unit is selected. First, what are we clicking? Are we clicking the ground? Go there and go idle. Are we clicking a building? Is it ours? Go there and go idle. Is it a unit? Whoose is it? Is it a resource? Is it minable? Can this unit even gather resources? Is there any resource left there? That kind of questions are what are driving the game in the week to come, probable.

Giving tasks

So yesterday, I did some groundwork for the behaviour of units in Holocene. I decided to go with a Finite State Machine that keeps track of two things the unit is doing.  There is a state and there is a task.

The state keeps track of what the unit is doing, like moving, fighting and gathering resources. The task is about what the unit is trying to achieve. For instance we have this amazing cylinder tree to cut for wood.

By sending the unit to the object, the system understands it will be a gathering operation, because the object has a Resource component. The player will then get the task of gathering,  related to this specific object. 

Gathering will then mean the unit has to first go there, so the state will be set to moving. Then, when the unit has reached its destination (which will have different meanings depending on the type of movement) the state will go to gathering untill some threshold is reached. Next, the state will be moving, because the unit will need to drop off the resources at a certain place and then the circle starts over again. 

I'm sure there'll be some complications,  but I think that this FSM should be the basics for the units and their behaviours. I'll first focus on the player's units.  If I do this well, getting the enemy to work should be about getting the states and tasks to change, which will be complex in its own right. 

I do however intend to keep these AI parts separate.  There's the way a unit deals with a specific task. That's up to the unit. Giving tasks is the player's job. That's for later.

Release: The No-Art Platformer

Because I wanted to release a little game and have the feeling of a game jam, I made The No-Art Platformer. You are a white block moving across black platforms hoovering above water, picking up coins and fighting red guys. You can download it Here directly. Free! (Things being free usually work with dutch, though I know many of the people that visit this site are not dutch.

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.

Now what

Alright. I'm sitting in the bus right now. We had a nice bachelor's party for Bram, my brother-in-law-to-be. I hope he enjoyed it a lot and continues enjoying the evening while the main guy left.

As this is a gamedev blog, what have I done lately? I know I have been quiet, because it has been quiet as I have not been able to get too much work done because my rib hurt when I sit on my desk chair.  Yesterday was my first day of work again and I really needed to quit after 8 hours because of the pain.

In those half hours and hours and the weekend, I made progress in two games.  Firstly I have this platformern that I was working on. I kind of finished that.  To find out if it was any good, I asked my non-gamer wife to play it. I won't translate what she said,  but suffice it to say that she liked it better than Oxford Street...

My second piece of progress is in a game that I never actually started building but which was always on my mind.  When you can't use the computer physically, and you still want to make games,  you start thinking about it.  

I am a historian,  more than I am a game developer,  possibly.  What I really want to do is create something to relive antiquity.  I might one day turn teacher to primary school children and away their love for both programming and history. For now,  I will keep the programming to myself and keep my scope small.

I'm not going to change the world anytime soon,  but sharing what you love is most valuable if you ask me. That is why I'm making a real time strategy game about early civilisation.  I'm probably calling it Holocene if that doesn't cause problems.  Might be partly RPG as you are a king and need to be there physically to influence all of it, but possibly just an RTS first and additions or version II later.

Anyway the bus is fast approaching the destination and I am tired right now. I had this to share now, so I wish you all a fond good night!