Mar 4, 2024

Making Waves #2: Building the crew of Sagres (pt.1)

Sagres - KG_Matt

⛵️ Hello again Navigators! ⛵️

As you might have seen in our last development post (here), making Sagres was all about conveying a sense of connection. To do this the game needed a cast of characters who are fun to travel alongside and who can help bring this theme to the fore.

Let’s take a closer look (with insight from developer ooze - thanks ooze!) at the cast of Sagres!

***

Lucia & Fernando

As protagonist Fernando, the first other character you really get to know in the story is Lucia, his spritely childhood friend.

“Lucia and Fernando’s connection is really built-in from the very start of the game,” says ooze.

“That said, before settling on Fernando as the protagonist, Lucia was originally intended to be the main character. Ultimately I felt there was a huge benefit to having the main character act as a vessel for the player, to enable better immersion in the story. This is why he is designed with his hair covering his eyes.”

Antonio

The legendary explorer Sir Antonio (Lucia’s father) provides the story with some initial urgency, given that he has mysteriously disappeared and it’s up to you to find out what happened to him.

“Antonio is my favourite character,” says ooze. “He clearly has two ‘faces’, the kind side he shows to his daughter, Lucia, and the stricter side he shows when facing wider society.

He understands the importance of discipline, and it often feels like he should be the protagonist of his own game, as he sets out on seemingly impossible adventures. I wanted his arc to show that even if you don’t achieve your aims then that doesn’t mean you can’t gain something important by trying.”

***

We hope that was interesting! Next time we’ll look more closely at some more characters, namely Amelia, Chama and Nicolau.

Thank you for reading, and until next time: Fair winds and following seas! 🌊

Ooze and Kakehashi Games

Mar 4, 2024

Big Update 0.1.3.05

Magisterium: Fantasy Craft - thespitefulgames

Greetings and salutation, adventurers!

We didn’t publish any new updates for a long time, because we have been working very hard on the game and had to revamp some functions over again. From now onwards, we are going to re-work some systems of the game to improve it.

Warning!

When loading your old saves bugs may occur in the form of incorrect display of flora (trees, brushes, plants). It is highly recommended to create a new game.

You asked for it and we are happy to present you some furniture and some knickknacks to furnish your house comfortably.

Here is a list of new blueprints we have added into the game:

1. Simple round chair (buy a blueprint from Eugene)
2. Simple rectangular chair (buy a blueprint from Eugene)
3. Round stool (buy a blueprint from Eugene)
4. Small bench (buy a blueprint from Eugene)
5. Rectangular dinner table (buy a blueprint from Eugene)
6. Round dinner table (buy a blueprint from Eugene)
7. Cabinet (buy a blueprint from Eugene)
8. Bookshelf (buy a blueprint from Eugene)
9. Simple bed (buy a blueprint from Eugene)
10. Simple mattress (buy a blueprint from Gloria)
11. Wooden chandelier (buy a blueprint from Eugene)
12. Iron chandelier (buy a blueprint from Fred)
13. Tall brazier (buy a blueprint from Fred)
14. Small brazier (buy a blueprint from Fred)
15. Deer horn trophy (buy a blueprint from Eugene)
16. Fireplace (buy a blueprint from Fred)
17. Target (buy a blueprint from Eugene)
18. Town’s dark aketon (buy a blueprint from Gloria)
19. Town’s dark breeches (buy a blueprint from Gloria)
20. Town’s dark shoes (buy a blueprint from Gloria)

Here is a list of things we have added into the game, changed or fixed:

• Do you remember those spruces of all sizes around the map? On the whole map of the game, we have substituted these old spruces with the new ones of better quality that look nice and natural.

• A new item is added into the game: deer horn – you can gather it from a deer.
• Autosave has been added into the game, now you can adjust the time of your autosave press ESC button go to Settings and choose the time of Autosave in the Game settings and Apply. You don’t have be afraid that you lost your progress if you forgot to save. But still don’t forget to save the game if you are implementing a very important mission and save when you exit the game.
• Now you can add stones into the crusher to get sand and limestones. No more tedious digging for sand and mining stones for limestones, just put all the stones you got from your miners and get as much sand and limestones as possible.
• The perfectionists will love it! 😊. We have made building easier and added an option snap to grid. Now during the building, pressing ALT (by default) you can choose 4 sizes of the grid.

• We have changed the weather a lit bit, less overcast now.
• Improved the visual part of the main page of the game (added some good-looking GIFs).
• We have also created a Discord Channel to make our communications easier. Add to our discord channel.
• We have re-worked Blueprints tab page.
• Bug, that didn’t allow a client join the game after totally breaking any tool – is fixed.
• Fixed wrong location of compass for non-standard resolutions.
• We have added a description to the requirements Noble Samurai Skill.
• Added sound during skinning of an animal body.
• We added some small details to the plot of the game to explain some weird things going on outside the village. Newcomers will find a letter close to the skeleton near a small pond not far from Henry’s house.
• Fixed small bugs.

Now it’s high time for you to earn some money and go blueprints shopping😊.
Furnish your houses and share the pictures of your interior house-designs in the screenshots in our community in Steam and in our Discord Channel.

Mar 4, 2024

Devlog #3: Goblin brains

Goblin Camp - Gencee

Goblins, and for that matter all creatures, need code to tell them how to act. In Goblin Camp our goblins must be able to fend for themselves. They need to feed themselves, drink, sleep, build shelter, fight off attackers and perform all kinds of jobs at camp. They ought to do these tasks while also being
aware of their surroundings, they shouldn't seem like robots or zombies that ignore all the things going on around them.

