Comments by HGMuller

OK, I solved the problem with the extraneus piece images. What wrecked it was the dot in graphics.dir. The code below assumed that everything behind the dot was a filename extension. So it though that "dot/alfaerie/wfortress" already was the extension, and that it did not need to add the ".gif" that was the next part of the name.

Now all Diagrams that use an extraneous image in the graphics.dir folder should work again, whether they use betza.js or betzaNew.js (after browser-cache refresh).

You should define separate pieces, with and without the sideway move, and then promote the latter to the former when it reaches 5th rank trough a morph.

I swapped the lines now myself.

[Edit] And they now also all use the tenjiku sprites. For Mini-Shogi this is not ideal, though, as the variants of regular Shogi need many different Gold Generals, rather than just a promotable and an unpromotable one. So I had to improvise, and used the Man symbol for the promoted Silver.

Well, for one o is already implemented as this proposal describes, and it would break backward compatibility to change it. It is also often used in combination with other modes, such as m, which would require the a to go over into a next leg. If p' would be introduced for friendly hopping, as a cleaner replacenemt for the dau kludge, omcp' would be an often required combination, which now had to be spilt because of the required u. (But then again, introduction of cc for active burning (or the colon notation) would make that obsolete.)

I don't really see what you try to save here. Get rid of the single a that is needed between o and b now?

The oab... probing doesn't seem sufficient for an Edge Hog, btw. At least, I suppose a2-a7 would be a valid move for that, but at both ends the adjacent square on the ray would be on board. I suppose the way to implement an Edge Hog is through morphing: split it into two types, and morph type 1 to type 2 on edge squares, and type 2 to type 1 elsewhere. And make these non-edge squares inaccessible to type 1. So morph=E/E!!!!!!E/"/"/"/"/"/E for type 1, and morph=/.EEEEEE./"/"/"/"/"/ for type 2.

It seems a very recent invention.

Currently you cannot even have more than one spell in the entire game. So anti-spell spells would not be useful.

That is true. The sandbox still uses betza.js, and only betzaNew.js can handle moves that need more than 3 clicks.

I am not sure why I haven't upgraded that yet.

This is not something that can be achieved in just a few weeks. But yes, I have been working on it. (Sadly interrupted by an emergency that we have to move the TalkChess server before the end of the month, because the current one will get off line then.) I have started a kind of blog on it on takchess.com, to report the progress, and occasionally receive feedback.

The plan is to write a compiled C program that, when started by the user, installs itself as a HTTP server, so that you can surve to it through the browser. The Interactive Diagram on a page you view on this server could then request moves from it, instead of using the JavaScript that is running in the browser. I have already tested out this setup, by using the MicroSoft model program for a TCP/IP server, and adding the code needed to serve ordinary files from the directory it was started in. The idea is to define one filename (say "engine") as special, and not treat it as a file, but as a command to run the engine code, and output a move.

I am still busy designing a sufficiently powerful engine. I could have just translated the existing JavaScript code to C, counting on the larger speed, but the JavaScript AI has many design characteristics that would also slow down a C program. For that reason, as well as to make the project interesting, I wanted to try a completely different design:

Every piece would get all its potential moves tabulated. That is, every leg of a move would get the squares it visits (indicated relative to the piece) put in a table when the variant is initialized, with the maximum length it could have on a board of the given size. (So on 8x8 a Rook would get 4 moves, each consisting of 7 squares.) During play these tabulated moves will get associated with a board square, depending on where the piece stands, or, for a continuation leg, on where that leg starts.

This data structure takes the place of a conventional move list; retrieving captures from it will be done via the square they are associated with. This way you only have to change the moves of the pieces that were involved in a move (re-associating or deleting their moves, and those of pieces that were discovered / blocked), while most pieces will keep the same moves. That becomes particularly advantageous in large variants.

I thinks it adds nothing. At best the AI would come up with a representation that even an idiot could come up with, and then draws a statue of it with such an abundance of detail that it becomes unsuitable for use in a game, and could only serve as an ornament. And if we are not so lucky it comes up with something embarrasingly ridiculous for representing both the name or the move. As is the case here.

Interesting. This is probably a bug; it should not be able to 'pick up' empty squares, but the highlighting might create the impression that the square is not empty.

