Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add solver option "active robot must ricochet before reaching the goal" #13

Closed
smack42 opened this issue Oct 5, 2018 · 8 comments
Closed
Labels

Comments

@smack42
Copy link
Owner

smack42 commented Oct 5, 2018

feature request via BoardGameGeek
https://boardgamegeek.com/article/30145862#30145862

Is it possible to include an option to turn off the "active robot has to ricochet at least once before
reaching the goal", but not allow the 1-move solution?

This is the example I came across: (screenshot)

Without the ricochet rule above, it can be done in 7 moves (green: W S E silver: S blue: W S red: E),
which I think could be permissible as another robot is needed.

The custom board on that screenshot is this one:
!DriftingDroids_game!C290C2E0!AAABM3jaY2BgYOAAYVYgYQDEJkCsCsRmQCwExAyMU
ABkMcABEhNNkJERizxYMyOSTka4ClRxmCEQmhHBJN1eRoTDKXIAlDICs4AkIwAm6QGF!

@smack42
Copy link
Owner Author

smack42 commented Oct 5, 2018

my reply at BoardGameGeek
https://boardgamegeek.com/article/30156262#30156262

Yes, I can add such an option to the program.

I propose to do it like this: Add a new solver option "active robot must ricochet before reaching the goal", which is a checkbox (yes/no choice) with default value "yes". When the user unchecks it (choice "no") then it allows 1-move solutions for the Ricochet Robots boards where each goal has two adjacent walls. In your custom board example it would allow solutions like the one you've presented, with the active robot doing just one move straight to the goal after the helper robots had moved.

I would not like to make the meaning of this new option more complex, such as "active robot must ricochet before reaching the goal if it could reach the goal in just one move and no other robots would have to move in order to help it". In my opinion that's too confusing. What do you think?

The code changes necessary for this are quite small. The most challenging part are the translations of the new GUI text into the various user languages. English and German are done be me. I'm going to ask the people who contributed the Esperanto, Russian and French translations for their help again.

@rubo77
Copy link

rubo77 commented May 26, 2019

Is this included by now? Where do I find the code for this?

because I have a problem in my Roboyard, that the solver rejects to find a solution if the target doesn't sit in a corner and the robot would have its last move directly:

Screenshot_20190526-235521_Roboyard

@smack42
Copy link
Owner Author

smack42 commented May 27, 2019

Generally, the active robot has to stop at the goal. If, like in your screenshot, there is no wall behind the goal space then you have to move another robot there, in order to make the active robot stop.

The code change discussed in this issue is not done yet. I started something some months ago but haven't finished it. I should continue that some day...

@rubo77
Copy link

rubo77 commented May 27, 2019

Yes, exactly, It needs another robot there, I find a solution with 11 moves, for example, where the blue goes right to give way for the green robot to pass and stop down there, then the blue goes left and down.

but the AI doesn't find any solution because that last move is not allowed, I guess.

Where could that code be in your solver?

@smack42
Copy link
Owner Author

smack42 commented May 30, 2019

I've copied the game state from your screenshot into DriftingDroids:

!DriftingDroids_game!18252EF4!AAAEL3ja5ZLNDYAwCIX5TNOLF6fw5t4O5iBWrfY
HcAAlgZT3KAWKiMh0aEhmS7omjUmXMQZ6kU6oD4q9EWxMx5/4wXQUJT2Pb99u4sR5pMXJ
Sb1gWvPSvsFTk5jN6tmA9imVGpV59dnxZAanU3d4X/9ve+H/uwAZmge5LDuLZQL4!

The current version 1.3.7 finds some 13-moves solutions, because it doesn't allow the blue robot to move straight to the goal.

My local code change (not committed yet) in response to this issue here, relaxes the rule restrictions in the solver algorithm to let it find an 11-moves solution like this:
grafik

I'm going to commit this change shortly, when I have that code properly cleaned up and tested.

smack42 added a commit that referenced this issue May 30, 2019
For custom-made boards we don't apply the rule "active robot must ricochet before reaching the goal" as strictly as for the standard Ricochet Robots boards.
This is achieved by detecting the "solution in 0 or 1 move" situation only if the active robot stops at the goal in a single move, because there is a wall or another robot behind the goal space. On all standard Ricochet Robots boards there are two walls next to each goal, so this condition is always met and we have to enforce this rule to avoid the trivial single-move solution. But on custom boards the goals can have no walls next to them and then some helper robot(s) are required to reach the goal. In these cases we allow the active robot to move straight to the goal, because moving the helper robot(s) to the required is not a trivial single-move solution.
rubo77 added a commit to Eastcoast-Laboratories/Roboyard that referenced this issue May 31, 2019
commit smack42/DriftingDroids@67057cf

For custom-made boards we don't apply the rule "active robot must ricochet before reaching the goal" as strictly as for the standard Ricochet Robots boards.
This is achieved by detecting the "solution in 0 or 1 move" situation only if the active robot stops at the goal in a single move, because there is a wall or another robot behind the goal space. On all standard Ricochet Robots boards there are two walls next to each goal, so this condition is always met and we have to enforce this rule to avoid the trivial single-move solution. But on custom boards the goals can have no walls next to them and then some helper robot(s) are required to reach the goal. In these cases we allow the active robot to move straight to the goal, because moving the helper robot(s) to the required is not a trivial single-move solution.
@smack42 smack42 added the solver label Jun 8, 2019
@smack42
Copy link
Owner Author

smack42 commented Jul 25, 2020

closed by release 1.3.8

@smack42 smack42 closed this as completed Jul 25, 2020
@rubo77
Copy link

rubo77 commented Jul 26, 2020

Should I update the solver in roboyard as well? Or did the functionality stay the same since the last commit I used?

@smack42
Copy link
Owner Author

smack42 commented Jul 26, 2020

The relevant code change was committed in May 2019, more than a year ago. You had already merged it into your app.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants