Combining multiple tasks

[rom1504]

When creating a bot, you usually want to combine many different methods and information to accomplish tasks. Mineflayer provides unit action (digging, simple movements, building, ...) and information.

There are many ways to combine these actions to produce useful behavior :

• the pyramid of doom (anti-)pattern
• defining case specific functions to combine functions (this for example)
• state machines (in mineflayer-scaffold)
• iterators (in helperbot)
• meta programming (in rbot)
• a task manager (see dutie and dutieflayer but also duties)

There are also some stuff provided by the js community that might be useful :

• async
• promises

In this issue I'd like to talk about whether we can find some common ways on how to combine mineflayer tasks to get useful behaviour. That doesn't mean these ways should be included in mineflayer, they can simply be ways we advise people to use when building bots, but since mineflayer is the common factor in all this, it seems like a good place to talk about it.

I think criteria to know whether one of these ways works or not are :

• do you need to write a lot of code to use it ?
• is that code complicated to read ?
• how much was done with that method ? does it work to actually get useful bots ?

It might be interesting to make a table to compare all these methods (with the pros and the cons).

The discussion has also started there https://github.com/andrewrk/mineflayer/issues/182 and there https://github.com/demipixel/dutie/wiki/Example-task-scenarios.

[rom1504]

Several steps into doing something :

• task generation : generate all the tasks you are going to do to accomplish something
• task scheduling : decide what you are going to do first
• task evaluation : actually do it using mineflayer

Most of the methods listed above mix all that together. I think it might be interesting to separate these aspects because really they are different problems.

For task generation : it might be interesting to build some kind of graph of what you can do to get from a state A to a state B. For example :

• A = you have no tool ; B = you want to get some stone ; what you can do : [[get log; craft wood; craft a stick ; craft a wood pickaxe; get stone], [kill someone with stone] ; [find a stone itemStack in the world]; [get some tnt; make it explode; get the resulting stone]]

Each possible task could get a estimated time attribute in order to choose which to do. If that graph was available, it would be easier to generate task based on what you have and what you want.

[demipixel]

That would be quite difficult to do. How would we program every possibility? How would we show that tnt is very resource unfriendly? What about getting wool? Making a farm would take longer but would be useful.

[vogonistic]

This should probably be a plugin, but it sounds like a lot of fun. You could attach providers that can answer with the amount of time to answer queries.

need: * axe
response from crafter: [go to chest, get things, go to bench, craft axe], time 60s
response from fetcher: [go to chest, get stone axe], time 5s

There could be providers for walking using different methods, inventory crafting, subcontracting to other providers and so on.

[rom1504]

Related to (the obtaining field of) https://github.com/wurstmineberg/assets.wurstmineberg.de/blob/master/json/items.json.description.txt

[rom1504]

On that theme, trying to express achievement as tasks would be a good test for a task model http://minecraft.gamepedia.com/Achievement#List_of_achievements

[Slord6]

I've also been thinking about this but in the context of multiple bots working together. I think it's a use case that's worth bearing in mind. The separation of generating task/scheduling task/executing task that @rom1504 mentioned is definitely the way to go, especially in the case of cooperative bots. For my use case I've been thinking about it in terms of a single goal, for example Mine 1 Obsidian, you then iterate backwards from to generate tasks that can be split between bots. So for this example, if you'll excuse the terrible diagram:

All the tasks are effectively already ordered for each bot to take the next one, provided it's sub-tasks are complete.

I think this is what was meant by "some kind of graph of what you can do to get from a state A to a state B" in the earlier comment? This seems completely feasible with mineflayer in its current state, perhaps with a couple of exceptions, eg Mining the dragon egg as a goal - not sure if you can programatically get that it's effectively a drop from the dragon?

[qrvd]

The approach of multiple bots working together sounds very interesting, it would allow for quite advanced play. By the way, I haven't seen it mentioned here, but you may want to give Behavior Trees a look, since they're a common way to implement advanced AI and very versatile:

• Behavior Trees - Overview
• An Introduction to Behavior Trees
• Behavior Trees for AI - How they work

[extremeheat]

Yes, see https://github.com/PrismarineJS/mineflayer-statemachine/ for a basic finite state machine

[qrvd]

I've been trying to implement a simple Minecraft bot, and as I understand it, behavior trees are quite different to finite state machines. But both have their valid use cases

[egeres]

You guys might be interested in STRIPS, which is a planning algorithm which could design strategies and itineraries of actions to complete a specific goal 🙌🏻