A big procedural overhaul

Good morning. Let's get to it.  Yesterday, while I was working at home for my day job a mechanic showed up (it was an appointment) to change some electric stuff and that means that for a while we did not have any electricity. I decided to spend the time on thinking about Holocene. This is what I came up with:

This is what it kind of looked like before yesterday and I backed up my project because...

Well, I agree. I owe you an explanation.  Well here it is. I'll try not to make this too technical. I made some design mistakes. The most important one is that I never considered a world with any size above one Unity terrain which is about 500 meters if I'm correct. I'm sure most of you know that setting up an ancient civilisation will not work on so small an area.

What I did now is plan for a system where the world can be really big. The above image is a tile. It looks like nothing worth spending time to discuss, but it'll change. In the game, we'll have a couple of these tiles rendering while we're walking around. This fits excellently with the first person camera view, because you can only see a couple of tiles at any given time, so why render all of it?

Second thing is that with Unity's terrain system,  we'd have a landscape that does not fit well with the low poly models that I have in mind, like the mammoth. I think it'll immediately look like a weird mash up of different art styles. With this regular geometric shape landscape, I think I can prevent that and keep the artistic coherence.

Lastly, and this is tied to the big world tile thing, I need rivers and seas to have this game the way I want it to be. Water its pretty easy to implement. Just have a landscape and drop a plane with a shader on a certain height et voilà. Problem is that that'll make for ponds and lakes, and not for seas really.

What I plan to make is a system where some of the tiles  (don't be surprised if that's over half of them, like Earth) sea tiles. I'll probably use some smooth Perlin noise to get some magnifier for the heights on that tile. Need to find out how that'll work in practice.

Rivers will be something else. I'm not sure about that either, but in my mind, I'll have something decide a random place above some height threshold and drop a river there. That river will flow down the slopes of the landscape until it hits water. Maybe it'll have to push through when it hits a depression with hills in all sides. Maybe that'll be a little lake.

Whatever I do there, I'll have to be mindful of the time it takes to generate the terrain. It's ok to have to take 20 seconds if need be and I'm sure the generation of the world will be one of the heaviest processes I'll ever have made until now, but let's bit have it take minutes unless it's absolutely necessary and let's certainly not have it take time during runtime.

Anyway. I thought I needed this blog post to explain myself and get my thoughts to paper. When I told my wife yesterday, she was not pleased by what she saw. I'm sure she is not the only one.  Besides, the Perlin noise thing for the seas, I came up with that piece of genius during the typing of this blogpost.

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.

What we really, really need

So. Back in the bus again. It's dark outside the windows, so why look there? I have a short update again, because yesterday I started the AI basics for Holocene. This is mostly about fleshing out the structure of needs for our characters.

There's five needs defined right now: food, water, sleep, warmth and an ill-defined social one that I did not put much thought in yet. Any character had these needs in some measure and they're what drive the behaviour of characters if you don't ask them to do anything.

The aim is that characters will try to satisfy their most important need by doing basic stuff. For instance, if the guy is hungry, he'll look for apples and eat them. Don't expect him to go on mammoth hunt because he's hungry. There'll probably be some message system to notify if the character can't immediately satisfy his needs, because you'll have a job then.

Right now, we only have a system that decides what need to focus on. A need has a priority value which it's highest for food and drink and a bit lower for warmth and sleep. Sleep had another perk, because once you get over a certain threshold, the character will go to sleep, no matter what. 

For the other needs, there's a threshold once one or more of the needs ate over it, the priority matters. The highest level need with the highest priority will get focus. This means that with a threshold at level 8 out of 10, 8.5 food need will beat 9 warmth, but will be trumped by a 8.6 water need. Like that.

The AI will then have the specific need to focus on. Depending on the distance to the sole and stuff like that, the character will make his move.

The idea behind this stuff is that the need checking system should be able to be bypassed by player actions.  So the guy needs social interactions? I don't care, there's flint rock to carve!

I'm not sure about how the autonomy of a character might sometimes override your decisions. Do we want characters to die of thirst while fighting a mammoth? Probably there's going to be some special thing in the Need class that'll make sure you get notified at least if that's about to happen.  Need to think of that some more.

Generating the Big Apple

