Will the flaming thing be my friend?

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

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

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

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

The Work Place and the Play Place

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

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

Vitruvian Man, by Leonardo da Vinci

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

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

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

Goal Oriented Action Planning

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

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

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

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

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

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

Sequencing the states

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

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

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

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

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

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

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

Agabouga likes apples

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

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

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

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

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

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

How to be destroyed properly

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

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

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

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

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

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

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