BTW, I did some more work on the Play-Test Applet 2.0. It is now possible to also place win squares on the morph board (through the red and orange buttons). And I tried to make it clearer through background coloring what elements on the page belong together.

Do there exist pieces that need this?

It seems to me it can already be expressed by inserting an extra slider leg in the same direction for making up the difference. Like [R?fR-isR] for a hook mover limited to the forward quarter sector.

I don't think it is a good idea to invest in (and spend resources) merely simplifying cases that almost never occur.

'Wedges' are awful. They make the the pieces look more alike than different, and take up valuable space that could have been used to express the difference. Distinguishing sides by color is infinitely superior than distinguishing sides by orientation, as the brain is hard-wired to recognize it by parallel processing. There really is no significant difference between playing with traditional kanji pieces and playing with wedge-like pieces with other inscriptions, for a game with so few piece types as Shogi; they equally suck, for the same reason. But due to the rules of Shogi and physical limitations they are a necessary evil for over-the-board play.

If we would prpose to orthodox Chess players that they should draw wedges around the pieces in their diagrams, they would laugh themselves silly, and think we are insane. And there is no real difference between Chess diagrams and Shogi diagrams; the purpose is exactly the same.

I wanted to reserve @ as atom for indicating dropping. Single or double quote behind a modifier was proposed for friend-only or foe-only (e.g. on p). For grouping of atoms I would use braces {} rather than overloading the parentheses. But  I like the double-quote idea better (except that I would use &, as I thend to interpret quotes as suffixes of the previous symbol), as meaning 'same group of modifiers as previously'. I don't think that would be very useful in the bracket notation, though, as there will never be very many modifiers on an atom there. And perhaps it is more useful to focus on a full implementation of the bracket notation than trying to keep the a notation bearable through all kind of quirky tricks.

And one can also look at it this way: an unwieldly Betza notation is a very useful 'red flag' to indicate you are attempting to do something that you really should not do. The complexity of Betza notation reflects the complexity of conceiving the moves when playing, and perhaps that is a good thing.

Game Courier handles this with a variable called $flip, which when set to true switches the pieces for the upsidedown orientation. You might do something similar in Jocly.

I cannot speak for François, but it seems to me you severely over-estimate our abilities to modify Jocly. It is not a program that we wrote ourselves. Implementing new games is one thing, because the original developer intentionally tried to make that easy, and published tutorials for how it should be done. Altering the Jocly core is a completely different matter.

Looking at the code there makes me realize that I only master about 20% of JavaScript (the part it has in common with C); trying to understand the wizardry used there is somewhat similar to reading a Chinese text armed with only the knowledge of the Latin alphabet.

So in short: doing what you propose would be approximately as difficult for me as it would be for you to do it yourself, and comparable to the task of rephrasing one sentence in the Chinese translation of the bible...

I was thinking of something like dabaubR where each successive leg should not be longer than the previous.

If I understand this correctly that means a Rook that relocates the friendly piece at the end of its extrapolated move to any of the squares it passed over. Requiring a certain order of the intermediate 'transition squares' is difficult for back-and-forth movement, but comes automatic when you always move in the same direction. E.g. the Valkyrie in Odin's Rune Chess is basically a simplified version of what you use here, which can ony relocate a piece on its destination. Rather than first picking off the piece, and then moving back to the point where you want to unload it, (which would require length restrictions to not overshoot the origin), I described it as first moving to the unload square, and then continuing to the target ([Q-udQ] or  afudQ). That automatically guarantees the unload is between origin and destination.

So in the case you describe you could at least first move to the unload square. Unfortunately there is no such freedom for the destination; this always has to come last. So you would get an m slide to the unload square, fud slide to the piece that should be relocated, and then an m slide back to the destination. The 3rd leg should be shorter than the 2nd, which you can enforce by making the last leg an i leg, and split the 2nd leg into two: [Q-uQ-dQ-ibQ] or afuafdaibQ. Another way to look at that is traveling origin - unload - destination in the same direction (to enforce the order), followed by a friendly rifle capture in that same direction.

(I think that this is what Bob had in mind too, but he wrote the u in the wrong place.)

Note that even the Japanese don't draw tiles around the kanji when they publish diagrams (e.g. tsume puzzles).