Comments/Ratings for a Single Item

Actually while testing with the interactive diagram I have noticed some undesired results. So I'm modifying a bit the game. Please allow me some more time.

To the editors. Now this article is ready for review.

May an editor look over this article?

Hello HG,

The Grand Apothecary alert game automatically generated preset work well as far as I can see.

Now I need to make my other two Grand apothecary chess games work. When I paste the diagram designer code into the playtest applet, the applet gets it, but I cannot for some reason press the game code button.

I cannot test that when I don't know what exactly you are trying to paste.

files=12

  ranks=14

  symmetry=none

  holdingsType=1

  promoZone=4

  promoChoice=!P!X*N*B*L*E*Z*R3*Y3*F3*J3*D2*Q2*I2*T2*U2

  graphicsDir=../graphics.dir/alfaerie/

  whitePrefix=w

  blackPrefix=b

  graphicsType=gif

  squareSize=54

  hole::::a1-l1,,a14-l14

  pawn:P:mfW*fceF:pawn:b4-k4,f5,g5,,b11-k11,f10,g10

  berolina:X:mfF*fceW:berolinapawn:a4,l4,c5,j5,,a11,l11,c10,j10

  king:K:KisO3isO4isjO2isjO3:king:g2,,g13

  rook::::a3,l3,b2,k2,,a12,l12,b13,k13:1

  queen::::f2,,f13:1

  bishop:B:B:bishop:c3,j3,,c12,j12:2

  knight:N:NmZ:knight:b3,k3,,b12,k12:1
  mamluk:L:WL:/graphics.dir/alfaeriemisc/compounds/%camelwazir:d2,i2,,d13,i13:1

  siege elephant:E:FAH:/graphics.dir/alfaeriemisc/good/%elephantferzrook:e3,h3,,e12,h12

  cannon:Z:mRcpR:cannon:a2,l2,,a13,l13

  knightrider:Y:NN:nightrider:c2,j2,,c13,j13:1

  caliph:H:BL:/graphics.dir/alfaerie/%camelbishop:f1,g1,,f14,g14
  vulture:F:afafafsKafsafafKafafraflKafaflafrKafraflafKaflafrafKmA:bird:d3,i3,,d12,i12

  joker:J:fI:fool:e1,h1,,e14,h14

  Dragon:D:FyafsF:dragon:f3,,f12

  Thunderbird:T:WB3afafyasfF:/graphics.dir/alfaerie-fpd/%thunderbird:h2,,h13

  Unicorn:U:BNN:unicorn:e2,,e13

  Firebird:I:FR2afyasfW:/graphics.dir/alfaerie-fpd/%firebird:g3,,g12

  symmetry=mirror

  shuffle=:B:N:E:F,QUT,DI,:L:Y

  maxPromote=2

  royal=3

OK, my bad. I had made a change recently in the script that flushes the GAME code, to allow for variants that start counting ranks at 0. The diagrams you can define with the Play-Test Applet always start counting ranks at 1, but when I added the possibility to paste existing diagrams into the Applet, this was no longer true. With as a result that the locations of the castling partners were not calculated properly. But when I corrected that by adding the variable rank1 to the internal rank number, in one place I had accidentally typed rank11. Which crashed the script.

I have deleted the spurious 1, and now it works again.

Thanks, HG!

I have created presets for all the 3 games. Now I'm going to test them. Hopefully there are no errors.

There is some problem with the rank labels. I had tried to change it from 0-13 to 1-14 but there are still problems. When 0-13 was the case I had brouhaha squares on rank "1" and pieces on rank "0" were no able to move. This is not suppose to happen. When I had changed it to 1-14 it was even worse. I could not understand what is going on. All hell broke loose.

If you post a link to a preset that doesn't work as it should, I can have a look at it. I am a bit surprised the rank labeling matters much. Of course in the Interactive Diagram the firstRank parameter should be consistent with the lists of square coordinates you give for all the pieces. But if the initial setup looks OK in the Diagram, producing GAME code from it would depend on firstRank only in very few (and non-essential) places. The initial position is defined by FEN, and thus doesn't use any square coordinates. The only info that is encoded as square coordinates in the generated Pre-Game code that I can think of is the location of the castling partners. But even if that would be completely wrong, it just means that you can never castle.

HG.

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+1&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+2&settings=Applet

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+3&settings=Applet

Those above are the presets. I noever specified a fist rank parameter. What seems to be the problem.

