Well, it is just a matter of including an extra optional array with as many members as there are setups, and copy the element corresponding to the selected setup to the game definition's castle property. The one who wants to use it must worry about supplying the castling specifications, which are rather lengthy in themselves. But many setups will likely share the same definition, so the array can just refer to that definition multiple times.
This same method could in fact be used for any game parameter, to make it dependent on the chosen setup. You could even add arrays of functions, and call the function for the selected variant as soon as it is selected. This user-supplied function then could make arbitrary changes to the game definition. Or you could allow an array of promote functions, for replacing the original 'promote' function in the definition. Or a function to be called by the AI when it must make the selection in its turn, to replace the default random selection.
I am now turning Capablanca Chess into a reference implementation for the use of the prelude module for combining a number of 10x8 variants. Some of the variants I would like to include have 'flexible castling', though. And at the moment such castling cannot be specified by the castle property of the game definition, (which only allows the specification of one castling per King/Rook pair), but must be implemented by supplying a 'customGen' function to extend the move generator. So that customGen function must then not always do the same thing, and in particular for variants without flexible castling must not do anything.
The question is how it should know that. It should somehow be visible for it what selection the user made. There could be some extra property in the castling definition that would tell it flexible castling is allowed. But actually the number of the selected setup is already stored in the prelude object in the case of a 'persistent' choice, so that it can make the same choice in every subsequent game. And I suppose these kind of large rule variations would only occur for persistent choices, where the prelude is used as a second-level selection method for the variant, rather than having a variant with flexible initial position. So I guess I can fix it that way.
Well, it is just a matter of including an extra optional array with as many members as there are setups, and copy the element corresponding to the selected setup to the game definition's castle property. The one who wants to use it must worry about supplying the castling specifications, which are rather lengthy in themselves. But many setups will likely share the same definition, so the array can just refer to that definition multiple times.
This same method could in fact be used for any game parameter, to make it dependent on the chosen setup. You could even add arrays of functions, and call the function for the selected variant as soon as it is selected. This user-supplied function then could make arbitrary changes to the game definition. Or you could allow an array of promote functions, for replacing the original 'promote' function in the definition. Or a function to be called by the AI when it must make the selection in its turn, to replace the default random selection.
I am now turning Capablanca Chess into a reference implementation for the use of the prelude module for combining a number of 10x8 variants. Some of the variants I would like to include have 'flexible castling', though. And at the moment such castling cannot be specified by the castle property of the game definition, (which only allows the specification of one castling per King/Rook pair), but must be implemented by supplying a 'customGen' function to extend the move generator. So that customGen function must then not always do the same thing, and in particular for variants without flexible castling must not do anything.
The question is how it should know that. It should somehow be visible for it what selection the user made. There could be some extra property in the castling definition that would tell it flexible castling is allowed. But actually the number of the selected setup is already stored in the prelude object in the case of a 'persistent' choice, so that it can make the same choice in every subsequent game. And I suppose these kind of large rule variations would only occur for persistent choices, where the prelude is used as a second-level selection method for the variant, rather than having a variant with flexible initial position. So I guess I can fix it that way.