In this post I'll go through the systems I've written. They can be divided into two main systems. The first is a very traditional finite state machine, while the second is a more interesting and complex utility system.

I focus on how goblins behave in this post since they are the main characters, but the same systems drive the behaviour of all the creatures of Goblin Camp, from the birds flying in the sky to the deathfolk oggling at your gateway rock.

High level planning

Goblins form high level plans to establish a rough idea of how to fulfill their needs. For example, a guard goblin should grab a weapon and some armour if they don't already have them, hang around at their assigned guard post, and react to any alarms around camp. These three things translate into the 3 states a guard can be in. These states make it easy to write code in the style of "If goblin is in the 'Guard' state and a better weapon is available, reserve the weapon and transition to the 'Equip weapon' state."

Sleeping is a more involved example. A sleepy goblin will prefer sleeping in their own house, but if they don't have one the plan depends on how cold it is. In warm weather, the plan will be to pick a nearby tree and sleep in its shade, while during the cold months they'll formulate a plan to gather branches and
build an improvised lean-to to sleep in, which in itself needs planning to find a suitable place to build one so it doesn't block access to any existing buildings.

Each plan can only ever be in one state at a time, and will change from one state to another depending on what goes on in the game. Generally anything that behaves like this is called a finite state machine.

Each plan is independent, they don't interact with other plans at all. This keeps their implementations very simple, and it's easy to add new ones whenever a new plan is needed. A goblin will have multiple simultaneous plans: They'll have a job they need to perform, they might be sleepy
and thirsty, perhaps they're being menaced by a wolf.

Whenever a plan changes from one state to another, it will add one or more behaviours to the goblin. From the above examples, if the guard goblin has decided to equip a weapon the code will add behaviours to walk to the weapon, pick it up and equip it.

Low level behaviours

Every behaviour is a fairly simple, single thing to do. Examples are: "Move somewhere", "Pick up an item", "Attack an enemy", "Wait", "Equip a weapon", "Catch a fish".

A goblin can only do one thing at a time though so they need a way to choose from a large set of behaviours. They could have 5 behaviours that want to move them to 5 different places, and they can only be in one place at a time. To make goblins act sensibly they also need to be able to react to sudden changes around them, so they have to ready to change their minds in the middle of a plan.

A utility system is in place to allow goblins to decide which behaviour is most beneficial to them at any given moment. In particular the system is modelled after the Infinite Axis Utility System. Plans give behaviours an overall priority to give a rough ordering (idling at the gateway rock is a lower priority plan than performing a job, for ex.). More importantly each behaviour has a set of considerations attached.

Considerations

A consideration is a basically a function that evaluates to a number between 0 and 1. They are things such as "How far away is the item we want to pick up", "How thirsty is the goblin" or "How many enemies are nearby". Each consideration also has a response curve that determines what score the behaviour gets based on the value of the consideration function. This lets you tailor the same function for different purposes. Some behaviours should be more likely to happen if an item is nearby, while others should be less likely. We can reuse the same consideration for many behaviours just with different response curves.

A behaviour can have any number of considerations attached, and since the considerations are each independent adding new ones and modifying existing ones is very simple. Evaluating consideratons can be done in parallel since they only read information about the goblin and its surroundings and output a score value. This easily scales up to hundreds of goblins and other creatures all simultaneously evaluating and scoring their behaviours.

Thinking and reacting

One of the main features of this system is the reactivity it provides. Let's look at a concrete example.

A goblin has been assigned to fish. They formulate a plan with these behaviours: "Go to fishing spear", "Equip fishing spear", "Go to water", "Catch a fish". When the goblin has equipped a spear and is on their way to the water a ravenous crane descends from the sky and attacks them. Because goblins always have a behaviour to defend themselves, that behaviour now takes precedence over anything else and the goblin stops moving and starts defending themselves with their spear. A guard goblin arrives as well and they defeat the crane together. During the battle the fisher goblin became thirsty, and a set of behaviours to find water and drink have been added. During the battle any thirst behaviour is not important enough to be chosen, but once the battle is over drinking is the next most important thing.

Now the fisher goblin goes to the nearest water source and has a drink. Once they've had their drink the drinking behaviours are removed, and we're left with the original behaviours added by the fishing plan. Before they were interrupted they were still moving towards the water to fish, but the consideration for the "Catch a fish" behaviour scores highest now because they are already next to water. So they directly start fishing.

Modelling this kind of behaviour using finite state machines is possible, but accounting for all the various scenarios quickly becomes infeasible and often the solution is to just cancel whatever was going on and switch to the new state, or wait until the current state ends. In the above example the fisher goblin would cancel fishing altogether when attacked and drop their fishing spear. If they were to become thirsty while fishing they'd likely keep on fishing regardless, potentially becoming dangerously thirsty while doing so.
With the utility system AI it is simple to switch between behaviours and keep the old ones active, the system automatically rearranges them according to their scores, allowing goblins to react to changes and continue jobs where they left off.

On the other hand, adding in new plans with new behaviours remains easy and simple regardless of how many there are already. Since behaviours arrange themselves automatically based on their combined consideration scores, the complexity of the system doesn't increase when new behaviours are added. I can layer on as many behaviours as I wish and the goblins will keep behaving correctly. This allows us to keep adding more complex interactions between the goblins while keeping the code maintainable and bug free.