So what is wrong with those? They seem to work normally when I use them in 'Play' mode.

I can't reproduce said bug. Maybe it was something temporary!

But I had a new bug here: https://www.chessvariants.com/play/pbm/play.php?game%3DGrand+Apothecary+Chess+3%26settings%3DApplet

Neither the siege elephant or the mamluk works. Also in the the three games as I had said below the non-joker pieces on the brouhaha squares cannot move. I have not checked the jokers.

I notice that the piece labels for Mamluk and Seige Elephant both start with a period. Have you tried whether the Caliph works? (It also has a label starting with period.)

@Fergus: can there be a problem with functions that have a name starting with a period? The GAME code generated by the Play-Test Applet generates functions with the name of the piece label, which return the start index of their move description in the legdefs array.

I can confirm that the Mamluk and Seige Elephant properly work when I replace the symbols used for them (.JW and .ET) by an ordinary Camel and Elephantrider, the labels of which do not start with a period (J and EE). In the startup FEN and in the functions defined for the pieces near the end of the Pre-Game section.

@Fergus: Did you see my question about this, amidst the flurry of postings that appeared yesterday?

@Fergus: can there be a problem with functions that have a name starting with a period?

It would appear so. I ran this code to test this:

def cat * 2 #0;
def .dog *2 #0;
set p fn cat 8;
set q fn .dog 8;
dump;

And the result I got was this:

array(1) {
  [0]=>
  array(1) {
    ["main"]=>
    array(2) {
      ["p"]=>
      int(16)
      ["q"]=>
      array(2) {
        [0]=>
        string(1) "8"
        [1]=>
        string(2) "*2"
      }
    }
  }
}

This may be because GAME Code uses the period to separate array elements from arrays. I would recommend using aliases (old way) or rewriting the $piece array (new way) to avoid the need for writing functions with names that start with a period.

I am not completely convinced yet: in your example it is clear that the function definition of .dog is used to generate the output. I think the unexpected result is due to a space missing between * and 2 in the .dog definition.

The problem could be in onlyupper / onlylower, which I use for iterating over the pieces of the player on move for generating moves. This might not recognize the piece labels starting with the period. I guess I would have to loop over all pieces, and just test piece by piece using the fnmatch "*[a-z]*".

Of course it would solve a lot of problems to get rid of this madness of piece sets with non-alphabetic names. If I understood the 'new method' correctly, it would require help of an editor to define a new piece set in a PHP file. Perhaps we could make an adapted version of the 'all pieces'  Alfaerie set that assigns sensible labels to all pieces. Then we would never have to use anything else again.

I agree with HG. .stuff and 1stuff are a nuisance. But it probably takes a lot of work.

I think the unexpected result is due to a space missing between * and 2 in the .dog definition.

Yes, when I corrected that, .dog gave me the correct result.

If I understood the 'new method' correctly, it would require help of an editor to define a new piece set in a PHP file.

No, the new method was provided to eliminate the need to make new set files. I have now written a subroutine that will do the job once you feed it the data. It is in the include file update-piece-set, and the subroutine is called update-piece-set. Just feed it the notation you will use. To make preparation of data easier, you may feed it all the data it needs in a single array. Each array element should be a single piece label or an array including the piece label first and the new notation second. Where a piece label is by itself, it will reuse the same label for the same piece. Where it comes paired with new notation, it will use the new notation for the piece and discard the old piece label.

This method allows the designer to write the FEN code using the original labels, but within the code, it will change the piece labels to the desired notation, and it will strip the $pieces array of all pieces not being used.

You may get data on what notation to use from the user. For each piece, just include an extra field on what notation to use for the piece. When it's left empty, use the original piece label.

Where can I find this include file?

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

You can browse the available include files here.

Populating $pieces with the correct info seems like the way to go

Where can I find this include file?

It's in the includes directory. So, you just include it by name.

BTW, I did stumble on the method for defining a piece set through assigning to $pieces. Perhaps this is the best method to convert Interactive Diagrams to GAME code, as these Diagrams do specify the filenames of the piece images, the directory where these images are to be found, and the piece IDs (which can be used as labels). So it would just be a matter of dumping this internally held info in the form of a GAME-code associative array, in the code generated for the Pre-Game section.

