An Outlook on Development of BotEngine

As promised a week ago, I am sharing my conclusions from aggregating feedback on bots and development tools.
These are the basis for how I continue to make machines work for us.


Even with the relatively small number of bots available today, for many people, the problem is filtering this quantity to find what they are looking for.
Using the search function on the forum or google helps, but these options are far from optimal.
A way to improve this is by offering better filtering tools.


The Sanderling IDE made it simpler to develop and operate bots and I will further advance here.
I plan to make bot setup more straightforward, for example by offering to configure a bot without the need to edit a script.

People often expand their bots to issue alerts in specific situations, and the numerous questions about this functionality suggest that there is value in making this easier.


Development will become easier with improved documentation, but guidance for development also is based in no small part on the provided examples.
After publishing bots based on different approaches to code structure and build workflow, the feedback helped me better understand the challenges people face when adapting those examples.
These learnings will help me to change the examples to make development more accessible.

Another way to improve development is by providing better guidance when editing code.
In the current development environment, developers have to bear the peculiarities of C# and .NET.
The friction here can be reduced by introducing better static analysis and a simpler programming language.


Improving Example Applications For Eve Online

A comparison between today’s eve online sample mining script and A-Bot illustrates differences between approaches to bot architecture.
Many of the often asked for adaptions of the mining script are made tricky by the scripts overall structure.
The task tree approach in A-Bot makes implementing changes of bot behavior easier, but the current implementation of A-Bot is not suited for distribution with the common IDE and therefore requires a complicated setup to build from source.
To make bot development more accessible, I am planning to fix this.


(First off, this is said with complete respect and gratitude. Second, I could be really off base here. If I am, someone please correct me!)

@Viir, I see that you are working on improving the framework, which is awesome, and I really respect your hard work and dedication. However, if I may offer some constructive criticism… You are clearly quite brilliant with the language/.NET, and I have noticed something I frequently see in my line of work when dealing with similarly skilled developers.

(I hope this metaphor works, as it is the best that I can come up with.)
Let’s say that learning a programming language is a journey. Often, when someone so knowledgeable tries to help someone who is new, they look backwards down the road to their starting line so they can answer questions in a way that the newcomer will be able to understand. However, what that developer sees as their starting line, is actually just the horizon, and the true starting line might be several more horizons away from that. You are wonderful at answering questions, and you are probably doing so in a way that allows us to easily adapt them to many situations. However, the answers often combine some higher level programming techniques and that causes many to be unable to understand how it works, leaving them one answer closer to their goal, yet none the wiser because they don’t understand how your solution actually works.

I have a feeling that the API solutions you make for us are similarly influenced by your starting line being too distant to see. Many of your functions accept such a wide array of options, and can return a wide variety of things, that it is hard to know how to use them unless one has experience combining those advanced concepts.

I consider myself to be the kind of programmer that is very good at creating modular solutions that mimicks how skilled players categorize information, applies weighting based on the situations, and makes intelligent decisions with that information. (To the point of my partner suggesting that I patent my algorithms for targeting prioritization and weapon coordination.) However, when I look at your code, my eyes glaze over and I feel stifled. I think of things in terms of things like:
Bool Object.WarpTo(??? ObjectToWarpTo, Int WarpToDistance, Bool ConfirmWarping, Int SecondsToWait) ; inputs 2-4 have defaults, making them optional.
Which uses things like:
Bool Element.MenuSelect(Array EntriesToSelect)
Bool Ship.IsScrammed()
Bool Ship.IsPreparingToWarp()
Bool Ship.IsWarping()
Int Ship.Speed()
Bool Ship.IsStuck() ; bouncing off of something

This way, a newcomer could simply do:
WarpTo(PnP.Bookmarks.Personal(1)) ; warps to first green bookmark at zero. Returns false if scrammed, speed bounces, or not in warp by 60 seconds.
As that person becomes more comfortable and starts to upgrade his code so that (with ConfirmWarping = False) he can start warping and reuse as needed to determine when it completed, while being able to do other things like target and attack scrammers.

I feel that this probably explains why there aren’t more people developing off of Sanderling.

That’s the best way that I can find to explain my difficulty integrating your API into my existing code.

1 Like

Thanks @Innominate, really an interesting post which made me think.

I would even go so far to question if this specific to learning a programming language :wink:

I am not always eager to guess what a particular person’s previous experience is. I rely on questions to find out if there is something missing for them to understand how something works.
When reading in the forum, I scan for question marks to see where are questions.

There are other people with more experience than me in the domain and they will be better at narrowing down the set of choices given in an answer.
Maybe I can become better at recognizing when questions are better answered by someone with more experience than me.

So how can we improve here?
Maybe some of these options are not needed and could be removed to make the API simpler. But making such a decision would require knowledge about the domain.
But I see another way to improve here: Even when not reducing the flexibility of the API, we can still make development easier by helping people to discover useful combinations of the building blocks.

You give many examples of how experience in eve online helps when designing such an API. I think for many people it is better to not integrate that basic API we have now, but use an API that was designed by people who have more experience in eve online than me.

I see that you are responding right now. I just wanted to add that “black box” functions, like the ones I exampled, also help people easily find where in the data tree things come from, and provides examples for how to make code easier to follow.

Sorry, I assumed more eve experience.

The existing API is great and need not change. Right, simple reusable functions that describes the action and returns whether successful makes things easier to follow, especially when used on multiple levels.

; High level flow
While time between…{
If InSpace
Dock ; false closes eve
Restock ; false generates pop-up and pauses
While Hostile
Sleep x
; Done

; Mid level flow for WarpHome would use my warping related functions in my first post.

That’s a good point. To enable these reusable functions, I published the Sanderling Integrated Development Environment (IDE).
Using this IDE, the people who have the experience in a particular domain (for example EVE online) can change and create such reusable functions without needing to wait for updates of a central repository.

People interested in using a simpler bot API for eve online should take a look at Improving API and Documentation for EVE Online