Comments/Ratings for a Single Item

The Dev appears to be a lot less vulnerable than two other well known multiple occupancy pieces, Peterson's Cobra and the wall. The rule for capturing the Dev is this: 'Devs can capture devs directly. However the other pieces of the opponent can capture the dev, if all of the four squares that dev is standing on are under threat ...' In the case of the wall and Peterson's Cobra, the entire entity is destroyed if any part of it is attacked without the whole being threatened. So the Dev suffers from weaker movement ability but this is partially compensated by greater invulnerability.

David Howe has written an essay about pieces of differing size - Growing and Shrinking: Playing with the Size of Chess Pieces. The notes to that page reference a few more such pieces.

Mark Hedden should be mentioned here as having made significant contributions to this genre of variants using multiple occupancy pieces (as well as multiple occupancy squares).

I don't know what I was thinking back then, but If I had an option right
now I would rename the 'Shogi' piece to 'Cannon' as it should be, and
I would change the figure accordingly. Same thing applies to the Turkish
Chess variant I created around the same time.

We are currently playing this game as: White plays 2 moves with different
pieces first, then each side takes turns playing 4 moves all of which has
to be with different pieces. This seems to speed up the game considerably.

I am wondering if something could be added in order to allow the mobilization of more than one piece during a turn. Perhaps have a commander unit that mobilizes a bunch of pieces that are near it, like Joe Joyce uses in his Chieftain Chess:
http://www.chessvariants.org/index/msdisplay.php?itemid=MSchieftainchess

It looks awesome, but it seems like the knights are really useless on this board and further damaged by being so far back. I think you should also try to increase your piece diversity.

Perhaps a piece with the combined movements of the knight and flamingo(1,6 jumper). The flamingo move would allow the piece to be much more mobile on the large board, it might be a good idea to restrict the flamingo move to passive only as this would allow the piece much greater mobility without too greatly increasing its attack capabilities.

The Devs here are distinguished from a group of four Dabbabas bound together not only in their (reduced) vulnerability to capture, but also in a slightly subtler way given the presence of Cannons and Vaos (here ‘Shogis’ and ‘Elephants’, though the author has since changed to preferring the conventional names): given the wording of their jumping ability as involving “one piece” between source and destination, a Dev can be presumed to provide a single two‐square‐wide mount for such a piece. A consequence of this is that a Cannon or Vao, like the other normal sliders, cannot threaten the far side of a Dev; it either targets the near side or jumps the whole thing. By contrast, a foursome of Dabbabas would be insurmountable for a Cannon (or for a Vao along the main diagonal), but the Cannon could target its far side.

Mostly something to watch out for in case anyone attempts a computer implementation

That's a good analysis of the Cannon vs. Dev dynamic.

Mostly something to watch out for in case anyone attempts a computer implementation

I've been thinking for a little while about how it'd be kind of nice to have some way of indicating a piece's increased size on an Interactive Diagram. I can think of two or three ways it might be doable, but with no more than maybe a half-dozen games on this entire site using such pieces, I doubt it'd be worth the effort (unless the new coding is no more than, say, 15-20 lines).

There are many ways conceivable for how multi-square pieces would behave, differing in the details. In the Dev case it is especially troublesome for the AI that all occupied squares should be under attack; this means the legality of moves that capture it cannot be judged on their own merits, but require examination of the entire move list. This is a problem that transcends that of multi-square pieces, btw: you would also encounter it in variants that specify some piece can only be captured if it has multiple attackers.

I suppose one could nearly implement this through custom scripting in the existing I.D. code, with the xxxTinker routine, but in a rather complex way: the routine could test whether it is called for a new node by examining the node count, and when it is clear a variable for each Dev to record which of its components is attacked, and set up an empty array for moves. Each move hitting one of the Dev components would initially be rejected, but moved to the array of reserve moves. And the corresponding Dev component would then be marked as attacked.

After generating all moves it should then be tested which Dev has all its components attacked, and the shelved captures of such a Dev could then be appended to the official move list. This can currently only be done by writing a wrapper for the move generator routine. But perhaps an official interface should be provided for the user to add a custom routine for calling after move generation completes (e.g. xxxDone).

That's only the most complicated part of the problem I could see.

The simplest way that I could see for defining a large piece for the ID would be for an area=(x,y) property defined with the piece, x being the number of spaces wide and y being the number of spaces long, and the "root" space being at the player's lower left (so Black's would be at White's upper right). The system would then limit the piece (recognizing it from the "root" space) from getting too close to the right and far edges, and keep an awareness of what's in the neighboring squares as the piece moves, especially if it's a slider. Pieces like the Wall (and Great Wall), which are asymmetrical but can rotate by moving just one end, would be handled using morph (or a variant thereof).

The icon graphic could then be expanded to fit the space (for example, on a 50x50px board a twofold piece like the Wall would be 50x100 or 100x50; the Dev would be 100x100).

Between all that and what you cited, I think it would be a couple hundred lines of code, at least. (Is there support for an "include" file?)

Is there any documentation anywhere for (or even of) the xxxTinker routine?

The simplest way that I could see for defining a large piece for the ID ...

That is only simple because you assume you only have to switch on the complex implementation that was already done by someone else. The number of lines needed to implement this in general (i.e. give every piece type a configurable size, 1x1 by default) is not very large. But they would then be executed very often, as they would appear in the innermost of all loops, doing a 2d scan of the specified area for every step in a move, where it now simply tests the occupant of a square. So it would cause an enormous slowdown in all variants, also those having only 1x1 pieces.

A better solution would be to allow custom generation for some given piece types (using X as their Betza descriptor). That would only require one simple test per piece for pieces that do not have it, which can even be combined with the test for already existing special Betza atoms such as the Imitator. So it would cause zero slowdown in normal variants, and a very tiny slowdown in variants that feature an Imitator. The custom script that would then be invoked would only have to deal with the move the multi-square piece actually has, and can ignore complexities like multi-leg, move induction, and in the case of the Dev, even sliding.

'Include files' are an intrinsic HTML feature; the betza.js script is in fact an include file. You could include as many .js files as you like in a page, or write script in the page itself. JavaScript also has the property that you can redefine routines; the last one of the same name it encounters is the one that will apply.

Since the betzaNew.js file is still considered experimental, the xxxTinker routine is not officially documented yet. (Except perhaps burried in the Comments).

That is only simple because you assume you only have to switch on the complex implementation that was already done by someone else. The number of lines needed to implement this in general (i.e. give every piece type a configurable size, 1x1 by default) is not very large.

I refer to it as "simple" as "simple from the user's perspective." I actually figured it would be a PITA to implement, and that the needed amount of code "is not very large" is a bit of a surprise to me.

Since the betzaNew.js file is still considered experimental, the xxxTinker routine is not officially documented yet. (Exept perhaps burried in the Comments).

I'll wait for this, then. Perhaps there can be a bigpiece.js in the future (whoever decides to write it; I'm going to try to learn enough Javascript to write a weirdmoves.js for this).