Yes, that could work, though there is one caveat. When Game Courier is in Edit mode, it does not run any code unless someone clicks Run. This is a safety precaution to allow someone to edit buggy code that would otherwise disable the preset. Consequently, the board may not look right in Edit mode until someone clicks Run. If you use a set file in conjunction with the update-piece-set subroutine, though, it will avoid that problem. However, there could be a discrepancy between the labels used for the FEN code and the notation used in the preset.

To avoid that discrepancy, I was thinking of letting custom piece sets be stored as constants. However, constants are stored in logs, not in settings files. So, I'm not sure I have a good solution for this yet.

I'm quite interested by this possibility as I understand that this is a way to get rid of the creation of new sets. However, I'm not very skilled in coding, I mean less than you all, and I don't understand everything. Is there any example in some files?

@Greg Strong What is this list of files.txt, do they have something special ? I don't understand what means "the available includes files" ?

Sorry, I'm lost.

I don't understand what means "the available includes files" ?

An include file is a file containing programming code that is available for including in larger programs. The purpose behind this is to avoid rewriting code for different programs. Instead of writing each program from scratch, you can include include files to handle things that someone has already written code for. When writing GAME Code, you can use the include command to include the code in a particular include file. These are written as text files and have the .txt extension, which is the default extension for text files. But they are normally included without including the extension in the file name. The include files I have written are all in the /play/pbm/includes/ directory. To include one with the include command, just give its base name, which is the part before the .txt extension. H. G. Muller has written some include files in a different location, and these, I believe, are included by giving its full path and file name.

I now made the Play-Test Applet also generate Pre-Game code for defining a custom piece set, from the pieces that were used in the Interactive Diagram, when you press the GAME-code button to convert the Diagram to an automated preset. When a standard piece set was used (with the piece labels from the set used as piece IDs in the Diagram), there is no need to copy this to the Pre-Game section of the preset. But for non-standard sets it can be added to the mandatory Pre-Game code for defining the set.

The idea is that you should use purely alphabetic upper-case piece IDs in the Interactive Diagram that you will be converting. The newly generated GAME code then assocites these with the piece images that the Diagram was using.

This is as yet untested in a real preset. But the generated code looks like the example in the comment 42275. E.g. for a Diagram with just King and Pawns on the board I get:

set mypieces assoc
  P "wpawn.png" p "bpawn.png"
  K "wking.png" k "bking.png";
setsystem dir "/graphics.dir/alfaeriePNG35/"
setsystem pieces #mypieces

I'm quite interested by this possibility as I understand that this is a way to get rid of the creation of new sets.

It doesn't get rid of the creation of new sets. It just changes how you make them. Instead of writing a PHP file and having it put in the /play/pbm/sets/ directory, you can create a set using the GAME Code language.

However, I'm not very skilled in coding, I mean less than you all, and I don't understand everything. Is there any example in some files?

The only example is in comment 42275 on the Developer's Guide page. But this is an example of creating five different sets that each have only the standard Chess pieces in them. If you understand how it works, then you may be able to adapt it to create a set for a specific game. However, I might need to add some details to it to handle pieces that do not match up with pieces already in the set it is loading before running GAME Code.

Instead of creating a new set from scratch, you may prefer to work with an existing set that happens to include everything you need, then use the update-piece-set subroutine to define a new set in terms of it.

Thank you Fergus. I think I've understood the idea, also for your other answer. Not sure I'll be able to handle this right now, but I will try if I need. I feel like being a yellow or orange belt at judo and you guys being black belt. :=) Thanks also for your patience.

Hello HG,

So now rewriting the preset with the applet works?

I think it should. When you replace the non-alphabetic IDs by normal capitals, and also paste the GAME code it generates for defining the piece set into the Pre-Game section.

It seems to still be a problem given by the fact that some images are not in : "../graphics.dir/alfaerie/"

But that is not where the Play-Test Applet would take the piece images from. Does the old Diagram Wizard use that URL as graphicsDir when you select Alfaerie? I guess I should update that anyway to use the anti-aliased set. But using relative path names (not stating with slash) is not necessary, and not recommended. Because they might not work when the pieces are used from another directory.

Try deleting the leading .. (but not the /), then it should find the piece directory from anywhere.

It does not work. I'm using whole paths becuase I need those images. They are not in the default directory!

Does the link work in the Interactive Diagram? Can you give the link to the preset where you tried this?

https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+1&settings=Applet

This is the one!

