Pagina's

Tuesday 24 September 2019

Mountains and valleys

So. It is taking longer for me to write new articles on this devlog. That is mainly because I am studying ways to improve on the bumpy world that I made in the previous version of Holocene. Right now, I'm working on procedural level generation again and I think it's starting to dawn on me.

In the beginning of this year, I bought a couple of Unity courses on Zenva.com to get me started on this new years resolution that I got myself into.  Now that we're 9 months along the way, I saw quite some of the hours of videos and completed some of the courses.

One of the courses is on procedural level generation.  It uses a Perlin noise to make a height map and move vertices on a grid. Then it has a heat map to make sure stuff at the equator is hotter than around the poles. That is mixed with more noise to have some randomness. Another map brings the moisture and that comes together to create biomes. All very interesting.

I am going to finish the course,  but I am not going to use it straight away,  because I want to improve it.  Firstly, water is just blue land. Making a game about guys walking around the world,  water cannot just be blue land. I know what that is about and I think I can fix that, by having the water a separate object that the navmesh can now cross. I'm not sure how to do this exactly, but I'll manage.

Second thing may be more difficult to do and less important. I don't really like the way the ground is textured, by a colour map. Some parts of the world are "boreal forest" (which is a difficult term for us Dutch right now, by the way) and that's a specific tint of green for the ground. There will be trees and plants later, but I'm not sure green floors per se will be right, and especially not the red deserts that Zenva came up with.



Next, I am not sure if the course will cover this, but I will need more  detailed stuff on the scene to interact with. That'll in itself probably be like trees which will be in the later part of the course, but I don't know yet.

Probably even more important than all the other things combined is preventing the game from taking too much resources generating the world and keeping track of it. I'm planning to have a huge world, kind of like Minecraft. Problem is that the procedural process takes quite some time on a 10 by 10 tiles grid. I know this is mainly because of building a navmesh for the tiles. That should go better later. I hope I can manage that without clogging the PC totally or else I might need to change my scope to smaller levels which would really be a shame.

Whatever will be, first I am going to finish the course and restudy the code because some of it is very poorly explained.  Then I'll tey to find the solutions.

Thursday 19 September 2019

Flint tools, mammoths and game ideas

It's been a couple of days without game development, but not without thinking about it, because a though has been creeping up on me over the last couple of weeks. When I was fiddling around on Blender and making the amphora for the game, when me and my wife went to the prehistoric museums on Santorini and back in the Netherlands, I saw these things and, being an ancient historian with a passion that goes back further than even Civilization I, I think I might be talking Holocene in another direction.

Holocene, as it now is,  is a Real Time Strategy game with units to control etcetera. That might not stay that way, because I don't have any connection with that Worker guy, even if he does his work well. When I made the amphora, I but it in the building category and when I scripted it, something is off. Then I saw the flint tools, bone jewelry and the like at the museum.

I get the feeling I am not expressing all of this right, because it is a feeling I have and English is not my native language but the point may be clear: almost certainly, Holocene will become a different kind of game.

It's not fleshed out yet, but I think I'm going to restart the project again and make the view smaller. We're not having armies of generic guys, but small bands of actual people with names, learning to make  flint tools, hunting animals etc.

I follow a YouTube channel by Dave Frampton who creates his game Sapiens and his project might have influenced me too. I'd urge everyone to watch his project too and maybe play the game when it's ready and I'm not going to copy his project. I do want to thank Dave for both helpfully answering my questions on Twitter and showing me a way to combine my ancient history love and gamedev into something worth putting so much time in.

I'm also thinking about having a YouTube channel too. I like watching devlogs and I might need what we Dutch call "a stick behind the door" to prevent me from wandering to yet another project. Wish me luck!

Sunday 15 September 2019

UI and a glass cube

So, last weekend was fun. I did not have much time for game development as we went to stay in a 3x3x3 glass cube in the woods for the night. We did. Next day was the prehistoric museum so that was fun too.

I did spend some time on the game yesterday. Still the UI. What I want to make is the panel at the bottom of the screen where information on the selected unit(s) is shown. It'll be a panel with different parts that show or don't show,  depending on the type of object that is selected.  There'll also be a panel with icons for actions the selected object can perform. That needs some work and that's what I am doing this week, probably.

Tuesday 10 September 2019

Showing information

Alright,  a short one, because I don't have much time now. Yesterday and the day before, I was working on the UI gor Holocene. For now, as always,  everything is placeholder, but we'll have a resource panel and a selection panel to show information on the game.  The resource panel is already working.  It reads all the storage objects the player has and shows totals per resource type.

The selection panel is going to be a bit more complex. I had my plan for this written out before, but it needs some finetuning because the code is a bit different.  It'll be fine though, because I like what it was, so this should not take too much time. For now, the UI with the Worker unit selected, will look something like this:


Remember, placeholder is the key word here. I want it all yo work first before making it look pretty.


Sunday 8 September 2019

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.

Wednesday 4 September 2019

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.

Monday 2 September 2019

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.