Comments/Ratings for a Single Item

If a 'prelude-model.js' is created, I'll try to use it to set timurid parameters, which will allow the declinations to be merged.

@HG: I react to this about your ram: "Well, apart from the head looking down it doesn't seem very different."

I guess we were not looking at the same piece. I had seen a ram from you where the neck was a mere vertical thin cylinder put on the surface of a sort of token. Very different from what I was showing with my link.

Today, I see different designs from you, few being more in what I was thinking, so maybe it's a misunderstanding.

I guess we were not looking at the same piece. I had seen a ram from you where the neck was a mere vertical thin cylinder put on the surface of a sort of token. Very different from what I was showing with my link.

What you describe seems the Ram that François posted here. It was not mine. So yes, it seems there was a misunderstanding, as I was thinking you referred to this one, which I posted earlier. (And which also still had problems in fixing it to its base.)

If a 'prelude-model.js' is created, I'll try to use it to set timurid parameters, which will allow the declinations to be merged.

I wonder how I could best generalize the Metamachy prelude code. In Metamachy the various options are presented as a 4x3 matrix of clickable images, each image being a 2x2 composit of 4 icons in various relative positions. For Metamachy that makes sense, as the setups to be selected partain to an area of 2x2 squares.

In general the area could have any shape, e.g. a number of pieces on the back rank, and then another layout would be more natural. So it should be able to configure both the layout of the selection panel, and the layout of the individual clickable items in them. It could also be useful to allow accompanying texts, although the use of icons should be the principal method. (But in the Tamerid games it would be nice to have the name of the variant next to the icon-decorated buttons.)

So I am thinking in the direction of having the caller of a function that defines a prelude supply information on how the selection panel should look. A button in the selection panel could be defined by a character string as a mini-FEN. A numeric argument could indicate how many buttons should be displayed side by side.

Metamachy adapts the board-display routine to not show the configurable pieces, and then shuffles those according to the selection that was made. (Or by the AI: randomly.) This seems a round-about way of doing things; why not just leave the pieces away in the initial setup to begin with, and then just place them instead of shuffling them? That also saves you the work of taking them away! (And correcting the hash key for that...) Anyway, apart from how the icons must be painted on the buttons, it must also be specified to which square each position on the button corresponds, so that he piece can be moved there according to the selection. That can be an array of square numbers.

Because the selection might apply to both black and white, (as is the case in Metamachy) we might actually want to pass two such arrays. We should also account for the possibility that the prelude involves a number of selection events. And in whose turn these events must take place. E.g. white and black might be allowed to each chose their initial setup independently. I think Jocly enforces strict turn alteration, so it could be needed to skip some turns. (I think Metamachy already does this: black selects the setup, so the game must start with a dforced pass for white.) And it must be possible to provide a routine for the AI to make the selection, which would be run instead of showing the selection panel when the selection happens in the AI's turn.

Perhaps something like this:

Model.Board.Prelude = [ // sequence of panel descriptors in an array
  {
    who: 1, // show during white's next turn
    panelWidth: 4, // 4 buttons on a row
    setups: ["KQ/LE", "KQ/EL", "QK/EL", "QK/LE"], // the 4 options, and how their buttons look
    squares: { // where the 4 pieces go
      "1": [14,15,4,5], // for white
      "-1": [84,85,94,95] // and for black
    },
    ai: function() {  return Math.floor(Math.random()*4); } // how the AI would select
  }
];

clear syntax

I did it slightly differently: the prelude property in the game definition is now an array of objects like the one I proposed, except that I dropped the 'who' property. Each position in the array corrsponds to a turn, so it is already obvious who is on move for each prelude 'stage'.

If the array item is a zero, that turn will be passed; this is for allowing two different selections in a row by the same player, or black starting to make a selection.

I copied most of the code for the prelude model and view files from Metamachy, replacing the hard-coded locations and sizes of the selection panel and buttons by values calculated from the prelude definition. There is one thing I do differently, though: in Metamachy all pieces start on the board in a default location. (It appears this is important for them to show up later). The display function is intercepted to suppress the display of the pieces to displayed, and when a setup is selected, the pieces are first removed, and then placed back in another constellation.

