I guess that requires that I post what I am creating in the first place. Uploading the working bot code is not going to be sufficient, because the program code is only a small part, the tip of the iceberg.
To be clear, my goal is a different one: I don’t want to convert a script, but only find an anomaly ratting bot that works well today and is easy to understand.
So, where do I get the information from that allows me to write code?
The source of information is feedback from playing the game. Usually, most or all of this feedback comes from other people who share their observations in various ways, such as publishing training data sets.
There is also another way to get the training data: I will soon have access to a game account with a setup sufficient for anomaly ratting. This way, I can do the live testing myself and get the training data faster. As a result, I can find a working bot within a few hours.
For me, there is yet another source of information: The experience with A-Bot, which was an earlier anomaly ratting bot. Since this project started in 2016, we already got a lot of feedback on the approach there. So I learned that an architecture based on a decision tree is sufficient for this activity and works well. Also, the source code from A-Bot encodes the knowledge of how to do the ratting in-game. It is easy for me to understand because it is organized to follow the same coding principles as explained in the guide on developing for EVE Online (In the navigation basics chapter)
Before writing the first piece of code, my idea is to start with the combat part of the bot. When I see that the combat works, I can add other components, like finding anomalies and warping there.
The mining bot example project already implements a decision tree (How to Automate Mining Asteroids in EVE Online - #109 by Viir), so I start implementation by copying the mining bot code.
I want to speed up the development process, so I will use a trick to get a head start: Before even attempting the first live test with a game client, I try to convert the combat part of A-Bot, coded in the file Combat.cs
This combat function is distributed over 53 lines of code and contains a lot of information we can reuse for ratting. One way to summarize it is to list the subtrees it emits that can lead to effects:
- Unlock target.
- Lock target.
- Activate weapon module.
- Launch drones.
- Engage drones.
- Return drones to the bay.
The unlocking of targets might have been added because there is a risk that a bot will accidentally target the wrong object. Even if this happens only one out of ten thousand times, accounting for this helps avoid interruptions.
Let’s take a closer look at locking new targets: The way it uses TargetCountMax, we can see that it will lock multiple targets, to allow us to continue attacking as fast as possible when one target is defeated. This feature makes the bot more efficient as it will avoid waiting for new target locks during operation. The downside is it makes the code more complex than the simplest possible combat function, but since it is easy to translate this code, it is OK to use this extra feature right from the start.
We can also see that there is some filtering going on to find the next overview entry to lock a target: It is not sufficient to look for entries which represent rats to attack, because we might already have locked that object. To avoid this, the combat function filters out the overview entries which have any of these icons:
- Indicating we have locked the object as target.
- Indicating we are in the process of locking the object as target.
You find this filtering expression on line 87
Attempting a rough translation of the A-Bot combat function, I arrive at this decision tree:
- Branch: Is there a target to unlock?
- Yes: Unlock that target.
- No: Branch: Is there at least one locked target?
- No: Branch: Is there at least one overview entry to attack?
- No: Return to integrating function: We are done here.
- Yes: Use ‘Lock target’ on that overview entry.
- Yes: Branch: Is there any inactive weapon module?
- Yes: Activate that module.
- No: Branch: Is the number of drones in the bay greater than 0 and the number of drones in space less than 5?
- Yes: Launch drones from bay.
- No: Branch: Are there drones in local space idling?
- Yes: Engage drones.
- No: Branch: Is there an overview entry that we should lock as target? (See the filtering of overview entries explained above)
- Yes: Use ‘Lock target’ on that overview entry.
- No: Wait
- No: Branch: Is there at least one overview entry to attack?
To identify the weapon modules, we can reuse the approach from the mining bot: Let the user place the modules so that only weapon modules are in the upmost row: https://github.com/Viir/bots/blob/d2c881f35b59bdbdd6616b8f1c1e40332c403558/implement/applications/eve-online/eve-online-mining-bot/src/Bot.elm#L13
We can use the second row for modules that should always be active.
Since the mining bot already implements the grouping of modules into rows, we can copy the code from there.