Goal Oriented Action Planning

Good morning everyone. It's been about a month, I've been quiet on the blog.  I got myself a new laptop to work on the game sy the times I'd usually write these posts in the bus. As I'll be going to a concert with my wife after work, I left the laptop at home and here I am!

What have I been up to for the last couple of weeks? It's all mainly been about goal oriented action planning (GOAP) AI for the characters in Holocene. This means that the world is a world of states and tasks, but not really in a state machine way. A character has a simple state machine attached, but all it can do is be idle, go somewhere, and perform an action.

Where to go and what to do is dependent on the goals weer formulate.  For instance, the character is hungry. This gives him a goal: eat. Quite simple. So he eats and he's happy. But what happens when the guy does not have food? Well, he needs to eat,  so how do we make that possible?

Any job a character can have consists of the action (removing the food from the inventory and unticking him being hungry) and an effect (he's not hungry), but also some preconditions  (he had food). The action will only run if the character actually had food. 

The thing with GOAP is that once the goal of eating its picked, the character will try to find a sequence of actions leading to having eaten. Via some A* pathfinding algorithm from a tutorial, which I do not yet fully understand,  the character will find a road from the current situation to one where the preconditions for eating are met. We're picking up the apple over there, and we're not attacking the enemy or making fire or building river dykes. Because those won't lead to eating.

The GOAP system makes for flexibility because all you do it formulate small building blocks for behaviour and a system to build sequences of tasks based on very simple nodes. The thing is always that stuff like this isn't as easy as it seems. For instance, right now I'm having trouble making the character understand when a building he's building is finished. I find it hard to debug this system and the fact I don't really understand the underlying pathfinding does not help, but I know what to study and I'll be ok in the end, because I expect it'll all be so much easier once I get it.

Agabouga likes apples

Good morning again. I have a little update on the development of what I started to call Holocene again. I'm focusing on the game mechanics and specifically the satisfying of needs by characters. As I might have said before, characters need food, water, sleep, warmth and probably something social.

These five are instances of a Need class. Needs have a current value, a maximum value and some priority stuff. A character will be able to find out which need needs to be fulfilled and find targets for that accordingly.

I have this system working now, but I'm going to refactor that, because I'm not very happy with it and I think we're making too many calculations which will be problematic when we're having more than a couple of characters.

Anyway, afters whatever happens, the character has a state machine component that gets fired to a new state when that gets triggered. The idea is that once the guy is hungry, he'll find a food source and sets that as target to go to. Then the state machine will trigger a state to pick up the source and then eat it. Or bring it somewhere.

What I have now is a system that presets the target for Agabouga to the apple and tells him to go there. The triggering of the move state is not implemented fully, but that will be. By the end we'll have characters being able to find out what they need and if that's available. The state machine will then get a sequence of states going. Move to the apple, pick it up, eat it and find out if we need anything else.

A lot of work left to do, but it's actual mechanics so I like it.

How to be destroyed properly

Good morning and best wishes for 2020. It's been a while but not so much that I'm getting used to typing 2020 on my computer keyboard with ease. I spent the holidays with the family and the rest of the time with my wife and a bit with some courses and experimenting to get better at gamedevving. Now I think I'm back to business.

I have been up to quite a lot in these courses and experimenting lately. The aim is mostly to get more proficient in the RTS mechanics that I need for my game. I'm going to revisit the procedural world generation later, once I have kind of a game going, so I ditched that, because I was not happy about it anyway.

I also took a look at 2D grids and A* navigation, but that gets slow very quickly once the world is getting any bigger. I think I'll just stick with the 3D Navmesh system for now. I'm not sure what other elements to keep.

Now that I started a new clean sheet project, let me tell you what I did yesterday.  You remember this tree:

This is the acacia tree. It's an object of the Tree class and it can do something. It can get destroyed. Every object of the Worldobject family had hit points and once they run out, the object gets destroyed and other stuff happens. What'll happen it's that once the acacia tree is killed, it'll instantiate a list of objects around itself. Were talking logs and branches. The idea is that a felled tree will add resources like that, while trees can also be kept alive to give a little bit of resources every now and then. 

This mechanic is now partly made. I still have to make the instantiating thing and a time system to make "every now and then" mean anything.  Time will probably be one of those main mechanics. There'll be day and night and especially seasons and hence years, because there'll be aging and growing in the game. And winters should be colder than summers, which should make a difference. 

Not sure how to implement that one though, sho we'll have to find out.  For now I'm happy to be working again. 

Football sounds and screen sizes

Good morning.  I've had a couple of days off the project and got going again yesterday. I am going to spend the holidays with the in-laws, so you've not seen there end of the lazy times, but that's not the point. The point is that I'm getting close to finishing the PC  build of my yet unnamed goalkeeper game (going - in a flash of creativity - by the name of: 'Goalkeeper Game' right now).

Yesterday was quite productive.  First, I finished the sound system by hooking a sound handler script to a couple of events like the shooting, the scoring, the game over script and a couple of collisions for the ball. Then I downloaded some sounds to play from a free royalty free site. It's funny that searching for 'football' gives results for a totally different sport and one needs to search for 'soccer' to get football stuff. It's ok. We'll let the Americans have their thing.

Then I asked my wife if she had any ideas for a sound when the ball went in the goal.  I found out quickly that cheering crowds don't work when the ball is shot every two seconds and there's crowd sounds anyway (including 'Als we gaan, dan gaan we met zijn allen de kroegen overvallen hier in het mooie Breda.') So she recorded her own cheer.  Then she played the game and we got to test the high score. It worked and I'm very proud of her. My wife does think her cheer does not suit the moment the player fails, but I'm keeping it in anyway.

Technical stuff now. I made a mistake that I saw last time when I discussed the mobile build. The gloves were not in the middle of the goal to start when the game is played on something else as the screen that I tested it in in Unity. I had to change it to take the screen size into account and I think it works much better now. I'll test it again a bit and after Christmas I'll have a couple of days off from work to make the mobile build and see how I can release them.

After that I'll see what other idea I'll start 2020 with. Maybe some first version of Holocene in 2D and maybe turn based or otherwise simplified. We'll see. If I don't get to writing another blogpost tomorrow, I wish you a happy whatever-you-celebrate these upcoming days!

It's a game now!

Good morning everyone. Here's another installment. I notice that while I'm not working on Holocene, the devlogs are further in between. I even found out that I don't have a name for my new goalkeeper game. It does not matter to me really. There may just be less to talk about this game.

Alright, over the last couple of days, what have I been up to? Well, I kind of made the game. The schedule was to have the main mechanics ready by the end of week one, which is last week. This week would be for the GUI and mechanics around new games, pauses and the like. That's what happened. Yesterday was a GUI day. I made this:

I know. It does not look like much but the different texts and buttons are part of four panels that can be turned on and off: the main menu, the pause screen, the game over screen and the game screen.  These panels are shown when needed.

What else am I going to do? First, I'll study ways to build leader boards. The game will laat be ported to Android and iOS and it'll be fun to give the game done longevity by adding the competitive edge. I don't worry the game won't quit after a while, because some of the shots are difficult to stop, especially the high ones.

Next, I'm going to add sounds and probably done background drawing with fans or something else, because a penalty box does not typically float in a space that looks eerily like a Unity scene.  When that's finished, the PC build is ready and focus will shift first to Android and then to iOS. 

Fire the ball!

Good morning. Just a little update on the tiny game that I've stayed making a couple of days ago. My plan is to totally finish the game in a month or less and release it on PC, Android and iOS. Well, what's the plan?

I'm making a simple football goalkeeper game. There's a penalty area with a goal and one of these shooting machines that pump out balls to fire them to the goal. In the goal there's a couple of gloves that try to keep the ball from going in. You're controlling those gloves.

There's a couple of mechanics at work here. First there is the machine, the red and black thing that needs further modeling in Blender later. All it does is have a spawn point for balls right in front of the black nozzle part. The spawn point rotates to make for a random direction within the goal to fire the ball when it has to.

Firing a ball happens 2 seconds after it's been fired before. The spawn point calculates a new rotation and the ball changes location and rotation to that. Then it gets a boost forward.

The third mechanic is the goal. There's an invisible collider just behind the goal line that'll catch the ball when it goes in. Every time something that is a ball hits the thing, the score is increased and so it the force the ball gets next time. A similar thing is there for the gloves, but then the saves count is increased.  It'd be totally random of the saves count increases, because the gloves can't move yet.

Sho what it's the plan for now? First up, I am going to have the gloves move by mouse. By moving the mouse, you'll directly move the gloves to that location as if it were a mouse pointer.  The rotation of the gloves will be so that it'll will always point away from the center of the goal, fingers out, except when the gloves collide with the center of the goal. Then it'll be facing up.

Next week I'll focus on two important things: a game over mechanic with some UI. The game will end once a certain number of goals is scored. I'll have to find out how to do that, but I'd like to have a leader board and a personal record for this. No idea how difficult that'll be, but most important right now it's to have an end to the game. I consider this the minimum viable product.

Next, I need sounds like shooting sounds, bouncing and glove sounds. I'm not going for realism but for fun, so the microphone is ready.  Thirdly, I'll see what I can do remodeling the machine, because it looks like crap right now. I just downloaded Blender 2.8 and it's very different from the version I'm used to, do I need practice anyway. For the game, though, it's not that vital.

In short, tonight I hope to make this into a game that I can let my wife play. I like having my wife test my games, because she's not a gamer and she can be brutally honest at times. I hope she likes it.  Next week will be the finishing of the game. Then I planned two weeks for testing and building it for PC, Android and iOS. That'll be fun.

Small games

Good morning people. It's been a busy week and that's why I have not been able to write a blogpost yet. Yesterday was my wife's birthday and now I'm in the bus again.

Let's just say this up front: I'm putting Holocene on the back burner for a while. This does not mean I'm quitting it. I'll pick it up later. But there's some things I want to fix first.

I have a day job where I'm away from 7am to 7pm every day, so I get to have about two hours of gamedev if I'm not tired, after dinner and before spending time with my wife in front of the television. Regardless of how much I'd want this, I'm not a full time gamedev right now.

Now Holocene it's a big project, a very big project with a lot of stuff that needs to be done and this is where a problem arises. It's kind of my dream project, but after months of hard work, I am not making and gameplay yet. I know, procedural generation, basic UI and navmesh integration are vital. Don't get me wrong, but it feels like I'm not making progress no matter how much effort I'm putting into it.

About a year ago, I started to learn game programming and I thoroughly enjoy it, even the non-gameplay part of it. I'm really glad that I did this. But as long as this is not my profession and I don't get to pay my mortgage doing gamedev, I have to treat it as a hobby that I spend a lot of time doing. 

Returning home tired or semi-frustrated after a long day's work makes you want to do fun things. While my wife is watching the singing contests on the telly, I'm going upstairs to make my game and you know what, I want to make a game.

This means that for a time I will focus on making smaller games that I think I can make in a couple of weeks.  The day before yesterday I started a little football goalkeeper game where you're the keeper who needs to stop shots. Quite easy physics game. I'll make s ball and a goal and a couple of gloves with collision detection and that should be it.

I also have some ideas for a top down shooter and a platformer in a ancient Sumerian theme,  like the Ur Standard in the British Museum.

Another thing I'm considering right now is to have the Holocene project I'm working on be Holocene II. I'm thinking of a Holocene version in 2D it 2.5D, like Civilization. Not sure how that would work, but it's an interesting thought.

Someone on Twitter also put the thought of trying to get a team to build Holocene or a similar game. That's interesting too, but depends on some things. Maybe I'll find a nice group of people that kind of share my view about game making.

But first I'll be making some small games just to make games, finish them and recover. I found out that in 2019 I've been ill for 17 days which is about two weeks more than usual and while gamedev had nothing to do with me getting ill, it'll help me not getting ill.

Slowly back to health

Alright, that took way too long. I caught a nasty illness two weeks ago and while I'm still not 100% fine, I'm on my way to work again.

I have tried to put some time in the game while I had my well feeling moments, usually in the evenings. I did not make very much progress, but some things are starting to look more interesting as I switched focus from the tedious procedural world generation to actual gameplay. What did I do?

First and most importantly, I created a player object that could walk around in the 3D world. It can still walk on water and run straight through most trees and it can drop off the edges of the world, so there's stuff to do left, but it's good enough for now.  The player will directly interact with your tribesmen and objects in the world, but he can't really do much do something.

That's what the characters will be for. Later this week, I'll start try 873 making a character model in Blender and hook it to a character script that'll control its behaviour.  I had some training with Blender so that note theres a huge difference in looks of different tree types which I will have to get back to later. 

That's progress, isn't it? The bottom tree it's kind of the style I'm looking for. Low poly but kind of appealing. 

The player object can now walk around in the world and 'see' the different kinds of trees.  They are named in the UI and when the player gets close enough and presses E, some other non-functional UI fires to tell we're interacting with the thing. That'll be built upon later too.

For now, that's kind of it. I'm finishing this blog now. Hopefully my first day back at the office won't break me down again, because I learned to appreciate health actually. Wish me luck!

Whatever floats your apple

Good morning. I'm keeping this one short for an injury in my hand that kept my development time short last weekend. All I did was edit the world object script to allow for objects to float on water. It works, but with some funny stuff that I yet have to fix.

We're standing on the edge of a lake with a shore line animation moving in the bottom. On the shore are done trees and there's some red little balls on top of the water. Apple.floats is true.  Now there's a problem. The trees spawn the apples and sometimes they fall on a slope and start rolling downhill. Once they hit the water, they stop going down, but they do go forward quite quickly.

Nothing it's stopping the apple from reaching across the pond and bouncing off the edge. It's not so very visible on this gif, but that could turn really weird until the apples have so much speed that they launch through the terrain into oblivion.

Having a thing to stop them is the priority here, so I did a little experimenting with drag on the rigid body component. For now, that either stops the apples too quickly or too slowly. I probably need the drag to catch the apple in the first place and then leave it again.  The catching will take away most of the speed and the release would allow the apple to keep drifting a bit.

Another possibility is to completely catch the apple and stop it and then later add movement to it in relation to wind speed and direction. Need to think that over.

What we also really need

Yesterday I wrote about my new system to find out what need is most prevalent for a character and that worked by deciding which needs passed a threshold and then picking one based on a level and a priority. Well, I found out that I forgot something.

Imagine walking around in the desert and being both very hungry and very thirsty. Luckily there's some food lying around right next to you. You're going to pick that up and eat it, right? Well, that's not how our worked in Holocene. You see, you have 9.1 out of 10 hunger and a staggering 9.2 out of 10 thirst. This means that thirst is more and hunger and thirst have the same priority in deciding what to do, so you'll try to drink. There's no water, but your mind is set. So you die.

The problem of course is that the decision what need to satisfy does not entirely depend on which need is biggest, but also which needs are most easily satisfied. Like we programmers often say (and rarely do) we should mind the low hanging fruit too. In this case even quite literally. Hunger is prevalent too and easily fixed, so we should focus in that too.

Now how does this work? Well when the character triggers picking the need to satisfy, they make a list of needs that hit the threshold to be prevalent.  Then the list will be cleansed of needs that cannot be satisfied right now. From what is left, the most prevalent need is picked and action is taken. Unsatisfiable needs will trigger some warning in three UI when implemented, so that the player can check them.

In our example, the needs for food and drink are both added to the list.  Then drink its removed because there's no water. Food is there, so the eating routine starts, which involves moving to the food, picking it up and eating it.

It's got to be idle

It's been a couple of days since I got to writing a blog post, because I wanted to finish what I was doing before sharing it.

I was refactoring the state machine to make the state transitions easier  to implement without bugs. Like it always happens,  when you try to make something to prevent bugs, it'll have a major bug. And when you finally find and fix the bug, you wonder how on earth that could ever take that long! Well, that's what happened.

In short, when the worker was sent to a goat to collect the food, he immediately started harvesting and it was not until I right clicked the goat again that he went there. This was because of a couple of things:

Firstly, the mechanism for deciding if the unit arrived at the destination,  that was faulty. I have this method to give a arrived-signal when the distance between unit and target is smaller than the radius of the unit plus that of the target. This is to avoid units fighting for position. Problem was that the target was a spot on the edge of the target. This means that the unit would only walk to a certain distance from the edge of the target and that was too far away.  I moved the target point to the center of the target object.

Secondly - and this is that major bug - the unit started in the walking state with the destination at its own position. It would just walk to its own position and wait for instructions. I don't really see what went wrong exactly,  but the unit should start in the idle state. Once I did that,  it all worked again.

Other things I did were to implement a new sub class of building: storage. Every storage thing can contain a certain amount of any resource type a d it'll become a resource with some of its resources when destroyed.

I also got the amphora to look alright from the inside and not be see-through. Last, I got the UI for resources working. Next will be the UI for the selection panel to show selected objects.  After that, I'll start with either building or melee fighting.

Pillaging the amphoras

So, yesterday I was working on a bit of 3D modelling for Holocene. I was frolicking around with Blender and made this amphora.

This amphora tells me I'm pretty happy with my getting better with Blender, because, even though it's not difficult to make an amphora, it does look neat. I also learned that this one was not right and I needed a different way to make it.

The above example is made of a hollow cylinder. This means that it does not have an inside.  Now you can't see that in Blender,  but once you put it in Unity and you point a camera to it from the top, you can see straight through it. I spent over an hour trying to make an amphora that looked like this one, but found the handles on the side difficult,  so I went to bed.

Amphoras also gave me an idea for a new kind of worldobject: storage. Games like Age of Empires have storage buildings, but they don't have a maximum capacity. This means that, with one mill, you can have millions of tons of grain (and deer meat).

Storage objects in Holocene will have a capacity,  so there'll be a change in the delivery mechanism.  If an amphora is full, workers will need to bring their food somewhere else. If all amphoras are full, you can't get more food in your stockpile.

I'm not sure if I will implement bringing mechanisms like in The Settlers where workers bring wood to a building site and so on, but I will include pillaging. Amphoras can be broken, leaving the food to be gathered. This will bring extra options for warfare.

You see it's not fleshed out yet, but the ideas are there and I'll let them simmer for the day until I get to implementing them in the game.

Chasing goats

The gathering mechanics are nearly finished. I have a system to send a worker to a resource.  Once it arrives there, he'll start carrying resources from the thing until it is depleted or the worker reaches his carrying capacity.  He returns the stuff to a building and goes back to the resource to continue gathering or find another resource of the same kind. If there are no resources available within a certain range, the worker will look for other objects that become resources when they die and will attack that.

Every worldobject has a slot for a prefab to instantiate when its health goes to zero. For instance,  our inevitable goat is a unit, much like a worker, but when it dies, it turns into a source for food. While that could be done in many different ways,  in Holocene,  it's done by destroying the goat object and replacing it by a dead goat one.

Anyway,  when the worker has been gathering food and the source is depleted,  he may start chasing goats to kill them and get access to the food. For that, I made the chase state in my state machine.  Chasing is actually mostly the same as walking,  but with two main differences.

Firstly, chasing updates the destination all the time. If you walk to an object and the object moves away, you still walk to the spot where the object used to be.  Chasing will update the position of the target and change the direction accordingly.

Secondly,  chasing might result in fighting. In fact, that is the aim of it all. When the target gets inside a certain range,  the unit might start a range attack. If it gets closer there'll be melee fighting.  Of course this needs fine tuning,  but this is what it will probably be like.

Transitions are important

Working with and getting used to Unitys Animator, I find that the beef of these state machines is in the transitions between the states. Different states have the agent do different things, but the main thing is to get the agent to go to a specific state when you want it to.

I'm working on the gather mechanics for workers.  I put a little rock from Blender in my scene, added a resource script and focussed on the interaction between worker and rock (and explaining to a friend that not all interaction is sexual).

In short, you right click on the rock and the worker will move towards it. When it's there, it'll make a difference if the agent really is a worker and not, say, a catapult. Catapults can't gather resources in Holocene. Workers can. I managed that by adding a task enum to the unit script. That enum contains certain things that only certain units can do, like gather. The worker script will override the unit script for moving to a resource, adding the gather task. Now that is used to trigger gathering.  Guys without the task will go idle on arrival.  Others will go to the gather state.

Then gathering happens.  The worker will get resources over time and the rock will loose some. Then we need to decide what to do next.  When the rock is 'empty' or the worker can't hold any more resources,  we need to drop it to a building.

I've not finished this yet,  but I will save the resource object and location in a separate variable and find a suitable drop off point and object to go there, setting the task to return. The walking behaviour takes the worker to the drop off point and triggers the dropping.  Next the resource will be the target again and the worker returns to gathering. When the wotker does not have any resources and the rock is empty too, he's finished and will look for another rock to carve.

This should be the gathering AI. It took my some time to think up, especially since I need to get used to the triggers in animators. I am at a point though where I think I know what to do next.

This is one of those things I love about making games. There's little victories around every corner,  much more than in my day job. That's very motivating.

Fighting for position

Ok. Weekend is over again.  I have not been able to get too much work done in Holocene this weekend as I had other things to do (and yesterday night I wasted my time watching The Marathon Man).

What I did do is making a start with moving units. For that, I made another of these primitive shapes based Workers. A capsule for the body, spheres for head and red nose to know which way he's facing and an elongated cube for arms. And a worker script and some needed Unity components.

First thing I set out to do is to implement the walking behaviour that I made for goats. When the unit is selected and the player rightclicks on the ground somewhere,  the unit is going there. Quite easy.

When clicking on a friendly unit, the unit should go there and stop right next to it.  Well, that gave us this little gif that I shared on Twitter:

Now what happens there? Note that I have not yet implemented any fighting mechanics.  These workers are not fighting per se, but yet they actually are. The thing is, the moving one is trying to stand on the spot where the stationary one is already standing. Because two entities can't occupy the same position, there's squeezing going on.

This was actually quite easy to fix. The worker script knows what object it's going to and that object knows its size. All we need to do is tell the walking behaviour script what the size of both objects is. Add them up and we have the stopping distance. 

This is actually really all I pulled off this weekend.  Hopefully I have more time for my game this week.

Setting up the interaction

Ok, another update. Yesterday, I wrote about a little issue in the WalkAround state of goats.  Well, it somehow took the best part of the evening to fix that. Somehow the trigger for starting to move kept getting hit before the position was picked, having to goat literally go nowhere.  Well, done now.

The more interesting thing to talk about  is a little groundwork for giving orders. I already had a system to find objects when given a location.  I upgraded that with a class of references to everything you need to interact with an object. In the end, orders will all be "interact with this object over there" and the kind of object is central to know what "interact" really means.

When I  right click on an object,  selected objects will run a method on a base Worldobject class to decide which virtual void to run, with some basic general stuff and possibly overriding methods in a derived class.

Sorry if this is technical. It means that I define basic behaviours for interacting with objects of a certain kind that should apply to anyone. When a certain agent has its own behaviour for some interaction,  I'll program that and run that instead. This is how I understand object inheritance in C#.

Well, all I ended up with visually is that Holocene looks exactly like it did the day before yesterday,  so I won't bother you with screenshots or the like, but now it should be set up to do things I did not program yet. I like to have it flexible, because I know it is getting more complex quickly now.

Big goats unite!

Ok, that went more easily than expected.  Yesterday, I had a couple of hours to work on the selection system for Holocene and I think I finished it, which is nice. 

I made a script to handle selecting and deselecting objects for the player and made some changes to the script handling input from the mouse. As I said yesterday,  the script keeps track of what object is under the mouse cursor. When the user clicks, the following things can happen:

• You click on an object. It gets selected.
• You hold shift and click on an object. It gets added to a list of selected objects. The selection script always knows what kind of objects are selected and uses that information to decide whether the clicked object will be the only object to be selected or the other selection remains. Only units you own can be multi-selected. If the current selection contains other kinds of objects (e.g. buildings or enemy units), or the object to be selected is another kind of unit, the selection is cleared and that one object is selected. 
• You click somewhere on the ground and drag a box on the screen. All owned units in the box are selected. 

That's it, actually.  Because I don't have any GUI yet, I used the inspector to test it and it seems to work fine. In the little gif below, the big goats are owned by the player. The small ones are enemies. I try all the ways to select them.  It works.

Next up will be making basic moving units. Select 'm and right click on the ground to have them move there. The goats are not supposed to be controlled. They move around on their own. 

Selecting Objects Again

Good morning, people. I'm back from a weekend with quite some game development time and half a season of Casa de Papel. It was raining, but now I need to go to the office again,  so it stopped raining.  Time to tell what I've been up to this weekend.

First, there were two issues related to the world not being flat. I kind of solved them, but I'll revisit them when I feel like it. The camera is flying over the terrain and it avoids high hills like the plague, which is nice. It does not do that very smoothly. I need to find out why.

Same goes with the rotation of my models when moving uphill or downhill. It seems the navmesh agent does not care about the y-axis, so I had to do the rotation myself. After tinkering (and cursing) the rotation is now correct, but it flashes to that rotation in an instance. But hey, quaternions are evil. I'll get them good one day.

Now to the meat. As I told you, with the hilly terrain, I decided to refactor majorly, so I  am not porting all of my old stuff to the new Unity project. First thing to remake is the mouse control. The control script always knows what object the mouse is pointing to. That will make it easier to interact.

First thing is selecting objects. Like in the old project,  that happens by left clicking. Holding shift will add an object to the list, but only if we're having your own units. You can only group select units you own. All other kinds of objects are only selectable on their own.

This works partly and I expect to finish it soon, but it was late yesterday, so being tired, I probably put some bugs in there. I'll revisit this tonight if I have time. After that, I'll see if I can get box selection to work. That'd be an entirely new feature. Hopefully I can start with that today or tomorrow.

Dead, depleted and vanished

Alright, what did I do yesterday? Well, two things from my little list that I made recently. At least, a variant of one.

First, I wanted to make sure that when gathering or returning resources was interrupted,  you could order a worker to drop the stuff at a building.  When you right click a building that you own, the script will check if the selected unit has resources and whether the building is the kind of building that will accept the resource type that the unit is carrying.  If it is, the unit will get the task of returning to that building and dropping the resources. If that is done, he'll go idle.

The second thing is that once a resource is depleted, it is no longer useful and only causes annoyance for the player to find out which of the 17 felled trees have wood left. Now, the object will have its alpha decrease to zero over the course of a couple of seconds.  When the alpha is zero, the object is transparent and is destroyed.

I am going to change this later though. Right now, this only works for resources.  I'm going to move the functionality to the worldobject script and have it apply to dead units and broken buildings too. Furthermore, I think I will make a dead-and-depleted model for those objects, like a skeleton, a ruin of  tree stump. That object could then be removed more slowly. Most importantly, I now know how to make it work.

Between dinner and Casa de Papel

So holiday has ended a couple of days ago  and I'm writing this blog from the bus again. On my way to that thing we call the office. As I probably said before,  I have a full time job as programmer making office applications for customers. And by the fact I write my corpus of blogposts in the bus for a part, I  need to travel every day.

This means that I am home quite late and that doesn't afford me much time to work on my game. Holiday is over indeed.

Having said that,  I'm glad I was able to lay some groundwork for things I could implement in the hours and half hours of the evening,  between dinner and Casa de Papel that me and my wife just started watching.

With the placeholder GUI in placeholder place, the coming time will mostly be about object interaction, about unit AI and the like, but only in following orders. Letting the enemies control their units is for later. For now, I'll be focussing on making sure that when a decision is made,  the objects know what to do.

Things I am planning to do soon include:

• Changing a dead object or a dead and resourceless object to look and behave differently.  For instance,  when you kill a goat, it'll fall over and you can harvest the food. When the food is gone, it looks the same, but you can't interact with it anymore.  I want this to be clearer. Maybe turn the goat into a skeleton and have it vanish over time.
• Right now, resources can be dropped at any building.  I'd like to change that. You shouldn't be able to drop wood at the barracks. I'll probably build granaries, storage buildings and the like for that.
• When you attack a unit and it runs, following it is very simple. Have the unit close in and if it's close enough, continue attacking. I'd like the attacker to have to face the defender before fighting.  Besides,  I don't want the following to go infinitely.  That could be a tricky thing later when players discover luring enemy units.
• If you gather resources,  you return to a building. That works. But if gathering or returning is interrupted, there's no way to just drop the stuff at the building  and be done with it.  To drop something now, you need to first send the unit to the resource to have it return. I'd like to trigger returning directly.

I don't think that these points are very big, so these should be fine for the evenings. Besides,  I really like the small successes that such things make. They are really motivating.