Another detail about minjiku: the rules don't match the sprite for the ninja. Even if you don't have time to make a 3d ninja, it would be nice to have an updated model.
I now used the Gate in the game implementation as well. This is not such a bad choice, as this piece was intended to represent the Ski-Rook, the hole at the bottom symbolizing it would skip the nearest square. I used it in Scirocco for the Wagon (which is a lame Ski-Rook). And the Ninja has a sideway Ski-Rook move. The only good idea for having a dedicated easily recognizable Ninja representation was to use a shuriken, but this is not tube-like, and would have to be made entirely by hand. (But we could have used the Star...)
Unfortunately there was a lot more wrong with Minjiku Shogi. Apparently I broke the SkiGraph routine for doing ski-slides when I enhanced it for doing the Osprey. So it was doing a normal Rook move rather than a ski-slide. This must be fixed in locust-move-model.js.
And that is not all; the flying generals do not respect the ranking as promoted pieces. The ranking is part of the piece-type definition, but to make testing of it more efficient, I copy that to the piece object, so it can be easily tested by the move generator or GetAttackers function (which is called really often). But promoting a piece just alters the number of the piece type (piece.t). It does not add or change the ranking number if that new type had a ranking. This must be fixed in base-model.js, which handles the flying pieces.
And when I am at it, I might as well provide a method for requesting 'double promotion' in base-model.js as well. Perhaps I should allow specification of negative numbers in the promotion-choice arrays returned by the user-supplied promote() routine. The base model could then interpret these as their absolute value, but whenever such a promotion is applied to the board, call a user-supplied custom routine for adapting the game state. In the Minjiku case this routine could then set the ranking of the promoted piece, and in Team-Mate Chess it could add the extra promotion piece to the origin square of the move. (Problem: the legality testing, (through cbQuickApply), which ignores promotion, might reject the move if it doesn't realize the origin square is not evacuated. But I guess it even has that in common with the ranked pieces; the promoted piece might block a flying attack that the unpromoted piece would not. This will require some careful thinking.)
I now used the Gate in the game implementation as well. This is not such a bad choice, as this piece was intended to represent the Ski-Rook, the hole at the bottom symbolizing it would skip the nearest square. I used it in Scirocco for the Wagon (which is a lame Ski-Rook). And the Ninja has a sideway Ski-Rook move. The only good idea for having a dedicated easily recognizable Ninja representation was to use a shuriken, but this is not tube-like, and would have to be made entirely by hand. (But we could have used the Star...)
Unfortunately there was a lot more wrong with Minjiku Shogi. Apparently I broke the SkiGraph routine for doing ski-slides when I enhanced it for doing the Osprey. So it was doing a normal Rook move rather than a ski-slide. This must be fixed in locust-move-model.js.
And that is not all; the flying generals do not respect the ranking as promoted pieces. The ranking is part of the piece-type definition, but to make testing of it more efficient, I copy that to the piece object, so it can be easily tested by the move generator or GetAttackers function (which is called really often). But promoting a piece just alters the number of the piece type (piece.t). It does not add or change the ranking number if that new type had a ranking. This must be fixed in base-model.js, which handles the flying pieces.
And when I am at it, I might as well provide a method for requesting 'double promotion' in base-model.js as well. Perhaps I should allow specification of negative numbers in the promotion-choice arrays returned by the user-supplied promote() routine. The base model could then interpret these as their absolute value, but whenever such a promotion is applied to the board, call a user-supplied custom routine for adapting the game state. In the Minjiku case this routine could then set the ranking of the promoted piece, and in Team-Mate Chess it could add the extra promotion piece to the origin square of the move. (Problem: the legality testing, (through cbQuickApply), which ignores promotion, might reject the move if it doesn't realize the origin square is not evacuated. But I guess it even has that in common with the ranked pieces; the promoted piece might block a flying attack that the unpromoted piece would not. This will require some careful thinking.)