As we want to be able to select from a wider range of pieces than actually has to be placed this same method could not be used anyway. So what I do is not shuffling the pieces, but 'promoting' them by altering their type. As I noticed that Jocly sorts the piece list by increasing value of the piece type (which does not seem to be essential, as on promotion during a game it doesn't resort it, but it could have efficiency ramifications for the AI), I resort the list afterwards. (This required a small change in base-model, to make the sorting available as a separate function.)

So you would typically start with pieces in all locations where you want to place any, it doesn't matter of which type. The prelude then assigns them the types that were selected for the square they are on.

If you would want a square to appear empty before the prelude (as is done in Metamachy) this could be achieved by initially placing a piece there of a type that has an invisible image. Or perhaps better, that shows up like a flat marker (a checker?) with a question mark on it. That way makes it clear which squares you are making the selection for, if there are more empty squares than pieces to place. (As is the case in Metamachy!) I will see if I can make the prelude-view automatically add such a piece to the set that is in use; in the piece-drops sub-model I do provide flat 'pieces' with a number on them, which can be put on the holdings squares to indicate how many pieces of that type you have in hand.

I tested the thing on Timorid, by adding to the game definition:

prelude: [0,{
  panelWidth: 1,
  setups: ["XQX","HQH","XHX","QHQ"],
  squares: { 1:[15,18,20], '-1':[123,126,128] }
}],

with some (nonsense) alternatives for the setup of Ships (X), Queens and Griffons (H). The 0 indicates that white passes his first turn, so that the selection is done by black (and randomly picked if the computer plays black). This give the following selection panel:

A complication is that asymmetric pieces must be defined as separate types for white and black in Jocly. This has always annoyed me, and perhaps we should fix this one day (by assigning every type two graphs, one for white and an (optionally different) one for black. Anyway, for now I solved it by allowing an optional property 'blackOffsets' in the prelude objects, which would be an object that for each relevant piece type optionally specifies how much should be added to the type number when it is black.

I kept the layout principles of the selection panel the same as was used for Metamachy: one icon size between the buttons, and half that between button and edge. This looks a bit spacey when the buttons are only a single icon high, like here. On the other hand, it would offer space to display a text under the button; perhaps I can manage that. (This would require a new optional property in the prelude object, e.g. 'subscripts', and array that contains a string for each setup.) The layout might need a larger margin at the bottom for that, though. (And perhaps there could also be a larger margin at the top, to allow you to display a message there over the full width of the panel, fiven by an optional property 'header'.)

It seems Jocly never draws any text anywhere. So I cannot find an example of how to do that.

It would be possible do copy an image to the selection panel that has the desired texts already drawn on it, and use that as background for the selection buttons. Perhaps I should make an optional property in the prelude objects for that.

[Edit] I finally managed to render an image in the background. It can be specified as a 'panelBackground' property in the prelude object.

That sounds very promising. This will make it possible to reduce timurid chess to a variant with

prelude: [0,{ panelWidth: 1, setups: ["XQX","XLX","HQH","HLH","HSH"], squares: { 1:[15,18,20], '-1':[123,126,128] } }],

Well done

The Timurid family is a simple case, because they all have the same promotion. Pawn keeps promoting to Queen, even for those variants where a Queen is not in the initial setup.

I suppose that in general you cannot be so lucky. The commonly employed rule is that you can promote to every non-royal in the initial setup. That makes it more difficult to combine variants that merely differ by replacement of a piece. It would be nice to make the prelude sub-model more useful by also building in a device to automatically adapt the promotion choice depending on the selected setup.

Perhaps the prelude routine could automatically create an array with all non-royal piece types that were selected for participation in it. A 'promote' routine that returns this array when a move is found to be a promotion would then fit the requirement. And variants that don't want that would just ignore that array, and return their own, fixed array of possible choices.

Or, with a slightly different approach: the 'promote' routine could get the array it returns from a variable outside itself, existing in thegame-definition object. (The routine returned by cbPiecesFromFEN already does that, in the form of the property promoChoice.) The prelude objects could refer to that array (as they are also instantiated inside the game-definition object), e.g. through a property 'participants', and then change its content As opposed to replacing it by a new array) based on the user's selection. So that the promotion routine will use that adapted content. If this is not desired you simply omit the participants property from the prelude object.

[Edit] Also here the color dichotomy is a pain in the neck. With asymmetric pieces you could not use the same set of promotion pieces for white and black. I guess it is really urgent to fix that problem once and for all.

[Edit2] I suppose we can do without an optional blackTypesOffset. The prelude routine knows whether it is placing black or white pieces, and when it looks up the type for a certain piece ID, it can use the convention that white uses the first such type it encounters in the pieceTypes list, and black the last one.

Let's do it like this

If this prelude is also used as a second-level variant selection, I suppose it would be annoying if you would have to make the selection again each time you press 'Restart game'. So I now added an optional property 'persistent' in the prelude objects. If it appears with value true, the dialog will only appear in the first game after the variant is freshly selected, and once the user has made the selection, it will automatically pick that same selection in subsequent games.

As to the asymmetry issue, I think that for now the best solution is to add an extra 'blackParticipants' property, and make the other 'participants' array only contain all the piece types that participate as white pieces. In games without asymmetric peieces (other than the Pawns, which would never be in the array) or unequal armies, that would also be the list for black. When blackParticipants is present, it will be updated to contain the present black pieces. So it is up to the implementor of an asymmetric game to decide how he will program the promotion routine, and has the option to have any prepared arrays he uses in the process automatically updated for the selection.

I am not sure if it would ever make sense to combine games with different castling rights into a single group. If I think of the 10x8 games Capablanca, Gothic and Bird could be easily combined, but Embassy has free castling, Janus extra-long castling on the Q side, and Carrera has no castling at all. I suppose it would be possible to let the prelude object also contain an array of castling definitions that would be picked together with the corresponding setup. I guess we should not overdo things. (But this is actually very easy to implement.)

If it's easy to implement, then it's probably worth doing...

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.

It's a good idea to provide an example. It's the best way to ensure that the code is understood and used.

I pushed everything I have to the pullreq branch now. Capablanca Chess appears to work for 10 variants now, selectable through a prelude: Capablanca, Gothic, Bird, Carrera, Embassy, Ladorean, Grotesque, Schoolbook, Univers and Janus Chess. There is a large variety of castlings involved (2-step, 3-step, and since the initial King location also varies, which requires a different castling descriptor in Jocly, that already makes four). Carrera has no castling (at least that was easy), but there is no standard support for flexible castling, so I had to implement that myself.

Apart from the buttons with the icons indicating the pieces between the corner Rooks, I used a background image with the names of the variants:

A blemish on the implementation of flexible castling is that, after you select the King, it highlights the Rook for the 2-step castling, and the King destination for 3 or 4 steps. (This because the standard way for Jocly to enter a castling is highlighting the Rook, but obviously you have to use something else if more than one castling with the same Rook is possible.) This looks a bit unnatural. It would be better to let all castlings be indicated by the King destination. But for the tabulated castling in the castle field Jocly does it the way it always does it, highlighting the Rook. And since the extra castlings are defined relative to the tabulated castling, one of the castlings has to be tabulated, and then the Jocly standard code would offer that as a choice.

I suppose I could try to tabulate a 1-step castling, and prevent that Jocly tries it by removing the 'castle' properties from the Rooks. The standard code will then think there are no pieces to castle with, and ignore the tabulated 1-step castling!

Congratulations HG! This is nice.

10 variants in one, well done. I will try to draw inspiration from it for the variant timurids.

I updated the pull request with your contributions.

A suggestion for chu shogi would be to use the same representation for the side mover as in minjiku to facilitate learning (for example side mover: machine, reverse cart: mini tower, soaring eagle -> aigle, horned falcon -> hawk).
If we duplicate the sprites (wikipedia-fairy-sprites) in shogi/tenjiku-sprites.png we could even add the tiger and the wild boar, here is what that would give

Scirocco is working well, will you update the visuals? do you want me to do it?

Otherwise I played a lot of minjiku which I find very interesting, in the rules which are well done, it would be a useful addition to add an explanation on the "area move" that is mentionned.

I am still a bit shocked by how much trouble I had to make the free castling work. I think I am going to refactor the way castling is implemented in base-model.js; it currently is quite inefficient.

I will make the Scirocco visuals.

it's not surprising that castling takes a little time to refine

For my part, the integration of a prelude for a parameterized version of timourides went smoothly.

Thanks for everything, it's better this way.

For now I kept castling mostly as it is, but I made base-model support flexible castling as well. This required only a tiny modification. A castling spec can now also contain a property 'extra', which must be a number indicating how many more castlings that particular King/Rook pair can do besides the indicated one. These extra castlings make the King progressively take extra steps in the same direction (and the Rook fewer, so it ends in the same relative position to the King).  So you would put the castling with the shortest King move in the table, and to enter this castling you would have to click on the Rook as King destination.

This was already how Jocly did it if there was a single castling And it is convenient in case  the shortest allowed King castling move is 1 step, as it removes the ambiguity with the normal King move. The additional castlings must be entered by clicking on the King destination. This is a bit confusing if the shortest King move is not a single step, though. To cure that I have made it such that when you specify a negative number for 'extra', it interprets it as its absolute value, but suppresses the castling that was actually specified. So you can specify the 1-step castling in the table, which could then be entered through clicking the Rook, except that it will never be generated. But this forces all castlings that are generated to be entered through clicking on the King destination.

are we going to remove carrera, gothic and janus? or are we going to duplicate config_view_js_30, which is shared with capablanca in index.js?

Well, it seems impolite to delete work from others. Perhaps we should leave that decision to Michel. So I suppose we do have to duplicate the shared config array.

Which is sort of a pity, because it does not happen often that one can share config scripts. This seems a flaw in the building process. I suppose the reason to have these config scripts is that the actual game descriptions only have to refer to a few of those, which are shared by many. Otherwise they could just as well have been written inside the game descriptions themselves. But the fact that almost all games need dedicated model and view files sort of spoils that. If the building script would be clever enough to combine the game-specific files mentioned in the description with shared descriptions of all sub-models they are based on, it would be much more useful.

Now that cbMoveMidZ has a default that is almost always satisfactory, the view config scripts would need less 'personalization', so perhaps those could be shared on a larger scale now.

And for something completely different: this was an easy one. But it could still be useful: