Sequencing the states

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

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

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

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

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

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

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

Agabouga likes apples

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

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

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

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

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

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

How to be destroyed properly

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

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

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

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

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

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

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

Football sounds and screen sizes

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

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

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

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

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

The small screens of mobile phones

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

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

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

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

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

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

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

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

It's a game now!

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

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

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

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

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

Fire the ball!

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

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

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

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

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

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

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

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

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