The labels w and W are using paths that do not exist. The value for $dir should be an absolute relative path, not one whose value depends on another path value already being set. The value "/graphics.dir/alfaerie/" specifies a specific directory, but "../graphics.dir/alfaerie/" does not, or it specifies the wrong one, such as "/play/graphics.dir/alfaerie/". While "../" should not be used in $dir, it may be used in the location of a specific piece, because this will be relative to the absolute value in $dir. For example, w may be "../alfaeriemisc/compounds/%zebrawazir.gif".

OK, there are three problems:

1. The last two lines of the Pre-Game code have no semicolon at the end.
2. The .. at the start of the string assigned to dir in the forelast line should be deleted, to make it an absolute path.
3. The definition of the W image got totally messed up; it should be:

  W "../alfaeriemisc/compounds/wzebrawazir.gif" w "../alfaeriemisc/compounds/bzebrawazir.gif"

For this piece you made use of the % convention in the Interactive Diagram, for indicating where the white or blackPrefix should go. The script for flushing the game code does not support that convention yet, so it put the color prefixes (w or b for this set) in front of the path name as usual. I could probably automate this, but in the preset the path name has to be relative to the path assigned to $dir, and it might be difficult to deduce that from the full path name that the Diagram expects with the % convention. So I guess the best solution is to let the user, when he wants to incorporate pieces from a different folder, just post-edit the Pre-Game code generated by the Play-Test Applet for such 'guest' pieces (like W in this case).

I feel like being a yellow or orange belt at judo and you guys being black belt. :=)

The first thing that comes to mind on reading this is: "why then program at all, and not just let the Play-Test Applet generate the code for you?". But perhaps this is less easy than usual because many of your variants don't have a fixed initial position, but start with some piece placement (by black). This is not a standard feature of the Play-Test Applet, because the Interactive Diagram doesn't support it: the naturan way to implement it there is just let the computer shuffle the pieces randomly, accept the Diagram's choice when you want to play black against it, and prest 'Start Game' until you get the position you wanted to pick when you want to play black.

But thet means the GAME code generated by the Applet also shuffles randomly, instead of allowing black to pick the setup. Perhapssuch placement should be supported by the library routine for shuffling, in a way that is asy to activate by post-editing the automatically generated code. But I don't know what is the common way to enter the black choices in this case. Is that as a number of free drops in a single move?

Thank you HG. My problem is simplest than that. For a guy like me, every new tool needs some investment to get used with. I understood that the Play-test can do wonderful things and I see others using it, but I still have to devote some time to understand how to use it. It is certainly worth to do it for me but so far I have not used it yet.

My skills are limited. Even to create a simple Game Courier, it represents an effort for me to remember how to create a page that links to a GC, call the other page which presents the rule, make a diagram and link it, etc. For you, Fergus, and other editors, it is piece of cake. For me it is quite an effort to remember the "path".

For example, I simply want to make a GC for Devingt Chess, the page I made recently (btw, can someone publish it now?). Devingt Chess is almost structured like Bear Chess, so I can make code the GC easily, but I struggle how to make the page that will present it. Aargh.

Thanks for all.

It is true that every tool requires some new skills for using it. But the idea behind the Play-Test Applet is that it would make things as easy as riding a bicycle, where otherwise they are as complex as assembling your own car from parts, and learning how to drive it. Perhaps we are not completely there yet; the user still has to create th Game Courier page first, and the Applet only provides the program code to paste into it. But I have been considering the idea to also make it handle preset creation: equip it with yet another button and text entry, where you then specify the variant's names, and just have to press the button for creating the GC preset page, and opening it in play mode in a new browser tab.

HG,

At the same link before I have the absolute value to the dir like that: setsystem dir "/graphics.dir/alfaerie/";

It seems it is wrong. Where is my mistake?

You wrote "graphics.dir/alfaerie/ " instead of "/graphics.dir/alfaerie/ " in the preset. Therefore it complains that the string does not start with a forward slash.

I had tried that already and it did not work at the time. Now I saved it twice and it works. It seems that the saving twice necessity is still present.

the idea behind the Play-Test Applet is that it would make things as easy as riding a bicycle, where otherwise they are as complex as assembling your own car from parts, and learning how to drive it.

That's not quite correct. The alternative to using the Play-Test Applet will often just involve copying a preset that already works, writing FEN code for the board, assigning piece labels and notation to the correct pieces, and saving. As long as a game uses pieces already programmed in the fairychess include file, has a fixed setup, and mainly follows the rules of Chess, it should be easy enough to create a programmed preset for it without knowing how to program.

