Cozy Coding in the Woods | Chains – Devlog #5

Hello everyone,

Welcome back to my devlog for Chains, a rhythm-building game I'm programming with the Godot engine. I'm currently spending the weekend with a friend in Brandenburg to get away from Berlin and, of course, to do some programming.

Progress So Far

Since quite a bit has happened since the first episode, let's take a quick look at the gameplay of Chains and the current status.  Similar to The Settlers and other building games, Chains is about building increasingly complex production chains to bring satisfaction and new opportunities to our population. 

What makes Chains special, however, is the rhythm that governs everything: the players' task is to rhythmically coordinate the network of production chains. 

Since the last episode, there are two different carriers that represent two note values: Quarter Carriers, which transport something every quarter note, and Eighth Carriers, which transport something every eighth note. 

In addition, goods now spoil if they are in transit for too long. This is intended to motivate players to optimise the speed of their production chains. If goods spoil or arrive at the centre in poor condition, their effect is greatly reduced: Since the last episode, mushrooms, for example, increase the possibility of building more Quarter Carriers. And the cooked worms from the Worm Cooker ensure that players are allowed to build the fast Eighth Carriers in the first place.

What’s in This Devlog

In this episode, I would like to address the following tasks:

● Firstly, the following question remains open from the last episode: What happens to carriers when production chains are interrupted and the limit falls below the current number of carriers?

● Secondly: I want players to have to pay even more attention to the rhythm of their chains. That's why I'm implementing a system whereby production buildings require the delivery of goods to follow a certain rhythm.

● Thirdly, I am adding the option to exchange existing carriers more easily between different note values.

What Happens to Carriers When They Fall Below the Limit?

Let's look at an example: First, I build a well-functioning mushroom chain so that I can build ten more Quarter Carriers. Now I use these additional Quarter Carriers for a new chain to tap into a distant worm source.

Suddenly, I realise that I need even more carriers for the new chain, so I thoughtlessly delete a Quarter Carrier from the mushroom chain. The consequences are immediate: my allowed number of Quarter Carriers is reduced. What happens now with all the excess carriers?

I think it would be annoying for players if the game simply deleted the carriers. Instead, there should be a short grace period before the most recently built carriers are forced to sleep and thus become inactive. Once the old limit is restored, the carriers wake up again.

To do this, I create a state machine with three states: ACTIVE, PENDING, SLEEPING. In Active mode, the carriers behave as intended; in Pending mode, the carriers go into sleep mode but continue to behave as planned; and in Sleeping mode, they finally go to sleep.

To track which carrier was built when, all carriers are assigned a number during construction. This allows me to put the carriers that were built last to sleep. I think it is least problematic for the players if the carriers that were built last are put to sleep.

For visual feedback, I change the colour of the sleeping carriers and add a temporary animation. Now I just need to get the state machine up and running.

Here is the result: I have a working mushroom chain as an example again. If I now interrupt the mushroom chain, you can see how the last carriers set turn grey as a warning, but continue to function. Once the grace period is over, they are put to sleep and no longer work.

Now the number of carriers is back to the limit, but how can I repair my chain? A button that allows players to manually put the carriers to sleep provides a remedy. This makes it easy to get below the limit and repair a chain. Afterwards, the remaining carriers that were automatically put to sleep wake up again.

Deliver Goods on a Specific Rhythm

The next task is to revise the production of goods: In future, I will specify for each building whether it needs certain goods for production and, if so, how these must be delivered: A mushroom or water collector, for example, is very simple: they only need the right tile and no other goods to produce their product. 

Manufactures are more complex: Firstly, they need one or more goods to function, and these must be delivered in a specific sequence. For example: all at once, one after the other, or one after the other but with a beat of idle time in between, etc.

For example, it is possible to have a building that simply needs one or more goods on a beat. But then there are also buildings that first need good A and then good B. It becomes really complex when individual goods, multiple goods and breaks are combined. In my opinion, however, the latter is only important for really high-quality production goods.

After several attempts, I have now decided on the following approach: There is a small helper class called RecipeStep. It simply has an array that I can fill with goods. I can now assign these recipe steps to my buildings. If there are no recipes, they simply produce goods out of thin air, like the Mushroom Collector or Water Collector.

For the production buildings, I can now simply fill the arrays with recipe steps. The more valuable a product is, the more complex its production should be. Let's start with something simple: Let's say the Worm Cooker simply needs water and a raw worm at the same time, as before: To do this, I simply create a Recipe Steps with the two required goods.

It gets more complicated when the goods have to arrive in a specific order. For example, first the water, then the worm. Then I have to rearrange my Carriers and make sure that the goods don't go mouldy on their way to the Worm Cooker.

And I can make it even more complex: let's just say that the Worm Cooker now needs water first, then a beat pause, and then both a raw worm and a mushroom. I can also map this with the recipe steps.

Players must strictly adhere to the rhythm. If a good arrives at the production building at the wrong time, the previous goods are destroyed and the sequence is restarted. If the sequence is done correctly, something is produced.

The only downside at present is that it only works with quarter notes. I will add productions with eighth notes to the game later.

Simplify Carrier Swapping

To conclude this entry, I would like to implement a small quality of life feature: the ability to easily change Quarter Carriers to Eighth Carriers and back again. At first, I thought about adding an extra button, but now I'm doing it this way: Players simply place the new carriers they want to have in that spot on top of existing carriers. If the conditions are right, the carrier is placed. In addition, it is no longer possible to place an infinite number of buildings in one spot.

Conclusion

I'm very happy with the progress: the sleeping system provides a good solution for excess carriers for now, the RecipeSteps system is easy to use and allows for a wide variety of rhythmic sequences. And the simple upgrading of carriers has also been on my list for a long time.

For the next episode, I'm planning a new production chain for water monsters, a better display of what the production chains actually need, and I want to make placing carriers and adjusting rhythms more intuitive and require fewer clicks.

Thank you for reading, and as always, I welcome your feedback and suggestions. See you soon!