Tutorial Advanced

BOT Architecture Patterns

This post is related to people who want to make his own bots for EVE Online.

I made many nodes and completed bots in EVE Master and understand important architecture patterns, which help to make canvas of nodes more readable, ease to scale and change.

Linear Pattern

The most simple and intuitive pattern. Execution flow goes linear from left to right and has logic end in Exit Success or Exit Error nodes.

Example of Linear pattern usage in “Open current system context menu” node

Pros: simple, works good for a small logic peace.
Cons: bad for complex logic constructions, can do single task, do nothing else until complete it.

Possible exceptions when logic end should be ignored and logic should be repeated multiple times. Imagine, your ship in dangerous, you have just single high priority task – dock the ship. Good point to repeat execution flow until success.

This pattern doesn’t work for a full automated bots, which always should handle many things, such as check different dangerous things, like health and other dangerous.

Recycle Pattern

Advanced pattern, should be used in any bot. Core principle in this pattern – do not use Exit nodes. When execution flow became to a node with no forward way, execution flow goes to Start node. This small update forces execution flow to go over and over again, through all logic parts.

Exit node can be used only in specific cases such as need to shutdown bot because game server is going to shutdown.

Example of Recycle Pattern in “Neutral Alarm” node. Exit Success node is not linked to the Execution Flow. Execution is infinite until user manually stops it.

Pros: reusing all logic on canvas, complex logic looks cleaner, works good for anything.
Cons: it needs mind-shift, need to recognize where is the bot now, what it is doing or just did.

Because each time the node executions begins from Start, need to add logic for understanding where is the bot now, in space or docked, has low health or doesn’t… That is needed for executing right actions, if health is low – go dock, if at asteroid belt – lock asteroid, if already locked – activate mining lasers.

This is very flexible way to create bots, any time you can add new branch into the flow with new status validation.

Ratting bot as an example

  1. check execution duration
  2. set variable value to False if execution time is reached, set True if doesn’t
  3. close annoying dialogs if that appears
  4. close Neocom of that is opened
  5. validate Stations Path user input, it has to be valid, in other case bot will not be able to dock
  1. check if ship is docked
  2. docked: check execution limit reached
  3. docked: check server going to shutdown
  4. docked + execution limit reached OR server is going to shutdown: play voice message and send text message and stop (Exit) the execution
  5. docked: check user wants to check neutrals
  6. docked: check neutrals and split the flow into to ways
  1. docked + neutrals detected: send message, play voice message, await long period of time, because neutrals are detected in system
  2. docked + no neutrals: repair ship, undock

No sense to describe each single node, for example should be enough. That is full view on Ratting bot. It repeats through all the nodes over and over again and doing it very fast. That is a lot of other validations, such as: inventory window open, health status, drones status, locked targets check…

Leave a Reply