Archipelago
Archipelago copied to clipboard
ArchipelagoMW
ChecksMate: implement new game
What is this fixing or adding?
ChecksMate is a client for Chess played against a computer-controlled engine. Unique features include pocket pieces, fairy pieces, and random starting positions.
The client is available here: https://github.com/chesslogic/chessv
How was this tested?
The Archipelago community has never played this in any Unsupported multiworld hosted on the Discord server.
Some automated tests are available in the repository regarding some specific settings.
The author has played ChecksMate in 2 "mid-sized" multiworlds (6-15 games), 1 "large-ish" multiworld (30-40 games), and one or two dozen XS multiworlds (2-5 games). The non-XS multiworlds were async, and the XS multiworlds were sync.
Many of these multiworlds involved multiple copies of ChecksMate. ChecksFinder was common to many XS multiworlds.
If this makes graphical changes, please attach screenshots.
The following images have descriptive alt text.
Thanks for the review. The comments helped me a lot with style and even performance, and I continue to appreciate your advice.
I expect to leave this in draft until the game is involved in an Unsupported multiworld on the Discord, at which point I will be glad to receive a thorough review.
This relies on a client provided separately. I've been able to finish some dozens of multiworlds.
The base and world tests are passing. 2 world tests under the LADX folder are failing. Since my changes are limited to my folder and CODEOWNERS, it's not obvious to me what to change to support LADX. I humbly suggest that this PR may be useful in determining a style recommendation.
Haven't checked the code yet - only here because of the discord post about test failures, but Python file names are module names and PEP8 wants them the be all lower case.
All review comments are resolved. Tests are passing. I am going to review recent player and historical maintainer feedback one more time.
I plan to move this PR from draft state to review in the near to immediate future.
I am aware of some client issues (in particular that DeathLink doesn't function), but those issues would not impact the generator implementation.
Hi.
I just had a quick look at some of the code, and I see a few #TODOs in the custom state code. Without diving into the code, that gives me some pause about giving this a review yet as a core maintainer Are these #TODOs just things that would "improve" the logic for the player, or are these actual bugs/holes that could break our fill code?
By that last thing, I mean things like:
- access decreasing when an item is collected
- state.remove not being the exact inverse of state.collect
- different collection order resulting in different access
I.e. any of the things that violate the axioms that our fill code is based on
Hi.
I just had a quick look at some of the code, and I see a few #TODOs in the custom state code. Without diving into the code, that gives me some pause about giving this a review yet as a core maintainer Are these #TODOs just things that would "improve" the logic for the player, or are these actual bugs/holes that could break our fill code?
By that last thing, I mean things like:
- access decreasing when an item is collected
- state.remove not being the exact inverse of state.collect
- different collection order resulting in different access
I.e. any of the things that violate the axioms that our fill code is based on
Hello to you Vi. Thank you for taking a look at my project.
I have some automated testing which has demonstrated to me that I think it is fairly robust. Although I did not share my results directly, some additional testing I did with the fuzzer on recommendation did not turn up further concerns.
Please feel free to suggest improvements if you think the test suite could be more exhaustive. I prefer demonstrations over claims where possible, so I would refer you to the tests. However, I would claim it has been suitable in this case.