Implementing the Workforce! (Weeks 7&8)

Nov 13 – Nov 26

Not much happened in the first week of this phase, but the second week had been my most productive at that point! I properly implemented subject hunger and death. I improved the serf behaviour a lot and implemented the Harvester and Crafter type subjects and behaviour, specifically the Lumberjack and Carpenter. I also attempted to use source control for the project…

Productivity Rollercoaster

Working on a project alone meant there was NO ONE to pressure me, and tell me I should work more, besides myself (and maybe my girlfriend). That’s kind of an issue if you’re bad at self control, but so far I had been doing well motivating myself. However in week 7 I didn’t do so well. The first day of the week I spent almost eight hours on the Game Jam Game. That was great, but not helping Warriors and Serfs.  I spent 6 hours during the next two days working on the game, and a lot more time trying to use git for the project… (see below). Besides that, I had 4 days of no work at all on the Project, on one day I moved office, another was spent on Tatjana’s great Blender tutorial, and on two days I simply didn’t manage to motivate myself. But during the second week I put in more work than I ever did before (besides crunch week before final presentations). So I guess it kind of balanced out?

Source Control in Unreal sucks!?

I didn’t know if I was just being incapable or if unreal didn’t like git, but either way, I eventually gave up on source control for now. I tried to implement source control (with git) 3 times and probably spent about 8 hours wrestling with it. After the Game Jam last week, where I finally used Git for the first time, I decided it was time to use it for Warriors and Serfs. The first two times I tried to do it the way we had done it with the Unity Project, which was creating a repository with Gitlab and selecting the project folder as the local folder for it. But it didn’t seem to work that way with Unreal… I staged, committed and pushed the project which in total probably took around 3 hours each time. Then I tried to pull it on my laptop to test it, and nothing worked as it should, and I hadn’t a clue why.
Then I decided to do the smart thing: I googled.

sourceControl buttonIt turned out that the smart people at Epic made a smart little button that dealt with the entire source control thing automagically. So I used that instead, and it all seemed to work! Besides the fact that renaming files created duplicates. And that I couldn’t properly delete those duplicates. And that I had name collisions because of it, and confusion because of duplicate names with different content. And because I sometimes had to commit changes just to be able to test something, which resulted in the commit descriptions looking like this:

commit descriptions

So in the end I just turned off source control, and it saved me a lot of time and stress.

So what did I do?

So with half a week of stress and nothing, what did I even manage to accomplish during the second week?
Well I’m glad you asked!

Harvesters and Crafters

First of all, I implemented Lumberjacks, the first harvester subject, who planted trees around their houses, and cut them down, and turned them into logs. That meant I did not only need to implement the subject and all their behaviour, but also the trees (which are an “Interactable Environment”) and the building they were working in. Buildings could now have staffed subjects, and House-based subjects now had a home building in return.
enumsI made a whole bunch of Enums for subject types, lot types, building types, interactable environment types and job statuses. Also I extended the Items enum. Oh yeah, and I made a function for each of those, that returned a player-side “name” for them, so I could tell the player what they were looking at.


I made a new “harvesting” component which I stuck on a blueprint deriving from Building. The harvester subject did most of the work though. It “decided” to find a new home, selected a job to do, etc. To be in line with that, I modified the crafting building too. Before, the building would start the crafting process whenever the materials were there, and complete by itself. Afterwards the crafter subject -eg the carpenter- decided it was time to work, checked whether resources were available, and started the job, and completed it after some time. For the player this didn’t really make any difference, but it would make the code a lot clearer and probably more maintainable.

Apropos clean…

Behaviour Tree cleanup

I completely changed the way I did behaviour trees.
The first thing was that I split up decisions and executions. Originally the execution of a behaviour would follow directly after the decision was made to execute it.

original eat behaviour
Original eat behaviour: The first node was a condition check, if hunger was below 20%, it returned true. The second node found the nearest Inn, and set the moveLocation. The third executed the movement. (note that actually eating at the Inn had not been implemented)
eat decision
Improved Behaviour: Eat Decision. The decision only used the first two nodes of the original, and the “FindFood” Node was renamed to what it actually did. I also replaced the condition check BTTask with a BTDecorator! (also note the color coding)
eat execution
Improved Behaviour: Eat execution. As this is part of the tree was checked before the decisions half of the tree, it checked whether the decision to go eat was made before. It then found the nearest Inn again, moved to it, and then ate at the Inn when it was reached.

The original reason why I split up these behaviours, was that Serfs would break out of their item delivery behaviour when they blocked each other’s path, and they wouldn’t find back into it. Then I realised that doing this would probably work better with savegames, so I changed the remaining behaviours to split up like this too. I added color coding, so I could quickly find the corresponding decision / execution parts of the tree.

I replaced the condition check task nodes with decorators mostly because that was the right way to do it, but originally because I wanted to invert the success of a node, and since that didn’t work with Tasks, I had to use decorators instead.
This made the behaviour trees a lot smaller, and more legible.

Apropos Trees…


The reason why I had crafters and harvesters and their respective buildings, was that they behaved very differently. Crafters only ever left their homes to go eat. They worked in their homes to refine raw materials. Harvesters on the other hand needed to leave their house on a regular basis, to harvest materials from the world. This could be stone for a mason, or in the case of lumberjacks, trees. These trees also needed to be planted first, and perhaps tended to until they were fully grown. After the lumberjack had cut down a tree, they needed to refine it in their home, until they were ready to be picked up by Serfs.


These trees were derived from the InteractableEnvironment class, which grew the trees, marked them as harvestable etc. The tree class itself only had the model and its type set as “Tree”, but no specific behaviour, so implementing different harvestables like grapes, wheat, fish and stone would not take a lot of additional time. The same was true for additional crafter and harvester subjects.

Game Screenshot

gamescreenshot11.27State of the game on November 26th. You can see a whole bunch of Woodcutters’ buildings on the right, with a yet light forest the lumberjacks are growing. On the bottom right you can see I had tested out some different floor materials…
On the bottom left you can see I added debug buttons to spawn each of the three implemented subject types, so now you could populate the area with a lot of people. I also increased the size of game plane, as the Lumberjacks needed some extra space.

Current Build: DOWNLOAD

Leave a Reply

Your email address will not be published.