So. Back in the bus again. It's been a couple of days. I made some progress in refactoring of the object generation for my terrain and I also now have a little apple model to have the characters interact with. This is important because the plan is to have default behaviour for the characters to try and satisfy their needs. Apples are here to satisfy the need for food. Can you believe it?

Before my refactoring, apples were actually functionally the same as rocks. They appeared on the terrain in a pseudo random way. This made for weird situations where there were apples around and not a single tree anywhere. To fix that, I moved an object generation method to the object script for the tree object. Trees spawn apples like they're supposed to. No trees, no apples. I don't know yet how I'm going to trigger the generation, but for now, yes get one chance top drop an apple and that's it.

I also decided not to repeat myself instantiating objects, so I moved all instatiation methods to a central script and run or with parameters. That took some debugging, but I think it works well now.

There was something off with this image, but the generation worked alright. All I had to do is make the model smaller in the prefab.  In the old system, spawning apples worked well because the scale was set from the script. Now there is not going to be much variation in apple size, so I'd better not do to much with it. So I fiddled a bit and this is the result:

Those characters better like these apples if they know how much work it was to get them there. 

They have character

So.  Back in the bus to the office. They say protesting farmers are blocking the roads, so we might be in here for some time. While I don't share their aims and reject the violence they use, they have the right to protest. For now, no right wingers blocking the road. We'll see...

Yesterday evening was quite a productive evening for Holocene. I finished the first version of the starter script. It generates a terrain, populates it with trees and rocks and places the player object at a random position on the terrain.

The player can walk around and discover. When they press the space bar, two or three white capsules appear. While they don't look like it, they'll be your first tribe members.