HG,

The preset (here : https://www.chessvariants.com/play/pbm/play.php?game%3DGrand+Apothecary+Chess+1%26settings%3DApplet) does not apply the shuffle algorithm as the interactive diagram does. Normally the nightrider and warlock should shuffle on the left side and then mirror in the right side and then mirror for black. Initially they were not shuffling at all.

I have added this piece of code before calling the shuffling algorithm: (Y W) // shuffleset 0 0

And now sometimes it shuffles the pieces on the same side. Meaning 2 warlock on the right and two knighriders on the left. Probably this is because I do not undersand the meaning of the 2 zeros.

HG, Have you seen my previous comment here?

@HG, In the context of my before the previous example I think the ":" symbol does not influence the preset although it works fine in the interactive diagram!

HG, If you are here please check my previous comments on this post!

HG, Are you here?

May I ask few questions:

• why is the board checkered with 4 colors instead of 2?

• is the Betza's notation for the Dragon correct? According to the textual description I would say t[FR] and not FyafsF. (I understood the Dragon is a Murray's Gryphon)

• Why is the Vulture so complex? Why not a mere compound jumper Giraffe + Zebra?

It is a matter of taste of course, but to my taste I wonder why making more complex several piece which are basically simple such as Knight (N is not enough?), Elephant (FA not enough?). Thurderbird and Firebird are very complex. I would like to play this game but with simpler rules.

The dragon is indeed a t[FR], in Betza's original notation. However, that part of it was never documented on the Betza Notation page (instead languishing on the Chess on a Really Big Board page, though it turns up elsewhere too), and is arguably a little underspecified, so H. G.'s XBetza (which is what the interactive diagram uses) specifies such multi‐leg moves in its own way. In this extension, FyafsF is indeed equivalent to the original t[FR]

The vulture afaict is mainly a longer‐range relative of George Duke's (and more recently Uli Schwekendiek's) Falcon, whose advantage over the bison (from a game design perspective) is its blockability — presumably the same is sought here. Unfortunately, due to the multiple paths to a given destination, it is quite complex to describe. Idk about the extra knight move though, that's perhaps a little gratuitous (presumably to make up for the basic vutlre's lack of maneuverability?)

I agree the birds are quite complex, if potentially interesting to play with? And whether the knight/elephant enhancements are truly necessary may be worth a playtest as well

I have difficulties to see FyafsF. OK for the 1st F, then yafsF is therefore describing the "rook" sliding part of the move? I understand "fs" in the case of a N. In the case of a F, I don't see what "fs" mean.

And this can really code when the Gryphon is sliding backward?

Finally, I don't know what the modifiers y and a are. I don't see the explanation on our page on CVP. I see on WP, I understand "a" as again, but it is quite difficult what "y" means.

All this is really too complex

The extended betza notation is explained here. The "fs" is understood as specifying a direction relative to the initial step, so it indicates that the gryphon moves, after the first step, forward and sideways relative to the direction it first moves. It is a more complex notation, but it allows for more possibilities.

I notice here that the knight's move in the rules is different from that in the interactive diagram. Which one is correct?

Apparently I forgot to add the link to the XBetza page in my previous comment; I've now added it there.

yafsF is indeed the sliding part. a is as you've found, ‘again’; fs for w's and F's is interpreted as for a king, so for an F it changes to a W direction — and ‘forward’ for anything but the first part of the move is interpreted as ‘outward’ (like Alfonso about the rhinoceros); y is a ‘range toggle’ i.e. it switches from being a leaper/stepper to being a slider. Thus, yafsF is one step diagonally followed by a 45° turn and sliding orthogonally.

Complexity is in the eye of the beholder. It's not immediately obvious (especially compared to t[FR]) but it's apperntly easier to describe to a computer (and easier to generalise), which for the interactive diagrams is a definite plus

@Aurelian: I haven't had time to visit CVP since it came back on line. I will have a look at the shuffling problem you mentioned.

@Jean-Louis: there is an explanation of y and a here. Indeed a means 'again', and y can be used only in combinaton with it, where ya then means 'again with range toggle', i.e. when the move started as a leaper (as is the case with F) the next leg will move as a rider of the same stride. fs means 'forward sideways', but the convention is that this should be interpreted in an orientation where the previous leg defines the forward direction (think of the controversy for the move of the Grant Acedrex Unicorn!). So fs deflects the path by 45 degrees, pure s would deflect by 90 degrees, bs would deflect by 135 degrees. So the ya would turn the F into B (range toggle), but a 45-degree rotated B is an R. So yafsF is an F step followed by an outward R. Without the y (i.e. afsF) there would be no range toggle, and the second leg would be an outward W step. Which would give you a Moa.

