Fully-formed barracks

Alright, So I can now build fully formed buildings. Or rather, I can put them in place fully formed. That looks like this:

You select the red worker guy and click on the barracks image. Then it will generate a new barracks (actually fully formed and functional already) and you'll drag it over the ground below the mouse if you move the mouse. Pressing escape aborts this mission, clicking, drops the building in place. Next you can immediately work with it. I'll have to implement some extra stuff, because it's possible to put the thing right between the green guys. The script will notice if you're not pointing to ground, but to something else, but you can still put the thing between the green guys to the right. That'll not be there by the end.

More importantly even, I will not allow any buildings to be put in place as fully built. Have a look at Age of Empires if you don't know what I mean. I want to place some stuff as a starting object. It'll just be stuff, with a broad shape of the ground plan of a barracks. Then workers (or other building guys) will work on it and over time (also depending on how many guys are working), the object is replaced by some just-started barracks, some partly formed one, some almost finished one and an full barracks. Only then does it get alle the things it needs.

Technically, right now, the building placement script just drops the prefab of a barracks. What I'm gonna do is create a Unfinished Building class that has a couple of prefab references. I drop a prefab of that class in the placement script and it'll be able to interact with the workers to change to new prefab. I guess I'll have a mechanics comparable to the gathering of resources. Gathering will have workers take away amounts of wood from the tree. Building will add hitpoints (or something else) to the building. Should be implemented easily.

Anyway, This is what I try to make next week. I'll be in Santorini the two weeks after that.

Making it look anything like good

Graphic User Interface or GUI. Can't live without it, can't live with it. Lately I have been working on whatever's going on at the bottom of the screen when objects perform actions. It all works, but it does not look anything near alright. 

Now I don't think I should tell anyone that the graphics I am using are placeholder and that does not matter. I could change them whenever I want to. What does get under my skin a bit is the arrangement of the elements on the screen.

The stuff has this position that we know by now... when you look at the animated gifs. Problem is that I'm not releasing an animated gif when I have finished the game. It's supposed to be an actual game.  More specific: a pc/mac game.

This means there needs to be thoughts put into layout. What screen size am I supporting? Recently I bought a bigger monitor for my computer and that makes me realize things. When I run Holocene maximized, this is what it looks like right now.

All these identical rounded corners aside, there's so much empty space at the bottom and things are pushed to the side there. It looks - let's face it - very very bad.

Now part of me is talking the placeholder story. I'll have a look when I make the actual graphics.  Problem is that that part of me is wrong. It simply is. Can't help it.

I need to have something thought out to make sure everything  fits together.  Just take a look at the mini map placeholder to the bottom right. It looks out of place while there's enough space to put it.

Then there is this thing when I resize the screen to see that it supports.

The resource bar holds its own quite well and I see no reason to support screens so narrow as to get it in trouble,  but the bottom, again, it's ugly. I need to get my pencils out and try something in the next couple of days.

Life, the Universe and Everything

It's been four days since the latest devlog and honestly I don't have too much new to say. Just a little bit of thought about Life, The Universe, Game Development and Everything.

Game development is the thing that I want to do when I have the time. Problem is  - and don't give me the "busy man" thing - sometimes life gets in the way. Nothing much is happening,  but this global warming thing... it's been hot over the last couple of days and those are the days the little air conditioner at home cannot cope with, so no sleeping for neither me nor my wife. Isn't that sad?

This went on for two days until yesterday I could go to the little computer room again an not melt. Now those guys at my favourite team announce they'll present a new player for next season. So here I am charging the F5 like nobodys business.  Life has a funny way of interfering.  And between you and me,  I kind of like it this way.

Now for #gamedev, I did get things working, though it's not finished yet. The progress of the actions is kept when switching from object to object.  Progress runs on and after some time,it's finished causing something.

It's still buggy, because one is not supposed to discover iron working 26 times in a row, but it's mostly lack of time that caused that. Spawning units seems no act meh too, so far. It'll be ok.

Actions should be working by the end of the week. By that I mean creating units and discovering science (just flags that allow for other actions to be used). Maybe also something economic , but I'm not sure yet, especially since the gathering mechanics that I have can hardly be called a complete economy. We'll see how that develops.

Right now, the bus to work is approaching the end point and it's time for what they actually pay me to do.

Don't mix up

I thought I had it all figured out. It all seemed to work. Yet now I can't see how I could be this stupid. There's a reason why in a tutorial they always implore me not to get behaviour classes and display classes mixed up. So what did I do?

My work, last week, was mostly about creating actions, linking them to an object, triggering them by clicking, a timer with some GUI and the result of the action being there. I put all of that in a display class.

Part of it makes sense, because the button to trigger the action is pressed on the display.  The rest does not. What happened was that it all worked smoothly as long as the object doing the action was selected. You know, selecting an object removes the display of the current selection, including all the unfinished tasks.  That's the problem here.

What I'm now working on is a progress class. The progress class tracks if an action is running, how long it will have to keep doing that, if the action will be done once or multiple times (as in creating 4 of the same  type of unit). And it will finally perform the action in the end. All the display does now is "I'll have one more RecruitWarrior please."

What did this teach me? Not so much. I honestly believed the way I had it was the right way. Testing was mostly to watch the GUI doing its thing, so I never deselected the object until I wanted to check if, when I run a science type action in one barracks, it should not be available in the other.  It was. And in the one one, research stopped.

