+- Ludii Forum (https://ludii.games/forums)
+-- Forum: Suggestions (https://ludii.games/forums/forumdisplay.php?fid=10)
+--- Forum: Submit Your Games (https://ludii.games/forums/forumdisplay.php?fid=23)
+--- Thread: Throngs (multi-step approach) (/showthread.php?tid=399)
Throngs (multi-step approach) - dale walton - 01-28-2021
This version of Throngs is working, and I would like it included on an experimental (beta) basis, as there are still caveats.
It includes 3 board types.
Outstanding issues:
1) AI is essentially random for this version. It also considers each decision as a turn so that can be several decisions before turning control over to the player.
2) The turn counter is not breaking the turn register into proper turns according to who the mover is. - I even restructured the turns into separate phases and tested modifying the turn counter in the script, but nothing seems to correct this.
3) Using Meta settings was causing the AI to hang, so I implemented "no repeats in turn" using Remember instead.
4) I also worked around All Pass, -- I have not gone back to test if your new change works, as it would now mean restructuring again - And I am skeptical, until I see the turn register actually working.
5) Having to implement a "stop turn" choice is awkward for the players, but necessary because otherwise they could easily miss when their second turn started. I really hope there is a way I could pre-calculate all the positions, so each turn would be a pair of choices (from to).
(I managed it almost using neutral pieces on the sites to select, but it was very heavy and took many seconds to compile, and had problems with remembering duplicate values, making it execute slowly as well. It also gave a really hard to read record of the moves, due to the decisions affecting dummy pieces. -- In the end, I abandoned it and the attached implementation is the most practical I can manage.)
6) Given that it is multi-step, It would be nice if the player setting of using only the (to) locations actually worked for the continuation moves, instead of requiring the selection of the last To position each time. - Is that a player issue? how does one script such that that can happen?
RE: Throngs (multi-step approach) - Eric Piette - 01-29-2021
Hi,
Ok, I am adding it to the experimental category. It will be in the next release.
For the warning you explained in the other thread, that's because the mover is equal to 0 in some moves, I will look why, but that's not related to your description. But that does not have any impact on the logic, so if you see that in other games just warn me in order to take a look why that happens, thank you!
Regards,
Eric
RE: Throngs (multi-step approach) - Eric Piette - 01-29-2021
Hi,
Ok I fixed the warning in our dev version. I also replaced all the "true" by "True" in your file.
Regards,
Eric
RE: Throngs (multi-step approach) - dale walton - 01-30-2021
Great! Thanks.
Off Topic, but for Hops-a-Daisy, I revised the terms in the options, and added the rulesets back in and rewrote the rules and description to make it clearer, I hope. So I am attaching it here for you to update in the next release as well.
RE: Throngs (multi-step approach) - Eric Piette - 02-01-2021
Hi,
Ok I have updated the data and the lud.
Concerning the rulesets, we are using them for research about the DLP games, so for the moment they are restricted to our use.
Regards,
Eric
RE: Throngs (multi-step approach) - dale walton - 02-01-2021
In that case, I would like the game entered separatetly under each title with the correct defaults: others wanting to play are having trouble knowing which options go with which game.
Actually it is a useful feature for inventors tracking which rule combinations are working as well.
RE: Throngs (multi-step approach) - dale walton - 02-14-2021
I had a bit of feedback on the implementation of Throngs, so I am trying to make play smoother and more understandable with a reworking to use select for the intermediate destinations.
It is now almost working. Here are some of the problems:
1) doing this with Select. - The move commands should know when from is (last To) and the previous mover is the current mover, that the from does not need to be selected, but nothing I tried could make this work.
Work-around store last To to pending or to a variable and select the destination only. result: blue dots for moves instead of red. (but if "MoveFriendly" uses (move (from) (to) ) it has red dots. and different behavior:transparent when selecting the piece.
2) to make it clear which piece is moving and how much further, I added state.
Problem for the "MoveFriendly" as in a (move....) the piece state can't be updated in the (from ... (apply..)) and the piece is thus not refreshed to show it when the first (blue dot) selection is made.
-- for consistency I tried simply selecting, then changing the piece state and MoveAgain, but
3) Piece state and variable states are either not considered as games states, or the program does not yet allow such moves to be treated as moves. It gives a Blue dot for the select, but the (set...) actions were not performed (probably because no piece movement occurred, thus on the MoveAgain, the capability of the pieces to now move was not there....
-- I did not check whether this would work with pending, but all stored variables are part of the game state and must be hashed as such or explictly excluded (But variables are needed BECAUSE they carry state information.
Thus the attached version is not working as intended for selection an existing piece on the board.
FYI, I am also using a technique of clicking on the piece to clear the remaining power not to be used, rather than a pass - this is working OK.
4) Misc, that I despair of isolating for you, so just mention in passing:
In the process of changes, I noticed problems with using a condition to change a variable, that in a subsequent state before the decision, was used in another condition. This failed differently when using do to make the conditional assignment and when using the then clause of the first if.
It gave an if you see this warning in a implemented Ludii game... warning for player 0
I avoided the problem by restructuring the code.
I have previously found (then clauses as part of (and), - after the choices - , execute multiple times as evidenced by dupilcate variable assignments showing in the moves, I also try to avoid this construction .....
RE: Throngs (multi-step approach) - dale walton - 02-15-2021
------------------
Edit: I am also attaching the version that works for friendly moves (and the A/B AI seems to be playing half sensibly, so that is a big plus)
The issues for this version :
Select + fromTo where (to is (last From) form the select would like red move dots as the select was used to define the destination instead of source.
Also how can I show the pieces in a state > 0 as transparent?
FriendlyMoves based on move from / to would like a state update prior to the destination election to show the number properly so that people can see its power without turning show moves on.
RE: Throngs (multi-step approach) - dale walton - 02-16-2021
Minor update: The original rules state "must add a piece during your turns after a FORCED pass," which means the winning player may keep filling in until his passing would be forced, and then the other player must fill until there are no more plays left. (could be slower if the losing player purposely gives away position, but ultimately ends.
The implemented rules were, "must add during a turn after after a player CHOOSES to pass," which in some very rare cases, especially on larger boards, means a player might have more territory total, but more left to fill, and thus could choose to force the opponent to fill end end the game before he won, or to create a draw. This is the leader choosing to lose or draw, by is not the exact same outcome as the original intent.
Thus I modified the script to be, "must add during a turn after after a player CHOOSES to pass, IF POSSIBLE." - which ends the game in a forced double pass (i.e. no moves left) because it seemed safer than allowing passes without consequence generally, and then testing for a forced pass required by the original as a reason for restricting the next player's play, and the optional pass was already implemented.
None of this has impact on the game, only on the manner and degree to which a game can be stalled. - Passing is never a strategic thing to do.
The updated file is attached.
RE: Throngs (multi-step approach) - dale walton - 02-17-2021
Trying to use the above for correspondence style play, and relogging in after a unrelated crash while this was open, I got the following errors showing on the screen:
(My opponent does not seem to be logged in at the time. Those are my previos moves shown as errors.
Selected illegal move: [[Add:type=Vertex,to=6,what=1,decision=true], [SetNextPlayer:player=1]]
Selected illegal move: [[Add:type=Vertex,to=85,what=2,decision=true], [SetNextPlayer:player=1]]
Selected illegal move: [[Add:type=Vertex,to=9,what=1,decision=true], [SetNextPlayer:player=2]]
Exception in thread "AWT-EventQueue-0" java.lang.ArrayIndexOutOfBoundsException: 0 >= 0
When I logged out again it said my hashcode didn't match, but I didn't get a screen copy of that.