#behaviour trees

The tree used in this demonstration is 15 nodes in total, which is relatively small. It primarily consists of only two behaviours: retrieving up to 8 fuel whenever its hands are empty and the lamp is on, and cycling through the furnaces giving them 1 fuel each. Otherwise, it waits at its initial position.

The lamp itself only serves as an indicator that enough fuel is present to retrieve, which ensures the fox distributes it evenly. Beyond that, the fox's behaviour tree is entirely responsible for the automation demonstrated.

In this particular implementation, the number of furnaces is entirely arbitrary and the tree can handle as many furnaces as the fox can hold fuel. The only thing that would need to be changed is the contents of the Furnace Array variable, the tree would handle everything else.

A behaviour tree approach is quite valuable in this context, as it enables a singular agent to take the place of possibly dozens or even hundreds of ticking tile entities with considerably less engineering needed on the part of the player. Instead, they only need to walk through the steps they themselves would take to perform the same task.

Automation seldom ends here, however. There may be occasions where specific player-taken actions are needed, often specifically relating to certain items held in hand. This might range from applying a food item to multiple livestock to initiate breeding, to mining resources (both in the wild and in controlled environments), to attacking hostile agents in the pursuit of certain rewards (aka "drops", after the tendency of such items to "drop" once the entity is slain).

These tasks may be simplistically reduced to repeating them endlessly (in the understanding that the desired context will just happen to occur whilst the loop continues) or performed more conservatively (such as waiting until a sheep's wool has regrown before trying to shear it). This presents a quandary in terms of efficiency: The eternal loop approach will inevitably require fewer behaviour tree nodes, whereas the efficient approach will inevitably require more, hence the efficient tree has higher computing costs. This poses a problem when attempting to maintain a low-impact system, which is difficult to overcome without providing very low-impact and often hyper-specific conditions.

However, despite this challenge, it can be foreseen that the end result remains less severe on a server's resources than the equivalent in a large mechanical system as well as providing opportunities for players to continue playing the game. This is to say that as many of these more complex automation tasks require the player to undertake them, either by writ of how interactions are performed or by their complexity, it becomes increasingly necessary for the player themselves to perform them. This can range from mindless repetition of the same action for hours on end or, even less palatably, from automating the player's control inputs directly (such as by an external auto-clicking application).

But in all this there is an overarching question: Is it fun?

By alleviating the need for large complex systems, reducing much of them down to only a handful at most of behaviour tree-driven programmed agents, are we eliminating part of what the player finds enjoyable in the first place?