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!
Sunday, 22 December 2019
Wednesday, 18 December 2019
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!
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!
Monday, 16 December 2019
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.
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.
Wednesday, 11 December 2019
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.
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.
Sunday, 8 December 2019
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.
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.
Wednesday, 4 December 2019
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.
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!
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!
Sunday, 1 December 2019
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.
Wednesday, 27 November 2019
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.
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!
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!
Tuesday, 12 November 2019
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.
Sunday, 10 November 2019
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!
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!
Tuesday, 5 November 2019
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.
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.
Sunday, 3 November 2019
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.
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.
Wednesday, 30 October 2019
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.
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.
Monday, 28 October 2019
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.
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.
Wednesday, 23 October 2019
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.
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.
Tuesday, 22 October 2019
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.
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.
Monday, 21 October 2019
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.
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.
Tuesday, 15 October 2019
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.
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.
Sunday, 13 October 2019
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 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.
Wednesday, 9 October 2019
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.
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.
Sunday, 6 October 2019
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.
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.
Thursday, 3 October 2019
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'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.
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.
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.
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!
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.
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.
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:
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.
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.
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.
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.
Saturday, 31 August 2019
A little big thing
So, good afternoon. No development today, or at least not until the evening. I do have things to talk about though, as I have been busy working on the movement mechanics in Holocene and there are some problems.
When a unit is selected and the player right clicks somewhere, the unit should go there and that works for parts on the terrain where nothing already is. When there is a unit, it works too and the game knows where to stop to prevent two units to fight for the position to stand on.
The problem is when the unit wants to move to a stationary object like a resource or a building. The navmesh understands that the unit cannot just go there, so we'll have to find a place where it can go. Unity has these methods to find out the edge of a collider and places on the navmesh, but they do not yet give me what I need. When I send a unit to an object, it just stands next to the object on one place, no matter which is closest.
I'm not sure how the game decides that specific spot, but it's not what I want. That is because it does not decide which place is closest to the unit. I was hoping the methode for finding the edge of a collider would fix that, but they don't. I'm confident I will find a way, but I have not yet.
This is one of those "little big points". You might expect it to be a small minor thing to find the point where to go, but after a couple of days, you realise, maybe not so much...
When a unit is selected and the player right clicks somewhere, the unit should go there and that works for parts on the terrain where nothing already is. When there is a unit, it works too and the game knows where to stop to prevent two units to fight for the position to stand on.
The problem is when the unit wants to move to a stationary object like a resource or a building. The navmesh understands that the unit cannot just go there, so we'll have to find a place where it can go. Unity has these methods to find out the edge of a collider and places on the navmesh, but they do not yet give me what I need. When I send a unit to an object, it just stands next to the object on one place, no matter which is closest.
I'm not sure how the game decides that specific spot, but it's not what I want. That is because it does not decide which place is closest to the unit. I was hoping the methode for finding the edge of a collider would fix that, but they don't. I'm confident I will find a way, but I have not yet.
This is one of those "little big points". You might expect it to be a small minor thing to find the point where to go, but after a couple of days, you realise, maybe not so much...
Wednesday, 28 August 2019
Worker is too lazy
Good morning CET. An update on what I've been doing yesterday. I told you there was going to be 3D modelling for the gathering mechanics. We have the rock and the worker that is supposed to mine the rock. We also have the mining mechanics, but once the worker has enough stuff, there's nowhere to go to to deliver it. So insert s simple 3D hut that I made in Blender.
Well, no. That was because there was something wrong with the rock. Somehow I had that specific one yield gold instead of stone. And the hut only accepted stone, so the worker's not going anywhere. Well, fixed that. Still not going. This means there must be something wrong with the AI state picking thing and it is. The worker finishes mining, switches to walking as it's supposed to. Then it goes idle.
Being lazy myself, I get that. Sometimes you just go idle, but not this time. We're talking algorithms and they are supposed to do what I tell them to do. It hurts to say, but I guess I could have made a bug then. Let's fix that. Next!
Monday, 26 August 2019
Transitions are important
Working with and getting used to Unitys Animator, I find that the beef of these state machines is in the transitions between the states. Different states have the agent do different things, but the main thing is to get the agent to go to a specific state when you want it to.
I'm working on the gather mechanics for workers. I put a little rock from Blender in my scene, added a resource script and focussed on the interaction between worker and rock (and explaining to a friend that not all interaction is sexual).
In short, you right click on the rock and the worker will move towards it. When it's there, it'll make a difference if the agent really is a worker and not, say, a catapult. Catapults can't gather resources in Holocene. Workers can. I managed that by adding a task enum to the unit script. That enum contains certain things that only certain units can do, like gather. The worker script will override the unit script for moving to a resource, adding the gather task. Now that is used to trigger gathering. Guys without the task will go idle on arrival. Others will go to the gather state.
Then gathering happens. The worker will get resources over time and the rock will loose some. Then we need to decide what to do next. When the rock is 'empty' or the worker can't hold any more resources, we need to drop it to a building.
I've not finished this yet, but I will save the resource object and location in a separate variable and find a suitable drop off point and object to go there, setting the task to return. The walking behaviour takes the worker to the drop off point and triggers the dropping. Next the resource will be the target again and the worker returns to gathering. When the wotker does not have any resources and the rock is empty too, he's finished and will look for another rock to carve.
This should be the gathering AI. It took my some time to think up, especially since I need to get used to the triggers in animators. I am at a point though where I think I know what to do next.
This is one of those things I love about making games. There's little victories around every corner, much more than in my day job. That's very motivating.
I'm working on the gather mechanics for workers. I put a little rock from Blender in my scene, added a resource script and focussed on the interaction between worker and rock (and explaining to a friend that not all interaction is sexual).
In short, you right click on the rock and the worker will move towards it. When it's there, it'll make a difference if the agent really is a worker and not, say, a catapult. Catapults can't gather resources in Holocene. Workers can. I managed that by adding a task enum to the unit script. That enum contains certain things that only certain units can do, like gather. The worker script will override the unit script for moving to a resource, adding the gather task. Now that is used to trigger gathering. Guys without the task will go idle on arrival. Others will go to the gather state.
Then gathering happens. The worker will get resources over time and the rock will loose some. Then we need to decide what to do next. When the rock is 'empty' or the worker can't hold any more resources, we need to drop it to a building.
I've not finished this yet, but I will save the resource object and location in a separate variable and find a suitable drop off point and object to go there, setting the task to return. The walking behaviour takes the worker to the drop off point and triggers the dropping. Next the resource will be the target again and the worker returns to gathering. When the wotker does not have any resources and the rock is empty too, he's finished and will look for another rock to carve.
This should be the gathering AI. It took my some time to think up, especially since I need to get used to the triggers in animators. I am at a point though where I think I know what to do next.
This is one of those things I love about making games. There's little victories around every corner, much more than in my day job. That's very motivating.
Sunday, 25 August 2019
Fighting for position
Ok. Weekend is over again. I have not been able to get too much work done in Holocene this weekend as I had other things to do (and yesterday night I wasted my time watching The Marathon Man).
What I did do is making a start with moving units. For that, I made another of these primitive shapes based Workers. A capsule for the body, spheres for head and red nose to know which way he's facing and an elongated cube for arms. And a worker script and some needed Unity components.
First thing I set out to do is to implement the walking behaviour that I made for goats. When the unit is selected and the player rightclicks on the ground somewhere, the unit is going there. Quite easy.
When clicking on a friendly unit, the unit should go there and stop right next to it. Well, that gave us this little gif that I shared on Twitter:
What I did do is making a start with moving units. For that, I made another of these primitive shapes based Workers. A capsule for the body, spheres for head and red nose to know which way he's facing and an elongated cube for arms. And a worker script and some needed Unity components.
First thing I set out to do is to implement the walking behaviour that I made for goats. When the unit is selected and the player rightclicks on the ground somewhere, the unit is going there. Quite easy.
When clicking on a friendly unit, the unit should go there and stop right next to it. Well, that gave us this little gif that I shared on Twitter:
Now what happens there? Note that I have not yet implemented any fighting mechanics. These workers are not fighting per se, but yet they actually are. The thing is, the moving one is trying to stand on the spot where the stationary one is already standing. Because two entities can't occupy the same position, there's squeezing going on.
This was actually quite easy to fix. The worker script knows what object it's going to and that object knows its size. All we need to do is tell the walking behaviour script what the size of both objects is. Add them up and we have the stopping distance.
This is actually really all I pulled off this weekend. Hopefully I have more time for my game this week.
Thursday, 22 August 2019
Setting up the interaction
Ok, another update. Yesterday, I wrote about a little issue in the WalkAround state of goats. Well, it somehow took the best part of the evening to fix that. Somehow the trigger for starting to move kept getting hit before the position was picked, having to goat literally go nowhere. Well, done now.
The more interesting thing to talk about is a little groundwork for giving orders. I already had a system to find objects when given a location. I upgraded that with a class of references to everything you need to interact with an object. In the end, orders will all be "interact with this object over there" and the kind of object is central to know what "interact" really means.
When I right click on an object, selected objects will run a method on a base Worldobject class to decide which virtual void to run, with some basic general stuff and possibly overriding methods in a derived class.
Sorry if this is technical. It means that I define basic behaviours for interacting with objects of a certain kind that should apply to anyone. When a certain agent has its own behaviour for some interaction, I'll program that and run that instead. This is how I understand object inheritance in C#.
Well, all I ended up with visually is that Holocene looks exactly like it did the day before yesterday, so I won't bother you with screenshots or the like, but now it should be set up to do things I did not program yet. I like to have it flexible, because I know it is getting more complex quickly now.
The more interesting thing to talk about is a little groundwork for giving orders. I already had a system to find objects when given a location. I upgraded that with a class of references to everything you need to interact with an object. In the end, orders will all be "interact with this object over there" and the kind of object is central to know what "interact" really means.
When I right click on an object, selected objects will run a method on a base Worldobject class to decide which virtual void to run, with some basic general stuff and possibly overriding methods in a derived class.
Sorry if this is technical. It means that I define basic behaviours for interacting with objects of a certain kind that should apply to anyone. When a certain agent has its own behaviour for some interaction, I'll program that and run that instead. This is how I understand object inheritance in C#.
Well, all I ended up with visually is that Holocene looks exactly like it did the day before yesterday, so I won't bother you with screenshots or the like, but now it should be set up to do things I did not program yet. I like to have it flexible, because I know it is getting more complex quickly now.
Wednesday, 21 August 2019
To our goat overlords
So I opened Pandoras jar. Yesterday was quite productive and I am pretty pleased with it. I started working on a new AI system, based on Unitys animator component and the theory I found at the likes of Tommy Thompson who has a compulsory YouTube channel on AI in games. It took a little rewriting, but it looks really workable. Someone on Twitter already greeted our new AI goat overlords when I shared this one.
This one is as complex as it looks really. A goat enters the game in a WalkAround state where after a time a trigger "arrived" is hit. When that happens, the goat will go to the NextTarget state. It then immediately returns to WalkAround. If, after some time, a trigger "died" is hit, the state will transition to Dead.
Now that I'm typing this, I see a flaw. It works, but only for randomly walking around. That is because I use the behaviour scripts for this state machine. NextTarget does not actually anything but having the WalkAround state restart. Picking the destination for walking is done in WalkAround, making it useless for any agent that does not walk around randomly.
What I'm going to do tonight is move that destination deciding thing to NextTarget and rename both states to be used for other agents. The Walk state will deal with a destination in the Unit object and walk there. When it arrives, the next state will decide where to go next or what to do next. A worker might want to collect food after moving to the bushes, a goat will go somewhere else. Both could use the Walk state for walking. The difference is in the transition after that.
Anyway... I also did a little thing to trigger the "died" thing. For that, I added health to objects. When health gets to zero or below, it hits the "died" trigger. Objects then change to other objects. For instance, when a tree dies of cutting, it turns into a horizontal thing that gives wood supplies. It gets different attributes by dying. Technically it's become a different object, but ssssht, don't tell anyone.
Next steps will be to first fix the issue with the states, to add a healthbar and damaging mechanism to test the death thing and then to start Worker AI. With AI here I mean the intelligence to perform orders like "go there" and "harvest that". Giving the orders by enemy players is for much later. I call that Player AI and I did not give that much thought yet. Did I forget to mention anything? Probably, but the bus hits the "arrived" trigger, so I sign out for now.
Monday, 19 August 2019
Big goats unite!
Ok, that went more easily than expected. Yesterday, I had a couple of hours to work on the selection system for Holocene and I think I finished it, which is nice.
I made a script to handle selecting and deselecting objects for the player and made some changes to the script handling input from the mouse. As I said yesterday, the script keeps track of what object is under the mouse cursor. When the user clicks, the following things can happen:
- You click on an object. It gets selected.
- You hold shift and click on an object. It gets added to a list of selected objects. The selection script always knows what kind of objects are selected and uses that information to decide whether the clicked object will be the only object to be selected or the other selection remains. Only units you own can be multi-selected. If the current selection contains other kinds of objects (e.g. buildings or enemy units), or the object to be selected is another kind of unit, the selection is cleared and that one object is selected.
- You click somewhere on the ground and drag a box on the screen. All owned units in the box are selected.
That's it, actually. Because I don't have any GUI yet, I used the inspector to test it and it seems to work fine. In the little gif below, the big goats are owned by the player. The small ones are enemies. I try all the ways to select them. It works.
Next up will be making basic moving units. Select 'm and right click on the ground to have them move there. The goats are not supposed to be controlled. They move around on their own.