Indeed, it seems that either the knight's verbal description or its XBetza move has been exchanged with the one in the Modern game.

@Aurelian?

@ Jean-Louis, Thanks for taking an interest for my games:

1. The board is colored in 4 colors because of the fact that the nightrider is easier to visualize this way.
2. About the XBetza notation HG I think made his point.
3. In falcon chess the falcon is a piece with longer read and more end squares than the leapers (knight). I wanted to do the same, so the Vulture is done. Also over there the falcon piece is rook strength at least. I wanted a rook strength piece so I added the extra just move jumps. They are jumps as the piece would be hard to develop.
4. The knight is enhanced to keep it the same strength as a bishop (who on a 12x12 board has a longer reach). On a 10x10 board those are too much it turns out making the enhanced knight 0.5 pawns stronger than the bishop. Hopefully in the 12x12 case this will be alleviated.
5. I did not want a color bound piece for the modern elephant. Also with the extra trebuchet power it is closer to the other minor pieces.
6. I don't like the camel and zebra because they are too clumsy to use so that in these 3 games so they have short range aid. I had noticed that the short range long range piece deliver quite interesting forks.
7. The thunderbird and firebird are bent riders akin the griffin and manticore. It is just they get the bending later. They also have extra moves in order to keep them in the queen value neighborhood. I like using bend riders because they provide more strategic decisions. That is because their riding property does not allow them to be immediately useful but only in tandem with the clearing of the board.
8. I'm not sure what are you asking by simpler rules, but these games are named apothecary because of the way old pharmacists were tinkering with substances trying to make a cure. As them did I try different ideas from which some admittedly a bit crazy in order to explore many possibilities. These 3 games are my first attempt at 12x12 boards and hopefully from working on them I'll get sufficient experience for my future designs.

@ Bn Em & @ Daniel Zacharias

Thanks for pointing out the mistake with the knight. They were the result of bad copy pasting. The correct knight here is NmZ and in the modern variantion is NmHmA.

And by the way guys, I have some self criticism on my own regarding the three games. The non-pawn pieces, pawns ratio needs to be closer to one as there are many jumping pieces and strong pieces that easily cut through regular pawn chains. Also it felt naturally to have a cannon-rook battery on the edge, with berolina pawn ahead. But after a few tests I'm afraid that the player that moves the berolina first gets an advantage. Try it with the interactive diagram.

The board is colored in 4 colors because of the fact that the nightrider is easier to visualize this way.

But why not three colors instead of four? When I created Cavalier Chess, I tried a four color board, but I found that three colors works better.

@Fergus,

We have discussed this before. I like it better this way. Anyway when the preset is down I'll make a customization. Probably many would prefer 3 colors.

About the colors, have you considered something more like this?

Thanks to everyone for the explanations on the use of Betza's notation: I didn't suspect those refinements.

Above all, thanks to Aurelian for his answer and explaining his motivations. I understand that the priority is balancing the different powers on the board.

I still have to understand why a 3 or 4 colors is helping to visualise the path of a Nightrider, in any case I think I'm kind of blind for Nighriders, I just can't see their paths, I smile.

So, no critics from my side, this game has many interesting features and this is why I am interested

Thanks Jean-Louis for your interest.

@HG, In the context of my before the previous example I think the ":" symbol does not influence the preset although it works fine in the interactive diagram!

I finally had time to look at this. The preset as it was indeed ordered completely random shuffling of Y and W. Which means that YY-WW or YW-YW is also a possible outcome. The way the shufflespecs work in the preset is that the second element of the triplet specidies the set of pieces that have to remain symmetrically located, and the third element specifies the set of pieces that must be equidistributed over square shades. A 0 there means there are no such pieces (and if both are non-zero, the third element is ignored). The first element then contains the remaining pieces, and must be non-empty.

By putting (W Y) in the first element, you asked for an unrestricted shuffle. Because the first element must not be empty, you have to put one of the two there (say Y). The other (W) can then go into the second element, and will be symmetrically shuffled (either as W.-.W or as .W-W.). The Y will then be 'shuffled' over the remaining open spaces, which in this case is just placement there as there is nothing left to choose.

