Greg Strong wrote on Fri, Apr 12, 2019 12:15 AM UTC:
Regarding army selection, and other setup options:
I got the impression that you would like to have a separate dialog for setting the variant-specific options of the engines, which perhaps pops up automatically after you selected the corresponding variant. This would be feasible for CwDA, but in view of the above I wonder if it would be sufficient in general.
Yes, this is what I do. It populates the dialog with any game variables that are not yet specified. There are reasons why they may already have values. The game may provide values, in which case they are there just as a configuration options, but the user isn't normally prompted. Or the user may have selected a game that is derived from the game which fills in the options. (You could make a new variant derived from CwDA where the armies are always both Nutty Knights plus whatever other changes.) Or the options may already be specified because the user has opened a saved-game file, which of course must contain this information along with the game.
You raise a number of other things though which could certainly be considered related. For games where players take turns making choices or placing pieces, I view this as part of the actual game. Ideally, the GUI prompts you when it is your turn to make a decision. And the computer's clock should certainlly be running while it is considering its own choices. That said, I have not implemented anything like this yet. I haven't implemented any of the games you mention... And for some choices, it may not be obvious how they would be communicated in the protocol. For placing pieces, though, the existing @-notation for dropping pieces seems like an obvious choice. This does, of course, require a lot of new code... I agree it could be considered an "ugly" problem from a code-writing perspective.
In the latest XBoard I tried to expand the possibilities by allowing the engine to request opening of its entire settings dialog (as defined at that time) 'spontaneously'. So it could redefine its option list to define a dialog for the purpose, starting with feature done=0 (to temporarily remove its normal options), and end with done=2 (the forced popup request). This could have two comboboxes in it for the available armies, or (for Musketeer chess) comboboxes for selecting piece types and the files at which they would gate, etc.
Having this come from the engine just does not make sense to me. There are potentially two engines but only one GUI, so it seems to me the GUI should be "driving the bus" here. Which engine makes the request? What if the other engine doesn't support the same armies (or other options)? You could just pick one engine and stipulate that to run a match between engines they must support the same things (or that the use will only pick options supported by both.) But then the GUI needs to tell the second engine, so the options would need to be named the same... It seems this approach still has game variables, and the GUI still must have an understanding of this concept to facilitate the hand off. I think it is more straight-forward for the GUI to know which game variables and associated options the engines support, (the engines announce this anyway), and present the user a choice of the options both support.
I'll hold off on addressing the other topic for the moment. I don't have enough time at the moment to think through it all and draft an intelligent response.
Regarding army selection, and other setup options:
Yes, this is what I do. It populates the dialog with any game variables that are not yet specified. There are reasons why they may already have values. The game may provide values, in which case they are there just as a configuration options, but the user isn't normally prompted. Or the user may have selected a game that is derived from the game which fills in the options. (You could make a new variant derived from CwDA where the armies are always both Nutty Knights plus whatever other changes.) Or the options may already be specified because the user has opened a saved-game file, which of course must contain this information along with the game.
You raise a number of other things though which could certainly be considered related. For games where players take turns making choices or placing pieces, I view this as part of the actual game. Ideally, the GUI prompts you when it is your turn to make a decision. And the computer's clock should certainlly be running while it is considering its own choices. That said, I have not implemented anything like this yet. I haven't implemented any of the games you mention... And for some choices, it may not be obvious how they would be communicated in the protocol. For placing pieces, though, the existing @-notation for dropping pieces seems like an obvious choice. This does, of course, require a lot of new code... I agree it could be considered an "ugly" problem from a code-writing perspective.
Having this come from the engine just does not make sense to me. There are potentially two engines but only one GUI, so it seems to me the GUI should be "driving the bus" here. Which engine makes the request? What if the other engine doesn't support the same armies (or other options)? You could just pick one engine and stipulate that to run a match between engines they must support the same things (or that the use will only pick options supported by both.) But then the GUI needs to tell the second engine, so the options would need to be named the same... It seems this approach still has game variables, and the GUI still must have an understanding of this concept to facilitate the hand off. I think it is more straight-forward for the GUI to know which game variables and associated options the engines support, (the engines announce this anyway), and present the user a choice of the options both support.
I'll hold off on addressing the other topic for the moment. I don't have enough time at the moment to think through it all and draft an intelligent response.