There will probable be some work to be done left. The characters (I'm calling them characters) are rigged to be able to move around on the terrain with certain constraints like the steepness, but they're generated within a random distance from the player in any direction. This means they could instantiate over the edge of the terrain. That could pose a problem because for now I only have one terrain and I don't want the characters to spawn in the endless void of Unity.

While I'm planning to fix that buy generating a very large or even endless terrain, another issue needs to be fixed anyway. The characters can spawn anywhere and that includes places where the steepness is so high that they can't move and even at the same place as trees, rocks, water or anything else. That'll have to be fixed and I think that should not be a problem.

With that out of the way, I also started the scripting for the characters and their well being. The idea is to have anyone have general health, things like energy, sickness and injuries and a set of needs like hunger, thirst, sleep and the like. These will all be properties of the characters that I'm thinking of how to implement.

Next there will be skills. Any character will have a skill set with skills and their amount of mastery. That'll decide what the guy can do.  I think this will be the next thing I need to lay the groundwork for.

Right now it's time for work in the office. I don't think I'm seeing many tractors blocking the highway this morning. Which is a good thing, but it means this blog is done now.

Rolling Rocks

Good morning. It's Monday again so I'm off top the office. Time to share what I've been up to over the weekend. I said I'd be starting game mechanics and I really did, but that did not result in game mechanics but in some changes to the level generation. That is because I need rocks and other small objects to appear and these need to have some physics about them and a way to interact with them. Just the meshes of the Unity terrain are not enough for that.

What I did was create a couple of rock models in Blender and hook them up to an empty game object in Unity. The model gets a collider component and a rigid body for the physics a and the parent gets a worldobject script. Then the objects are dropped onto the terrain by the generation script.

What we see here is the generated terrain with static trees and rocks that are dropped just above the ground. Some of the rocks roll down the slope and that it's intended. Buy three end, rocks will probably not be instantiated on the higher steepnesses to avoid them from rolling down, but for testing purposes I did not change that yet. Same applies to the ground textures and tree placement. That'll be fine tuned later. 

I need to make some adjustments to the rock generation. I find the rocks to be mostly too big, so I'll find a way to have the variation in size and have some big ones, but not that many. I have some ideas to get that.  

Next, I think I need to lift the terrain up a bit. Right now, most of the time, I have terrains with huge flat parts that turn into lakes. That is because the altitude script checks for a lowest possible level and sets all lower values to that. I think I can make the terrain more interesting by raising it a bit. 

After that, I hope to finally be able to start with the real game play and add characters. Those are going to be the beef of it all. 

Talk about trees

Good morning. I've been quite busy working on Holocene over the last couple of days and I think I'm making progress finally. The procedural terrain generation is not finished yet, but for now I'll leave that there for a while to focus on what I'm actually really trying to do all along, the game.

I made a simple first person controller with a camera and some moving mechanics that I picked from my RPG project of half a year ago. Next I tried to hook it up to the trees and things on the terrain and that it's where it goes wrong first.

The reason for that it's actually pretty simple. Trees on a Unity terrain are not really objects in a way that one can add scripts to them and interact with them individually. At least, I have not been able to find a way to do that. For that reason, I cannot get a vision script to work. With a first person camera, I might be able to have the player look at the terrain as a whole, but that won't help to much, because we're not cutting the terrain to get wood. We're cutting trees.

To fix that, I'm rewriting past of the terrain generation script to allow for tree prefabs to be instantiate as separate objects. We'll have to find out if this approach will make things slow. If it does, I'll look for ways to not render objects that are not in view.

A tree object will have a parent object within a graphical element and one or more colliders. The scripts will be on the parent object or the collider, if there is just one thing. Once the player looks at the object, the GUI will give a message and certain functions will be unlocked.

I tested this a bit with a hand placed tree and that works alight. I'm now working on the generation script to allow for placement of the. The same will apply for rocks and the like, because those will be interacted with too. I think I'll be able to finish the script part today or in the weekend.

Right now, I'm using placeholder meshes to speed up development, but the plan is to replace them with my own creations. That'll take time and effort,but it'll make the game better, I think.

Procedurally generated frustration

Good morning everyone. I'm in the bus to work again. This weekend was pretty rich in game development. I managed to spend quite some time on the procedural terrain generation course that has had my attention for quite a while now. I learned a lot about Perlin noise and midpoint displacement algorithms and about how top make editor scripts in Unity.

Because I don't want the game to be too complex, I'm not implementing erosion for now. For that reason, I decided to just put all the scripts on my game project and get them to work before removing unneeded stuff and tinkering with the other stuff. It seems to work for a part.

This island is procedurally generated by using a midpoint displacement to generate the heights, a water plain at a certain height level and a couple of textures like grass and rock, which seem to blend too much right now. The white line is an animated shore line and the green stuff at the bottom... those are the trees.

Somehow the trees behave differently than they did in the course, so I must have done something wrong. At 11pm yesterday I decided to delete all the procedural code from my game project (only there) and start  from scratch. I am a lot more at ease with scripts with many methods than with scripts with a few large methods, so I'll have an Awake() with just about ten lines and keep it the way I like and the course teacher does not seem to.

My point is... sometimes you spend a lot of time on something without anything to show for it. Whatever I did, at least I learned from it.  I do now get that annoying feeling that I want to start working on the actual game mechanics instead of vital but secondary stuff like the terrain. I hope I'll ferry this thing working this week, because this way it does not feel like a game.

The stone age simulator I'm making

A little update from a crowded bus home this time. When I return, my wife is probably at the gym and I'll have time to watch a couple of videos from my Udemy course on procedural terrain generation. I'm learning a lot about that, but I'd like it to be finished rather soon, because I'm aching to work on Holocene proper.

Some time ago, I wrote Holocene was about to become a different kind of game. Now that I'm not really working on its mechanics, I take my time to think about what I want to make and write it down in my little notepad. I have a couple of ideas in different phases of fleshed out-ness. This blog post its about the main idea that is slowly getting shape.

Holocene is going to be a 3D stone age simulation game where the player needs to guide a tribe of people towards stone age greatness.  There will be a lot of discovering to do, both for me, the developer, and for the game characters, because they don't know much. They know that food and drink might keep them alive, but that might be easier said than done in the game. The task of the player will be to help three characters achieve things.

This premise may sound like a standard RTS, but it'll have a first player outlook and camera position so an overview may be compromised. Next, any character will be someone specific, so we're not dealing with generic workers or warriors.  A guy is a guy and singer fits are better hunters than the guys going for three pottery craft. Others might be better in cooking. That kind of stuff.

There will be low poly mammoths

There's not too much left tip say right now, except that there's a lot of work to do in the coming time. I'm seriously considering making a YouTube development log as soon add i have my course under my belt. Whatever I do though, I'll probably take my time. Don't expect the game to be anywhere near finished any time soon.