I am not sure why the automatic generation did not work; I haven't looked yet what shuffle string you specified there. Perhaps it failed to put one of the Y, W in the first element, and put them both in the second. Anyway, try if this works:

set shufflespecs (
  (Q V U) // shuffleset
   0
   0
  (I M) // shuffleset
   0
   0
  (Y) // shuffleset
  (W)
   0
   0 // mirror to get black
);

HG, There are four areas where pieces get randomized. And they work in the diagram. The code you had given me yesterday only has 3.

Ah, I did not really look at the Diagram, just at the preset. You can just add the fourth group to the shufflespecs array, as another triplet. You have to put one piece (e.g. Bishop) in the first element of the triplet, and all the others in the second.

I took your Diagram definition from the page source of your article, and pasted it into the Play-Test Applet to generate GAME code. Indeed it turned out that the two groups for which you wanted symmetric shuffling were not put into the shufflespecs array. The reason appears to be that you put the colon (:) to request symmetric shuffling on all pieces of the group. The GAME-code generation apparently cannot handle that. And I never noticed that, because I tend to mark all the pieces but one with a colon. The last piece then must be placed symmetrically as well, as the only open spaces that are left will be symmetrically positioned. If I removed the colon on one of the pieces in each group in the Diagram's shuffle parameter

      shuffle=:B:N:EF,QUT,DI,:LY

then the GAME code gets properly generated:

set shufflespecs (
  (F) // shuffleset
  (B N E) // symmetrized
   0
  (Q T U) // shuffleset
   0
   0
  (D I) // shuffleset
   0
   0
  (Y) // shuffleset
  (L) // symmetrized
   0
   0 // mirror to get black
);

(beware the Diagram uses other piece IDs than your preset!). I will fix the JavaScript for GAME-code generation in the Play-Test Applet such that it can also handle the case where all pieces in a shuffle group have a colon prefix. (As the Diagram itself doesn't seem to have any trouble with that.)

HG, When I try nothing gets shuffled!

When you try what? I see no change in the preset.

BTW, the GAME-code generation should now also work properly when all pieces in a shuffle groep have a colon prefix.

I had copied the code you've obtained in the preset. Isn't that supposed to work?

Well, I did not see it in the preset (link you gave earlier in this comment thread).

And no, that is not supposed to work, because it seems to use other piece IDs than the preset.

I don't understand what you mean by the fact that the diagram uses different pieces ID than the preset. I thought we had passed that. Maybe take another look and tell me what is there do be done: https://www.chessvariants.com/play/pbm/play.php?game=Grand+Apothecary+Chess+3&settings=Applet Thanks for your help!

You had not given me that link before, so I was looking at another preset. In this new one you forgot the closing parenthesis (and semi-colon) of the shufflespecs array.

I have made the modification but the shuffling algorithm still seems to get ignored. You have said earlier that the names of the pieces are different. I don't understand that. May you be a bit more specific?

It does shuffle for me. What I meant is that you gave two links, to different presets, in this comments topic, and that these use different piece IDs.

@HG, I'm not sure what is going on then. Maybe clearing my cache could help? Or the fact I use microsoft edge is a problem? But it seems it is not a preset problem.

All I can say is that when I use the link you last gave (with FireFox, or the Android browser on my tablet), and select 'Play' from the menu, I get a different start position as what was initially shown. And when I then go back to the previous page, and press Play again, I get yet another setup. And it gets shuffled in the way that was specified. So the preset appears to be OK.

Perhaps others could try to see if they have the same experience.

Oh, on Android I get correct results too! I'll just switch to that!

Now there is another problem. Once an invite is passed it cannot be accepted. If someone tries to accept the invitation (we have tried only personal) it gets an error that says the opponent won. Any idea?

I think we will need Fergus' help for this. When I use the preset in Play mode it doesn't declare game end during the first few moves. I think that proves that the Post-Game code cannot be responsible for the observed termination.

Agreed!

I have added in this game's initial position one regular pawn on each flank on the fourth row. That is because flank attacks by white where too dangerous in start positions where the black rook of the file was undefended. Also more king safety should he castle.

I have added in the notes sections explanations about why are the pieces are the way they are in this game. They are not perfect, but I had questions and I wanted to answer them.

I like it! It's always interesting to see the thought behind the choices made when designing a game.

Thanks!

Also feel free to make any comments!

The author, Aurelian Florea, has updated this page.