So for the new year I have put a lot of work in so far adding one more mechanic I wanted, and bringing up a lot of code to fix known bugs. Most that occured in the past couple of weeks with resource implementation and new way to find the closest location to an object from a unit.
So the first thing I did was address the bugs created in the previous week while they were still fresh in my mind. I altered the closest point algorithm to include the units current position if that position was one of the possible locations. It will then pick this location if it is the cloesest. I fixed the closest resource node by identifying a problem with the box collider being too large and actually causing my algorithm to locate the near locations to be just further than it needed to, although it worked fine with buildings. The solution was just to reduce the size of the resource nodes colliders. This led to a new problem where clicking on the resource nodes became difficult due to the small collider size to fix the previous problem. To solve this I add a new child object that acted as a unwalkable collider, and sized it to the reduced collider size. Then I took the original collider and resized it to be large again. At this point the grid identified the unwalkable areas by checking the unwalkable, unit, bilding and resource layers. So I unchecked resource so it didn't use the larger collider again and this allowed for the closest points to be where they should and allow the resource node to be easily clickable. As this change showed a cler benefit to selecting objects I altered all the current buildings and units in the same way and removed the unit and building layers in the grid check.
I updated both the worker and resource UI to display details that are relevant to the player so they can see. For the worker these include health (although no actual health mechanic is yet implemented), it's current state and it's current holdings. The resource node displays it's total amount of resource left.
Small changed were made to the resource system to improve what was currently there. So when a resource node has run out of resource and gets deleted, rather than becoming idle a worker will now find the closest resource. A change was made to make all the resourceType variables be an enum of resources from Food, Wood, Gold and Iron instead of integers to reduce confusion. Using this made it easier to fix a small bug where going to a resource node of the same type would reset the workers current holdings of resources. Then finally, if the player wanted to send a worker to a different resource node and not want to lost the resources they have holding, they can send a unit to the town centre to add what they have to it.
The big mechanic added this week was the training mechanic. Something that was temporarily put off while I worked out how to do it, as although it just needed to work in a coroutine like building progress does, I needed to work out where this coroutine had to be placed. As originally it was planned to be apart of my training script. The problem with this was each building could be training units at the same time, if the queue was in one script only one unit could be trained at a time across all buildings. It was therefore placed inside the building script instead. In here it was able to queue all the units to be training in that building. At first the script was still checking the cost of the unit after this training time had been completed, so I had to alter it to check when it was being created to prevent multiple units being created at the cost of one or having to wait the whole train time to find out you can't make that unit. Another change was made to check against the population properly. Where it found out all the units being training, added that to the population, and then if 1 was added to that if it would go over the max population the player can have. If it did then the unit isn't allowed to be trained.
A very useful idea learnt from other RTS games is the ability to cancel training units. As you may have set a couple too many units to train, or simply you need to actually spend the resources elsewhere and need to cancel them from training. So using a simplified version of the select ui with multiple units, I made it possible to click on the unit to cancel. I then had to show all of the queued units. As a possible idea down the line is to have one building allow multiple units to be created, and say if the player had 4 normal archers queued then a mega archer right. If they need the archers, but not necesarily the mega archer at the back, they should be able to cancel that one without stopping the current training queue. To do this again I used a simplified version of the select object ui. Unlike the select object ui, it makes sense to have a limit on how many units can be queued at once in a building. So this made it easier to create the UI to display that. Rather than dynamically creating the icons, and making sure each icon properly references the object it is showing, I was able to create placeholder icons that the texture simply changed to show the different units. Then when a player clicks on one, rather than holding a reference to it, each button can have a different integer being passed through it representing it's position in the training queue list. With this number it is very simple to then find what unit it is, remove it from the list and refund the resource cost back to the player.
