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!