Question: How to get @ point X,Y in due time

[clemens-tolboom]

(Asked in https://github.com/ErmiyaEskandary/Slither.io-bot/issues/241#issuecomment-222673120 but that is about teleporting.)

Question

I want the bot to move to point(X,Y) in due time.

Use case

• move to center where the food density is higher
• move to position when you want to battle your own bot (gamer vs bot)

  Implementation

I'm not sure how to implement this within the go function

       go: function() {
            bot.every();

            if (bot.checkCollision()) {
                bot.lookForFood = false;
                if (bot.foodTimeout) {
                    window.clearTimeout(bot.foodTimeout);
                    bot.foodTimeout = window.setTimeout(
                        bot.foodTimer, 1000 / bot.opt.targetFps * bot.opt.foodFrames);
                }
            } else {
                bot.lookForFood = true;
                if (bot.foodTimeout === undefined) {
                    bot.foodTimeout = window.setTimeout(
                        bot.foodTimer, 1000 / bot.opt.targetFps * bot.opt.foodFrames);
                }
                window.setAcceleration(bot.foodAccel());
            }
        },

[FliiFe]

As an alternative to "due time", you could look at the A* path finding from @OneEyed

[ermiyaeskandary]

For what @FliiFe ?

[clemens-tolboom]

I did look @ A* but the main point is when to move to ie center? That should not happen while eating or avoiding collisions.

My guess is the go() function should be replace by the A* part in order to do this. Or implement a priority list where some actions increase / decrease in time to allow for alternating action. It's not my main skill so need some advise to let my bot move to center or other X,Y.

[ChadSki]

Ah, you mean you want the bot to do eating/collision-avoidance, but also if there's nothing in the immediate area, it should try to approach your other player?

Sounds like a feeder bot, hah.

[Defimatt]

@ChadSki I read it as the bot should go to position (x, y) and use A* to prevent itself getting killed on the way; once it's there, the A* logic turns off and the normal bot logic takes over. @clemens-tolboom, can you confirm my understanding?

[ChadSki]

Oh, so the primary objective is to approach (x, y), then run the normal bot behavior. My earlier interpretation was backwards.

FWIW I think A* is really ineffective for Slither. It would be easier to freshly code behavior for going to (x, y).

[ermiyaeskandary]

@ChadSki Agreed hence why it is now in a separate branch.

[Defimatt]

@ChadSki @ErmiyaEskandary - as long as it doesn't get eaten on the way, it doesn't matter what the logic is. Maybe just turning on collision detection, but ignoring food would do it?

[ermiyaeskandary]

Yeah! Like a follow mouse mode except that you can enter coordinates or specify a place.. Do I understand this correctly? Try to get to a specific place while trying not to die ?

[Defimatt]

@ErmiyaEskandary that's my understanding, but it's @clemens-tolboom 's issue, so best wait to run it past him first in case I've misunderstood.

[clemens-tolboom]

The first idea is to get to P(x, y) without starvation and/or dying. I've got some useful input and will chew on it. Will definitely steal some code from the A* branch.

But the hard part is how to add / code other goals:

• moveTo(X, Y)
• catch preys
• prevent getting surrounded
• surround other snake
• try kill snake Q
• etc.

A* has a decision tree so what will be the 'new' go-loop?

[ChadSki]

Your bullet points seem to involve a lot of different complex features... beware of feature creep. Avoiding being circled and encircling others are always talked about but difficult to implement.

If you're going to focus on just getting to (x,y), I suggest:

1. Collision avoidance always takes first priority and overrides other goals (this is currently the case, and should probably stay that way)
2. Normally food-searching is the second priority. You could implement some toggle that makes the bot care about getting to (x,y) instead. Once it's close enough to the goal coordinates, turn the food-searching back on.

I'm not sure that it's possible for a snake to starve to death.

[Defimatt]

@clemens-tolboom I agree with @ChadSki that this issue should remain focussed on getting to an arbitrary point; we can worry about the other stuff afterwards.

There is a huge amount of baggage that comes with the A* strategy, such as the behaviour tree and A* libraries; the bot became so big that it had to be split into multiple files.

If we can implement this feature without dragging in a lot of external libraries or any of the A* codebase I'd be more comfortable.

A snake cannot starve to death. What happens is you eventually get back to a size of 10, which means that you can no longer boost. That gives you a disadvantage in getting away from tight situations, but it's not the same as starving.

[chancity]

The behavior tree can do everything... It's pretty sweet once you figure it out.

On Tuesday, May 31, 2016, Matt Duffin notifications@github.com wrote:

@clemens-tolboom https://github.com/clemens-tolboom I agree with @ChadSki https://github.com/ChadSki that this issue should remain focussed on getting to an arbitrary point; we can worry about the other stuff afterwards.

There is a huge amount of baggage that comes with the A* strategy, such as the behaviour tree and A* libraries; the bot became so big that it had to be split into multiple files.

If we can implement this feature without dragging in a lot of external libraries or any of the A* codebase I'd be more comfortable.

A snake cannot starve to death. What happens is you eventually get back to a size of 10, which means that you can no longer boost. That gives you a disadvantage in getting away from tight situations, but it's not the same as starving.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ErmiyaEskandary/Slither.io-bot/issues/266#issuecomment-222833420, or mute the thread https://github.com/notifications/unsubscribe/AH1vVXL4eKL6xhFOF1Eb12t2C9BXLgt3ks5qHK52gaJpZM4Iqnxs .

[clemens-tolboom]

I've created a PR #273 with my thoughts worked out a little. The bot works but has issues (of course). It moves to the center but does not eat much let alone accelerate.

But the advantage is I can inject new tasks and tasks can increase/lower their priority.

Next I have to dive into the A* branch and incorporate some features into tasks.

Hope you find it interesting :-)

[clemens-tolboom]

Removed the PR in favour branch. https://github.com/ErmiyaEskandary/Slither.io-bot/tree/feature/task-execution.

[clemens-tolboom]

As I pushed a branch I created an issue for it in #275. Guess this issues original (moveToXY) is solved by that branch.

Some feedback on comments made above:

[edit]@MattDuffin[/edit]

Collision avoidance always takes first priority and overrides other goals (this is currently the case, and should probably stay that way)

That is not true. Say I want a body guard bot ie protect my real user snake. The logic is currently hard coded so I can not be build that.

[edit]@MattDuffin[/edit] + @chancity

If we can implement this feature without dragging in a lot of external libraries or any of the A* codebase I'd be more comfortable.

The behavior tree can do everything... It's pretty sweet once you figure it out.

The A* branch contains real nice behaviour steps but AFAIK no priority scheduling not allows for UserScript extending. Please check my branch through issue #275 :-)

[Defimatt]

@clemens-tolboom I assume you meant to quote me not @ChadSki?

[clemens-tolboom]

@MattDuffin fixed. Thanks. Any thought too?

[Defimatt]

@clemens-tolboom I'm trying to test your branch but struggling due to floods of console messages, check my comment on your most recent commit.

[clemens-tolboom]

I close this now as #275 is getting up to speed.