The Rhino already existed as a piece in the fairy-set-view.js, in the main branch that I cloned from GitHub. The cbRhinoGraph function provides the move graph for the piece that is now customary called Manticore, but for which everyone appears to use the rhino image in 2d diagrams.
I wonder if I should make a function cbBetzaGraph(geometry, betzaString) that could be used to implement arbitrary moves. E.g. cbBetzaGraph(geometry, 'BN') to get an Archbishop.
I was able to implement Chu Shogi entirely with the aid of the fairy-move-model.js; it needed no special JavaScript code in its own model file (other than the usual promotion instructions). It is a bit annoying that Jocly does not automatically use a flipped graph for the black pieces. This means that many Shogi pieces need to be defined as different types for black and white. Which again causes complication of the promotion rules when a symmetric piece promotes to an asymmetric one. That makes it difficult to implement a simplification for defining shogi promotions.
Things I still want to add to the fairy-move-model.js are paying attention to the move/capture flag in the definition of the second leg of the hit&run capture (this.neighbors), which now always assumes both. And definition of a burnZone graph similar to neighbors, which would be used by moves with the FLAG_BURN set, where the burning would be an automatic side effect (like Advancer capture). By default it would then only burn enemies a King step away, but by redefining this.burnZone you could also make it burn friends, or even the moving piece itself (by including [0,0] in the step set) to support kamikaze moves.
I am still doubting whether it should include support for pieces that can jump arbitrarily many others, such as the Tenjiku Shogi generals. This seems to be very game-specific, especially if blocking rules exist that depend on a ranking.
The Rhino already existed as a piece in the fairy-set-view.js, in the main branch that I cloned from GitHub. The cbRhinoGraph function provides the move graph for the piece that is now customary called Manticore, but for which everyone appears to use the rhino image in 2d diagrams.
I wonder if I should make a function cbBetzaGraph(geometry, betzaString) that could be used to implement arbitrary moves. E.g. cbBetzaGraph(geometry, 'BN') to get an Archbishop.
I was able to implement Chu Shogi entirely with the aid of the fairy-move-model.js; it needed no special JavaScript code in its own model file (other than the usual promotion instructions). It is a bit annoying that Jocly does not automatically use a flipped graph for the black pieces. This means that many Shogi pieces need to be defined as different types for black and white. Which again causes complication of the promotion rules when a symmetric piece promotes to an asymmetric one. That makes it difficult to implement a simplification for defining shogi promotions.
Things I still want to add to the fairy-move-model.js are paying attention to the move/capture flag in the definition of the second leg of the hit&run capture (this.neighbors), which now always assumes both. And definition of a burnZone graph similar to neighbors, which would be used by moves with the FLAG_BURN set, where the burning would be an automatic side effect (like Advancer capture). By default it would then only burn enemies a King step away, but by redefining this.burnZone you could also make it burn friends, or even the moving piece itself (by including [0,0] in the step set) to support kamikaze moves.
I am still doubting whether it should include support for pieces that can jump arbitrarily many others, such as the Tenjiku Shogi generals. This seems to be very game-specific, especially if blocking rules exist that depend on a ranking.