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

[smack42]

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]

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]

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:

[smack42]

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]

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]

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:

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

[smack42]

closed by release 1.3.8

[rubo77]

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

[smack42]

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