That capture of any of its 'components' can already capture the Wall makes its implementation simpler than that of a Dev, (all moves can be judged on their own merits), but the fact that it has a sliding move makes it harder: one would not only have to test for blocking of other components on the destination area, but in the entire area swept by the move.
BTW, it is not clear to me how a Wall would capture when it moves in its long direction. I would say it can capture only a single piece then.
Multiple Walls would have to be represented as different types, to prevent that components of different Walls would be mistaken for a single Wall. (E.g. if one stands on e3-f3 and the other on e4-f4.
Remapping of clicks is not really necessary, if one uses the convention that each component can move only in the opposit direction as the other.
There would have to be wrappers for the routines that perform or take back moves, to drag along the companion component.
Testing for the blocking can be done with XBetza. For moving in its long direction there is nothing to worry; the activated component can hop over its companion with a back-and-fort W move, and then continue like a Rook (pabyafR, with a hop ban for all types other than its own). For the 'double-barrel' move you can make a detour that travels over both paths: first hop onto the companion, slide to the right, moving or capturing, take an 'iso' slide back to make that a rifle move, turn left to step back to the origin, and turn left again for another iso slide. So pyarmcaibpyalyailW.
As mentioned before, rotation could simply be pasW, again banned for hopping over all types except its own.
That capture of any of its 'components' can already capture the Wall makes its implementation simpler than that of a Dev, (all moves can be judged on their own merits), but the fact that it has a sliding move makes it harder: one would not only have to test for blocking of other components on the destination area, but in the entire area swept by the move.
BTW, it is not clear to me how a Wall would capture when it moves in its long direction. I would say it can capture only a single piece then.
Multiple Walls would have to be represented as different types, to prevent that components of different Walls would be mistaken for a single Wall. (E.g. if one stands on e3-f3 and the other on e4-f4.
Remapping of clicks is not really necessary, if one uses the convention that each component can move only in the opposit direction as the other.
There would have to be wrappers for the routines that perform or take back moves, to drag along the companion component.
Testing for the blocking can be done with XBetza. For moving in its long direction there is nothing to worry; the activated component can hop over its companion with a back-and-fort W move, and then continue like a Rook (pabyafR, with a hop ban for all types other than its own). For the 'double-barrel' move you can make a detour that travels over both paths: first hop onto the companion, slide to the right, moving or capturing, take an 'iso' slide back to make that a rifle move, turn left to step back to the origin, and turn left again for another iso slide. So pyarmcaibpyalyailW.
As mentioned before, rotation could simply be pasW, again banned for hopping over all types except its own.