Well, getting back to the beginning: don't mix up data, behaviour and display.

Reading the Big Book of Basic Stuff

So, this is kind of a technical devlog. The fun thing about working on Holocene is to combine my creative spirit, being a historian and learning a partially new craft. I work for a software company and I program business applications with databases and interfaces to influence whatever is in there. It's programming and it helps develop the way of thinking that I can't explain to my mother. On the other hand, while Java, Python, Javascript, Lua, C# etc are kind of alike, I'm working with a different kind of framework, much more high level than those others, even when Unity is actually doing much of the high level stuff for me. Learning to work with Unity and C# is an interesting journey for me.

I'm getting the basics as we go, but sometimes I have trouble fully getting grip of object oriented programming, I guess. I find myself having to rewrite stuff because I need it again in another context. For instance, I have this snippet for a gatherer to find where the drop-off building is and then where to go, because Navmesh agents can't walk into objects that it would walk around. I thought I needed that just for this purpose or at least for strongly related ones. I was wrong.

With the recruitment of units working, I needed a way to place them around the barracks. So what I did yesterday was kind of weird. I put the unit on top of the rally point, made it find out where the object of the barracks is and where is the nearest edge of that collider is, move the position directly to that position and then have the unit walk to the rally point. Because it worked and I just wanted it to work, I called it a day, but today is another day.

I am finding out how to use methods in a context where they do not have to have any specific kind of object involved. For that I have found out that static classes are useful. They can hold methods and global variables that you might need in any context. For now, they hold stuff about the size of the screen and other such things. From today on, I will populate it with methods that are generic. For instance, enter a position and the method returns whatever object is there (if there is one). Enter an object and the method will find out what are the edges of it.

My aim is to have this all grouped in a well-arranged way so that I always know where to find those information-gatherers. I'm sure that I will end up with a long script, but it's a script specifically designed for that purpose. I'll probably have it be a special script to distinguist from the screen size stuff. Tomorrow, I'll rerun all my scripts to find if there are such generic methods and variables that I need anywhere and then I'll put that in the script. I don't want every unit to have its own (identical) way of finding the entrance of a building. I just want to tell the unit to look for it in the Big Book of Basic Stuff (BBBS for short).

If recruitment was this easy...

I did what I set out to do again today and it's only 11:15 pm. I set out to have a system to recruit units from a building. I know I said I'd be refactoring and I'm going to, but mañana-mañana like they say in Spain. I just wanted to have that little bit of work I was thinking about in the bus home after work. I have this actions class that I link to a building or a unit and (if it's of a recruit-unit-type) it has a game object prefab of a certain unit that we need to instantiate. That one should find out which edge of the building is nearest to the rally point and then it needs to go there.

(the bug you see here, it's been fixed. who notices it too?)

This works nicely. Now it's possible to create units indefinitely, because they have no cost, but implementing that should be easy to do. Besides, there will be a building progress to creating the unit. Right now, they pop into existence. They should do so, but not before it takes time to create the unit. For that I'll use a filler sprite that fills over time, depending on the kind of unit and possible some science-type action (which I will not implement yet).

I am quite happy about the workings of the recruit action though. It works with delegate functions that are called from the display class, because it's a button being clicked that triggers a function in the action class indirectly. It should also be easily expanded to work with different kinds of actions. It's starting to look like a game. Of course there are no challenges yet, but those will come later.

For now, have a nice evening and we'll meet again!

Which one is that

Alright. I think I have the basics for the actions panel working now. It's sort of an inventory UI within an inventory UI.  Of course I wanted to make it work, but I especially wanted to really get how it does myself without referring to the tutorial that I mentioned a couple of months ago too much.  I think I do now.

I do see that my game needs some refactoring soon and while that most certainly is not the most inspiring nor the nicest thing to do, I'll have to get it over with now that my work does not cause issues that are difficult to repair yet. So probably, I won't be making much new stuff for a couple of days and focus on that.

While I do that, it does not hurt to think about small but important design things. The one I'm thinking about now is how to show an object is selected. I might have 3 identical warriors standing side by side and select one. Now what?

The selection panel with the actions thing, it will tell me I have a warrior selected, but it will not tell which one. For that I had a selection box around the warrior and that works fine, but it looks weird and crowded when selecting more than one unit at the same time, so I'll drop it in favour of some other visual cue.

I notice that nobody seems to like the box, so that is nice. I do have three options to consider:

• An object at the feet of the selected guy. This one looks nice, but only in units, because buildings and resources (the other kinds of objects that are selectable) don't really have feet.
• Something above the unit, like with The Sims. Problem here is that it might well be just like the box I had. If there are multiple units together nearby and I select one or two, it becomes hard to see which one is selected,  especially with the health bar prominently at that place anyway.
• Something in the object itself. This one is hardest to implement , because while the other two are really just turning on and off an object, here there must be more active work and it might need to be different for every object. I could try if I can draw a line around it. I just hope it doesn't make a box mess then.

Now that I consider it, I lean a bit towards a thing at the feet,  with something special for non-units. It's actually good to have differences here, because buildings, units and resources play a different role in the game. I also have to think about the fact that selecting enemy units should be different too. Enough work now.

The bus is almost at the office.  I have get ready to leave.  Have a nice day!

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?

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!