Refactoring Proposal: Behavior Trees, Tasks, and Plugins

[elicwhite]

Problems:
It is hard to configure the bot the way each person wants.
It is hard for engineers to add / extend the functionality of the bot
As this bot grows, there isn't great separation of behavior, causing additional complexity and problems with merge conflicts.

Solution:
Previous bots for games like World of Warcraft have grown to huge heights by being easily configurable, extensible, and easy to understand. The classic solution to this is to implement the bot core as a configurable behavior tree.

The basics are actually pretty straight forward in this case.

Imagine there are tasks like this:

ClearBag
TransferPokemon
CatchPokemon
SpinPokestops
WalkToLocations
WalkToNearestPokestop

These tasks would be implemented as classes that have a run method.

We could then read in a configuration file that people can write which defines how the bot runs. This would make it significantly easier to configure than adding more cli flags.

I imagine people could then write configs like this:

{
    "tasks": [
        {
            "type": "TransferPokemon",
            "arguments": {
                "minimumRemainingSlots": 10,
                "minimumCP": 100
            }
        }, {
            "type": "CatchPokemon",
            "arguments": {
                "greatBallCP": 300,
                "ultraBallCP": 500,
            }
        }, {
            "type": "ClearBag",
            "arguments": {
                "minimumRemainingSlots": 5
            }
        }, {
            type: "SpinPokestops"
        }, {
            type: "WalkToLocations",
            arguments: {
                "locations": [
                    "40.781362, -73.969046", 
                    "40.768075, -73.976339"
                ]
            }
        }
    ]
}

The tool would take the configuration, instantiate an instance of the task type for each element in the tasks array passing the configuration arguments to the constructor. It then uses a game loop, essentially a while loop that on each tick iterates through each task calling run.

By putting tasks higher in the task list, it essentially says it is a higher priority.

In the example above it is saying that it needs to make sure there is space in the pokebox before catching pokemon, space in the bag before spinning pokestops, and it should catch the pokemon around before starting to move in the direction of another location.

By doing this, we can enable other people to create repos that implement new tasks that can be more complex and swapped in for other things, and those classes can be extended as well.

I'm curious what people's thoughts are on this. Is this a direction people would want to go?

[tstumm]

A more modular approach would be nice, but configuration should be more easy. It is "just" Pokemon Go, it is not that complex that we need full "if this than that" configuration.

PR are welcomed :)

[jtdroste]

I disagree with @tstumm, this is a great idea. I'd add an optional "weight" param though, so we can set the order which tasks execute.

[elicwhite]

@jtdroste I'm thinking that to start the order will be the order in the tasks array. The old WoW bot had the ability to set the ordering though. It kinda made it confusing for people because multiple tasks could be configured with the same weights which made it not very clear. Here is an example configuration. This was pre json: http://pastebin.com/EjFt6L3E

[tstumm]

@jtdroste So you disagree with easy configuration? If you do "if this than that" you easily have an overly complex configuration. Ordering by position in configuration seems a good approach for me.

[elicwhite]

@douglascamata I thing nearly everything could be implemented as a task. For example, a RestForSoftBan task that people would put early in the list and it would simply wait and keep the rest of the things from executing. Or maybe it would be configured to use that time to walk to a certain location instead of just standing still.

Tasks provide clean, standalone, drop in functionality decoupled from everything else around it.

[elicwhite]

Some recommended reading to understand decision trees more broadly, and then it goes into how they are implemented. I want to make sure people understand the system well enough to be able to make an informed decision on whether this is the approach the bot should take before writing out a lot of code for this.

http://guineashots.com/2014/07/25/an-introduction-to-behavior-trees-part-1/