Will the flaming thing be my friend?

 For those who don't follow me on Twitter, I am still working on a Stone age game, but I dropped the RTS aspect in favour of a Survival game, which is really what I started with some time ago. The player is a human (with suspiciously long arms which may or may not change with the final models when I get to making them or getting someone else to make them) that still has a lot to learn, like what the hell that grey stone thing that fits in your hand might be used for and if that flaming thing that moves hysterically might or might not want to be friends with you (it does not, but how would you tell)?

The idea is that there'll be a very big procedurally generated world with all kinds of biomes with each their specific things. At the start of the game, this one human appears somewhere and the world says good luck.

I'm planning to make a bigger dev log on what we have right now, but there's a couple of things to pick up and eat and there's really two ways to die right now. What else does one need? Well...

I'm planning to have a crafting and building system, more dangerous things than just these two and generally more things to do. What I hope to achieve is a nice explorer sandbox game where the player can use a couple of simple systems to build an interesting experience. There'll be more options than would make sense (except if you're one of the growing group of people into eating rocks and sticks). I'm looking forward to slowly seeing this one grow. 

The Work Place and the Play Place

Right! That's been a long long time ago and it's 2020, so well, it's 2020. Last time I wrote anything on this blog, that was in February, a couple of weeks before I quit going to the office. In the bus was my time to write my blog posts about my game. Now it's half-November and I haven't seen my colleagues for over half a year now, because I've been working from home from the start of March onward. Now that saves my my bus commute, so there should be more time to work on my game and there is, but it's not been all the productive really. 

First, with working at home, something weird happens. Work is my work en game development, I do that mainly because I like to do that as a hobby. That's nice. because I'll have much more time for that, but there is this thing that I call the Problem of the Work Place and the Play Place (abbreviate it to PWPPP if you like, but it's not mandatory). What I mean here is that the place where I work is exactly the same place where I relax. I'm sitting on the same chair, looking at the same two monitors while I type on the same keyboard and drag the same mouse around. Something is odd about that. 

Vitruvian Man, by Leonardo da Vinci

What I used to do in this long forgotten pre-Covid-age (I'm a historian too, I know about old stuff) is that I went to the office, did the work stuff there, went home, listening to podcasts in the bus and on the bike, had dinner, socialised with my wife and went upstairs to the computer to work on my game or play another game while my wife was watching TV. Now that is completely out of whack and that's weird. Don't get me wrong: this is not by far the most important thing about Covid in our lives, but I want to get it out there, because it does matter in its own little way and I'm positively sure other hobbyist game developers who spend their working time staring at a computer screen can relate.

We're living in a strange time, right now where we get challenges that we're not wired for. It's not the worst thing we can have to face; I'm not in a war situation, but that's not the point. The point just is that things are weird and unreliable and that things often work in different ways than you might expect. Maybe this is also why I'm reaching back to this devlogging again. Not to make it bigger than it is, but it's something I understand. I bought a webcam today and might just try streaming some of my programming, 3D modelling and designing on Twitch or YouTube. I think I got it to work with a game of Age of Empires II which I just played.

Speaking of which, isn't it fun that I got to my highest ELO in months? Crawling out of the pits of despair into the top-40 000 of the world. As long as one loves doing it, right? 

Goal Oriented Action Planning

Good morning everyone. It's been about a month, I've been quiet on the blog.  I got myself a new laptop to work on the game sy the times I'd usually write these posts in the bus. As I'll be going to a concert with my wife after work, I left the laptop at home and here I am!

What have I been up to for the last couple of weeks? It's all mainly been about goal oriented action planning (GOAP) AI for the characters in Holocene. This means that the world is a world of states and tasks, but not really in a state machine way. A character has a simple state machine attached, but all it can do is be idle, go somewhere, and perform an action.

Where to go and what to do is dependent on the goals weer formulate.  For instance, the character is hungry. This gives him a goal: eat. Quite simple. So he eats and he's happy. But what happens when the guy does not have food? Well, he needs to eat,  so how do we make that possible?

Any job a character can have consists of the action (removing the food from the inventory and unticking him being hungry) and an effect (he's not hungry), but also some preconditions  (he had food). The action will only run if the character actually had food. 

The thing with GOAP is that once the goal of eating its picked, the character will try to find a sequence of actions leading to having eaten. Via some A* pathfinding algorithm from a tutorial, which I do not yet fully understand,  the character will find a road from the current situation to one where the preconditions for eating are met. We're picking up the apple over there, and we're not attacking the enemy or making fire or building river dykes. Because those won't lead to eating.

The GOAP system makes for flexibility because all you do it formulate small building blocks for behaviour and a system to build sequences of tasks based on very simple nodes. The thing is always that stuff like this isn't as easy as it seems. For instance, right now I'm having trouble making the character understand when a building he's building is finished. I find it hard to debug this system and the fact I don't really understand the underlying pathfinding does not help, but I know what to study and I'll be ok in the end, because I expect it'll all be so much easier once I get it.

Sequencing the states

Good afternoon. Yes you heard that right. It's even almost evening and I'm in the bus back home from work. I was just thinking about the state machine that I'm running in Holocene and there's a problem.

The problem is not unfixable by any means, but it'll make my job a lot more difficult because I am bound to create a gigantic AI class if I continue what I'm doing now.  Shop what am I doing really? Well, I'm using a state class that has actions defined for entering and exiting the state and for executing whatever the state needs for every frame. All these methods are written in the CharacterAI class.

The idea is that once something is happening, like the character finds out he's hungry, the decision class will look if there's apples to eat and if there are, trigger Moving state with an apple as target. That's all fine and that works, but...

Walking to an apple is not really the same as eating it and moving to any target does not satisfy hunger feelings, so I have to make it more complex. Once the character arrives at the apple, he'll have to interact with it.  Pick it up, maybe prepare it and consume it.  That means we need more information on what to do next. That is going to clog the system quickly.

Now here's my idea: I'm going to use the Unity animator controller and add behaviour scripts to any of the states, keeping them very modular. Moving does just the walking until it's at the destination, picking up just picks things up, eating only destroys the object and sees if that does any good to the character. All these states can me called by a simple trigger that takes a string or an int.

Back in the AI script, all I have to keep track of its a stack of triggers. The states will let the AI know they're finished and the AI will know what to do next. In the eating example, the character will run a "hunger" method and that'll populate a stack with the state for finding it there it's food nearby, plotting the road, going there, picking the food up, seeing if it needs preparing, doing that, eating the food and going back to seeing what to do next.

I'm sure this is easier said than done, but I think this is what I'm going to do.  This way I keep the code separate and unrelated and that often means less bugs and easier to manage.

Agabouga likes apples

Good morning again. I have a little update on the development of what I started to call Holocene again. I'm focusing on the game mechanics and specifically the satisfying of needs by characters. As I might have said before, characters need food, water, sleep, warmth and probably something social.

These five are instances of a Need class. Needs have a current value, a maximum value and some priority stuff. A character will be able to find out which need needs to be fulfilled and find targets for that accordingly.

I have this system working now, but I'm going to refactor that, because I'm not very happy with it and I think we're making too many calculations which will be problematic when we're having more than a couple of characters.

Anyway, afters whatever happens, the character has a state machine component that gets fired to a new state when that gets triggered. The idea is that once the guy is hungry, he'll find a food source and sets that as target to go to. Then the state machine will trigger a state to pick up the source and then eat it. Or bring it somewhere.

What I have now is a system that presets the target for Agabouga to the apple and tells him to go there. The triggering of the move state is not implemented fully, but that will be. By the end we'll have characters being able to find out what they need and if that's available. The state machine will then get a sequence of states going. Move to the apple, pick it up, eat it and find out if we need anything else.

A lot of work left to do, but it's actual mechanics so I like it.

How to be destroyed properly

Good morning and best wishes for 2020. It's been a while but not so much that I'm getting used to typing 2020 on my computer keyboard with ease. I spent the holidays with the family and the rest of the time with my wife and a bit with some courses and experimenting to get better at gamedevving. Now I think I'm back to business.

I have been up to quite a lot in these courses and experimenting lately. The aim is mostly to get more proficient in the RTS mechanics that I need for my game. I'm going to revisit the procedural world generation later, once I have kind of a game going, so I ditched that, because I was not happy about it anyway.

I also took a look at 2D grids and A* navigation, but that gets slow very quickly once the world is getting any bigger. I think I'll just stick with the 3D Navmesh system for now. I'm not sure what other elements to keep.

Now that I started a new clean sheet project, let me tell you what I did yesterday.  You remember this tree:

This is the acacia tree. It's an object of the Tree class and it can do something. It can get destroyed. Every object of the Worldobject family had hit points and once they run out, the object gets destroyed and other stuff happens. What'll happen it's that once the acacia tree is killed, it'll instantiate a list of objects around itself. Were talking logs and branches. The idea is that a felled tree will add resources like that, while trees can also be kept alive to give a little bit of resources every now and then. 

This mechanic is now partly made. I still have to make the instantiating thing and a time system to make "every now and then" mean anything.  Time will probably be one of those main mechanics. There'll be day and night and especially seasons and hence years, because there'll be aging and growing in the game. And winters should be colder than summers, which should make a difference. 

Not sure how to implement that one though, sho we'll have to find out.  For now I'm happy to be working again. 

Football sounds and screen sizes

Good morning.  I've had a couple of days off the project and got going again yesterday. I am going to spend the holidays with the in-laws, so you've not seen there end of the lazy times, but that's not the point. The point is that I'm getting close to finishing the PC  build of my yet unnamed goalkeeper game (going - in a flash of creativity - by the name of: 'Goalkeeper Game' right now).

Yesterday was quite productive.  First, I finished the sound system by hooking a sound handler script to a couple of events like the shooting, the scoring, the game over script and a couple of collisions for the ball. Then I downloaded some sounds to play from a free royalty free site. It's funny that searching for 'football' gives results for a totally different sport and one needs to search for 'soccer' to get football stuff. It's ok. We'll let the Americans have their thing.

Then I asked my wife if she had any ideas for a sound when the ball went in the goal.  I found out quickly that cheering crowds don't work when the ball is shot every two seconds and there's crowd sounds anyway (including 'Als we gaan, dan gaan we met zijn allen de kroegen overvallen hier in het mooie Breda.') So she recorded her own cheer.  Then she played the game and we got to test the high score. It worked and I'm very proud of her. My wife does think her cheer does not suit the moment the player fails, but I'm keeping it in anyway.

Technical stuff now. I made a mistake that I saw last time when I discussed the mobile build. The gloves were not in the middle of the goal to start when the game is played on something else as the screen that I tested it in in Unity. I had to change it to take the screen size into account and I think it works much better now. I'll test it again a bit and after Christmas I'll have a couple of days off from work to make the mobile build and see how I can release them.

After that I'll see what other idea I'll start 2020 with. Maybe some first version of Holocene in 2D and maybe turn based or otherwise simplified. We'll see. If I don't get to writing another blogpost tomorrow, I wish you a happy whatever-you-celebrate these upcoming days!

The small screens of mobile phones

Good morning everyone. Today I won't have time to work on my goalkeeper game, because I'll be at a restaurant to have our annual Christmas dinner with work. I'll be home late. This blogpost will be the only thing I'll do for the game today.

Yesterday I had a little more time, although my favourite team had extra time in the cup, which I was not expecting. And there are farmer protests worth being annoyed about. I'm not so much into alt right climate denier stuff. Anyway, the game.

What I did yesterday was finally get Unity Remote to work on my phone. I have no idea what an SDK, NDK or JDK actually is, but it seems that I needed to click Browse Three times before Unity understood it comes with this trio. I also had to tap the build number on my phone a couple of times. But now it works.

My game is initially made as a PC game with mouse control and Esc and the pause key to access menus, so I know there need to be some changes to the game to make them playable for mobile.

First, the screen is very small, compared to the wide screen of my monitor. This means that, with a screen covering the goal, the gloves are very small and it's very difficult to stop the ball from going in. I'll make the gloves a lot bigger, probably twice as big in any dimension. That'll not take too much time and effort. The same applies to buttons and text in the menus.

Secondly, while the mouse movement is ported to swiping, which I was planning to do anyway, the gloves will be quite far to the right of the finger, making them difficult to control.  I I'll find a way to control that. I guess this will be more difficult. I want the gloves to be right on top of the finger.

Thirdly, there'll be a leader board to track who is best. Games like this can get boring quickly if the core mechanics are under control. A leader board should give it little more longevity.

The work I'll be doing anyway, is the sounds. It does not matter which device is used to play the game. I need sounds. I also need some background sprite to block the view of the Unity blue void. Those will be made soon.  Now of to work. Till next time!

It's a game now!

Good morning everyone. Here's another installment. I notice that while I'm not working on Holocene, the devlogs are further in between. I even found out that I don't have a name for my new goalkeeper game. It does not matter to me really. There may just be less to talk about this game.

Alright, over the last couple of days, what have I been up to? Well, I kind of made the game. The schedule was to have the main mechanics ready by the end of week one, which is last week. This week would be for the GUI and mechanics around new games, pauses and the like. That's what happened. Yesterday was a GUI day. I made this:

I know. It does not look like much but the different texts and buttons are part of four panels that can be turned on and off: the main menu, the pause screen, the game over screen and the game screen.  These panels are shown when needed.

What else am I going to do? First, I'll study ways to build leader boards. The game will laat be ported to Android and iOS and it'll be fun to give the game done longevity by adding the competitive edge. I don't worry the game won't quit after a while, because some of the shots are difficult to stop, especially the high ones.

Next, I'm going to add sounds and probably done background drawing with fans or something else, because a penalty box does not typically float in a space that looks eerily like a Unity scene.  When that's finished, the PC build is ready and focus will shift first to Android and then to iOS. 

Fire the ball!

Good morning. Just a little update on the tiny game that I've stayed making a couple of days ago. My plan is to totally finish the game in a month or less and release it on PC, Android and iOS. Well, what's the plan?

I'm making a simple football goalkeeper game. There's a penalty area with a goal and one of these shooting machines that pump out balls to fire them to the goal. In the goal there's a couple of gloves that try to keep the ball from going in. You're controlling those gloves.

There's a couple of mechanics at work here. First there is the machine, the red and black thing that needs further modeling in Blender later. All it does is have a spawn point for balls right in front of the black nozzle part. The spawn point rotates to make for a random direction within the goal to fire the ball when it has to.

Firing a ball happens 2 seconds after it's been fired before. The spawn point calculates a new rotation and the ball changes location and rotation to that. Then it gets a boost forward.

The third mechanic is the goal. There's an invisible collider just behind the goal line that'll catch the ball when it goes in. Every time something that is a ball hits the thing, the score is increased and so it the force the ball gets next time. A similar thing is there for the gloves, but then the saves count is increased.  It'd be totally random of the saves count increases, because the gloves can't move yet.

Sho what it's the plan for now? First up, I am going to have the gloves move by mouse. By moving the mouse, you'll directly move the gloves to that location as if it were a mouse pointer.  The rotation of the gloves will be so that it'll will always point away from the center of the goal, fingers out, except when the gloves collide with the center of the goal. Then it'll be facing up.

Next week I'll focus on two important things: a game over mechanic with some UI. The game will end once a certain number of goals is scored. I'll have to find out how to do that, but I'd like to have a leader board and a personal record for this. No idea how difficult that'll be, but most important right now it's to have an end to the game. I consider this the minimum viable product.

Next, I need sounds like shooting sounds, bouncing and glove sounds. I'm not going for realism but for fun, so the microphone is ready.  Thirdly, I'll see what I can do remodeling the machine, because it looks like crap right now. I just downloaded Blender 2.8 and it's very different from the version I'm used to, do I need practice anyway. For the game, though, it's not that vital.

In short, tonight I hope to make this into a game that I can let my wife play. I like having my wife test my games, because she's not a gamer and she can be brutally honest at times. I hope she likes it.  Next week will be the finishing of the game. Then I planned two weeks for testing and building it for PC, Android and iOS. That'll be fun.

Small games

Good morning people. It's been a busy week and that's why I have not been able to write a blogpost yet. Yesterday was my wife's birthday and now I'm in the bus again.

Let's just say this up front: I'm putting Holocene on the back burner for a while. This does not mean I'm quitting it. I'll pick it up later. But there's some things I want to fix first.

I have a day job where I'm away from 7am to 7pm every day, so I get to have about two hours of gamedev if I'm not tired, after dinner and before spending time with my wife in front of the television. Regardless of how much I'd want this, I'm not a full time gamedev right now.

Now Holocene it's a big project, a very big project with a lot of stuff that needs to be done and this is where a problem arises. It's kind of my dream project, but after months of hard work, I am not making and gameplay yet. I know, procedural generation, basic UI and navmesh integration are vital. Don't get me wrong, but it feels like I'm not making progress no matter how much effort I'm putting into it.

About a year ago, I started to learn game programming and I thoroughly enjoy it, even the non-gameplay part of it. I'm really glad that I did this. But as long as this is not my profession and I don't get to pay my mortgage doing gamedev, I have to treat it as a hobby that I spend a lot of time doing. 

Returning home tired or semi-frustrated after a long day's work makes you want to do fun things. While my wife is watching the singing contests on the telly, I'm going upstairs to make my game and you know what, I want to make a game.

This means that for a time I will focus on making smaller games that I think I can make in a couple of weeks.  The day before yesterday I started a little football goalkeeper game where you're the keeper who needs to stop shots. Quite easy physics game. I'll make s ball and a goal and a couple of gloves with collision detection and that should be it.

I also have some ideas for a top down shooter and a platformer in a ancient Sumerian theme,  like the Ur Standard in the British Museum.

Another thing I'm considering right now is to have the Holocene project I'm working on be Holocene II. I'm thinking of a Holocene version in 2D it 2.5D, like Civilization. Not sure how that would work, but it's an interesting thought.

Someone on Twitter also put the thought of trying to get a team to build Holocene or a similar game. That's interesting too, but depends on some things. Maybe I'll find a nice group of people that kind of share my view about game making.

But first I'll be making some small games just to make games, finish them and recover. I found out that in 2019 I've been ill for 17 days which is about two weeks more than usual and while gamedev had nothing to do with me getting ill, it'll help me not getting ill.

Ghosts on the navmesh

Good morning. I'm on my way again. The last couple of days I have been working on my characters for Holocene. First, I was building models in Blender, which took a lot of time without being successful really. Especially weight painting is terrible, when you try to keep things low poly. Shoulders are terrible to get right. After some days of trying, I decided to halt the character modeling for a while and use my proven primitive shape model in Unity.

Now that I decided that, I set that up. I have my tiles with a navmesh surface component to them, so the agents know where they can go. When I drop my guy on though, it does not really catch it. I think that is because the navmesh is above the surface somehow, making it difficult to work with. By changing the agent's offset and applying that to the prefab, I get this unsatisfactory result when I send the agent to the player position.

Note that this is not a ghost game. Floating characters are not what I need. I went to bed frustrated yesterday because all I really want is to have the navmesh right on the surface and have the agents just attach. 

While I'm writing this blogpost,  someone on Twitter just suggested I create a navmesh myself and that is certainly a thought I'd entertained for a while. It'd instantly fix the surface thing, I just don't know how to get any decent path finding to work then. Possibly with waypoints al over the surface if that does not take too much resources.

The Twitter guy said he'd send me his scripts so I'll wait for that. I really hope it helps me set up a good system without Unity's navmesh system which is giving me trouble every step of the way. I'm really looking forward to creating the actual game mechanics, so I'm hope to get the necessary technicalities over with. If this all works out, I found myself a new hero!

Plans plans plans

Good morning. It's Monday again and there weekend where I planned to make some progress in my game is over. What happened?

Well, Unity's been asking me to install their newest update for a couple of days, so before breakfast on Saturday, I decided to do so. I found out there is a thing in this version that I could use, so let's go for it. When I returned, there was an error message because Unity was not able to remove something. I didn't think much of it, so I just ran Unity and found out it could not start. I rebooted, same problem. 

After a bit of googling and asking around on Twitter, I found that Unity needed to be reinstalled in another folder, so I did and that worked well. That was similar lunch time.  I hooked up the scripts that I had and loaded the models that I made. Then I went for a sandwich. 

By the end of the afternoon (!) I finally got everything to work. My procedural generation requires a lot of parameters to be set in the inspector and I apparently forgot one of them that made the entire world have a "very wet" moisture rate which gave me a rainforesty world with no desserts, tundra, savanna and the like. It took so much time to find out what caused this and fix that. 

Later, I also found out I forgot to set the ground to a certain layer so that trees could find a good place to set their y-coordinate and not float over or sink into the ground.  Anyway, that was done by the end if the day. I did not feel like working on the game so I called it a day. 

Sunday, I decided to work on another tree model because I did not have a tree for the savanna region yet. Now that I found a nice trick  in Blender to make trees more easily, it did not take too long to make a nice Acacia tree. 

I'm pretty pleased with how much these tree models improve over a short period of time. I know that I'll make some more and remake some of my earlier ones and I'm happy that that should not be much of a problem. 

I also continued with the humanoid model that I've been working on lately.  I tried to rig and animate it in Mixamo but I couldn't get it to work correctly, so I decided to rig it manually in Blender. When I went to bed, this is what I had. 

It's getting near a complete rig and then I will have to add weights to different places to make sure the guy does not move weirdly in the check or the neck when lifting the arm. Last, I'll make four animations: an idle one, a walking one, one for picking up objects and one for dropping objects. Maybe I'll also make a working one at this point. Maybe later. 

Anyway, I had a lot of plans for the weekend, but most of it got into recovering what I already had, which is annoying. Yesterday evening I found out I could open my old project too all of a sudden. I could now take some of the procedural level generation parameters if I need to, do I'll not delete it yet. I also set up a source control for my project. 

Note I'm off to work. Hopefully I can get the rigging of my humanoid finished tonight. Then I can get to work getting the guys to life. 

Slowly back to health

Alright, that took way too long. I caught a nasty illness two weeks ago and while I'm still not 100% fine, I'm on my way to work again.

I have tried to put some time in the game while I had my well feeling moments, usually in the evenings. I did not make very much progress, but some things are starting to look more interesting as I switched focus from the tedious procedural world generation to actual gameplay. What did I do?

First and most importantly, I created a player object that could walk around in the 3D world. It can still walk on water and run straight through most trees and it can drop off the edges of the world, so there's stuff to do left, but it's good enough for now.  The player will directly interact with your tribesmen and objects in the world, but he can't really do much do something.

That's what the characters will be for. Later this week, I'll start try 873 making a character model in Blender and hook it to a character script that'll control its behaviour.  I had some training with Blender so that note theres a huge difference in looks of different tree types which I will have to get back to later. 

That's progress, isn't it? The bottom tree it's kind of the style I'm looking for. Low poly but kind of appealing. 

The player object can now walk around in the world and 'see' the different kinds of trees.  They are named in the UI and when the player gets close enough and presses E, some other non-functional UI fires to tell we're interacting with the thing. That'll be built upon later too.

For now, that's kind of it. I'm finishing this blog now. Hopefully my first day back at the office won't break me down again, because I learned to appreciate health actually. Wish me luck!

Beyond the waves of the sea

Good morning again. Yesterday was one of those days where I did make a little progress building the world, but most of the effort went in conceptual improvements. Not do much actual code. 

Firstly, what did I make? Well, this.

What you're looking at is the beginnings of some ragged mountain range. For testing purposes, I have these coloured textures that indicate height on the level. Brown posts are the higher regions. In the brown part, there's a bunch of spikes popping up. These are random points that I rose to a level where they're easy to see. They are going to be the basis for more ragged mountains. Those are the peaks.  I'll write more about that once it gets under way.

Secondly, the ideas. I found out a problem in my wrapping system. When the left tile its not nearly the same height as three rightmost one, there is a lot of space to cover to make the right one connect. This can give weird results:

The leftmost tile is a sea tile and this tile on the picture is highlands. To connect, the needs to be a steep drop which does not look right. For that reason, I'm changing the wrapping system. If you look away the world map (of earth) there's two points pg interest here: the sea East of Iceland and the Bering Straight between Siberia and Alaska. From there, there's a pretty simple line of ocean going from the north pole to the south pole.

What I'm going to do is stimulate something like that. The world I'm generating will be surrounded by low regions on the east and west side. That'll be oceans. I think this will fix the problem described above without making it look unnatural. I might even put water around there poles to, but probably with extra generated land masses or ice sheets. Have not decided yet.

I do know how to make the surrounding ocean. That'll be by mixing the height map with a noise that has low values around the edges and high ones in the center. I'm not sure about the algorithm yes, but it should be feasible and I've seen this before. I'll probably make that first because it's not very difficult.

I'm also going off for a long weekend from Friday to Monday, so there probably won't be much work then.  Maybe a blog when I have one of these Eureka moments, but don't count on it. You'll never know, but the laptop stays home,  except if you're a thief. I'm taking my laptop (which I always refer to as"slow" and "crappy") totally with me.

The world is round

Good morning again. Weekend's over so I'm in the bus to work again. This weekend was quite busy, but I did have some time to work on Holocene. As may buy now be known, we're procedurally generating the world and for three nth time I restarted the project to set it up better and now I finally get the idea I start to understand how it's supposed to be structured. So even if it seems like I'm not making progress, I do.

First, I've been thinking about the structure of the world building script and the order of operations.  We'll start with the broad outline of the world that we'll have.  I use small plane objects to set it up. This broad outline right now had one simple Perlin noise, but it'll probably have four. My aim will be to have big low regions that'll be the oceans and big higher regions that'll be the continents. These continents will have features of their own.

Once this is done, I'll see if I need more pronounced mountains. If I do, let there be mountains. I think I'll use mid point displacement to generate them.  When that's done, I'll focus on the rivers again. The aim will be to erode the mountainside so that there will be room to drop rivers there.

Maybe unclear when I write it like this, but there point is that I want to have a playing field where I can drop a river on a mountain and it'll naturally find its way to the sea. Last time I tried that, rivers would get stuck in dips along the mountainside. Now I'll try to carve a path so that the dips have an exit.

When I finish the rivers, I'll add a heat map and a moisture map and that'll bring biomes. Any biome had certain vegetation types and animals. When I drop them in, this should be it.

Right. That's the end aim. Right now I have this. This it's a 4 by 4 grid of tiles with a Perlin noise on the 3 left columns and a special row to the right. This row is a special kind of Perlin noise, because it mixes two. It connects to the one top the left, but it also connects to the left most to its right, in other words: the world is round. I decided not to do this to the top tiles, so it'll be a cylindrical world, rather than a round one, but I'm pretty pleased with this. You have no idea how long this took.

Anyway,  i think I'm starting right. Next task will be to make the work larger and more natural by adding more Perlin waves. Hopefully that connecting time column will look better by then. We'll see Howe long this all will take. I also have a job and a wife and I know this is all going to be a big task, but it's begun!

Still grinding

Good morning. Yesterday I found out that I still don't have what it takes to pull off a good procedural world generation. That's ok, because I can still learn and I already started following yet another massively large course on it. The idea is that in time all puzzle pieces will come together and I get a system that actually works and gets us a good and believable world. In the end, the world is one of the main elements for Holocene. I need it to be good. No concessions allowed.

I told you rivers don't flow the way I like. I think that is mainly because of the noise I'm using for the landscape. There are hills around where rivers can form. At first, I tried having them just spawn somewhere and then flow to the lowest neighbouring area until it hits the sea. Well, that meant that rivers went to a low point and start going around a bit until it surrounded itself and had nowhere to go.

Well, that's ok if that happens sometimes, but certainly not if it happens to 90% of all rivers. Now how can I fix that? I think that's a difficult question, because it's hard to see such a thing coming without making huge analyses.  A river should in principle look for the low point and go there and it's good if it goes meandering down a bit, but at some point the river makes a sort of U-turn and closes in on itself. That often spells misery.

What I think I should be doing scares me a bit, because I think I need to procedurally create river beddings and leech the water flow in afterwards. It would give me power to force a way to the sea.  I still need to have it find a way to avoid the weird u-turns, but maybe it works. What I really need is a way to make sure that from any point on the map, water regions are mostly reachable by only going down. Again, it's ok if it is not 100%, but over half the rivers should flow to the sea or a lake. That's what I'm going for.

The river just stops somewhere

Good morning everyone. I'm in the bus to work again.  This weekend was quite productive while in the end, I only got a little progress. The problem was that my game totally broke and I hadn't made the effort to back it up yet, which was stupid. On the other hand, there were things not working correctly which I were trying to fix and which I could not, so it's ok. I'm not beyond that point anyway.

I'm still working on the procedural level generation for Holocene and I'm using a Zenva Academy course to guide it. I'm not just following it, but have it guide my progress and do the refactoring that it's screaming about while I'm writing the code. Instead of linking noise generation scripts without attributes to every single object, I'm using static ones for that kind of purpose, because a larger level might turn a slow and laggy level if I'm not careful.

Right now, I have a grid of tiles which in turn are grids of vertices and blocks. Any vertex had a height and that stands for the height of a given place in the world. It also had a heat and moisture value which make for a biome value together. Right now, any biome can have one kind of tree. I'm going to change that later. There's no reason why tropical rainforest can only have one kind of tree. 

Last thing I added was rivers. While I was following the course, I kind of knew this was not going to work correctly:

The river gets a random origin point somewhere above a certain height threshold. On the right on there picture. Then, for every step of the way, it finds its lowest neighbouring vertex and goes there until it reaches the sea. Here is the problem. The way to the sea is hardly ever a simple downhill path. There are bumps on the way.  It the real world, rivers overcome those bumps over time, but here they don't. This makes that the river will just stop in a valley, zig zag around a bit and look weird like in the picture.

Seeing this thing is easy, but I have not yet come up with a solution. It seems like there needs to be more planning, although that feels counterintuitive. The origin is fine, I think and the first downhill part is too, but then we need to make sure to keep some longevity. We need to make sure the river does not stop in a valley (or it should form a lake) and we need to make sure the river flies not surround itself.

I'm thinking of a system that had the rivet have a general direction to go, to a shore somewhere. I'm not sure how to make sure it does not have to be a straight line, but I'll manage. The other thing I'll probably do is have the river have a force to be able to lower vertices around it. When the river has gone down, it should be able to dash through small uphill sections by lowering that section.

I'm thinking about this some more. Hopefully, I'll have a good solution soon.

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.