support camel moves for boards >= 5x5 other than 9x10 which is reserved for Janggi elephants #47
Conversation
|
wanted to add the reasoning for >= 5x5. every board size bigger than 5x5 will have every square of the board accessible by a pair of camels (one per square colour), but one might desire a game where the central square is not accessible by camels, hence allowance of 5x5 (but also for simplicity of the code). a 4x4 board by contrast would require camels to always be at the edge of the board in order to make a move. this in of itself isn't much of an issue as a camel move may not be the only move that the piece can do, but as a result, it would be easy to drag off the board and onto the board in order to specify the camel move if desired. i also want to note that a variant i designed is 6x8 and includes two pieces with a camel move but for symmetry one might want a 6x6 board with a potentially less traditional chess setup. the variant i made would work on 6x6 too although in such a case there would be no pawn double-moves (as that would cause the pawns to cross the centre of the board). hence i find it imperative that everything 6x6 and bigger allows camel moves, except 9x10 reserved for Janggi elephants ofc. EDIT: also, because the central square is excluded on 5x5, both camels can access the same number of squares, which makes it an elegant minimum. |
|
IMPORTANT: with regards to concern about making snapping less intuitive for players accustomed to not having a camel move be possible, i want to point out that currently the snapping is programmed so that half of the camel move's square is mapped to a rook move and the other half is mapped to a knight move. this barely affords any extra flexibility when trying to quickly draw knight moves; when i tested trying to draw knight moves quickly, it is about as inconvenient as drawing them exactly as there is no other move types that snap to a knight move! and the fact that other than the knight move, all squares map to either a rook or bishop move, makes these exceedingly easy so that the rook move clearly doesn't need an extra half square from the camel move. furthermore, the camel move is not strange to chess at all; see the below diagram of every square that a knight can move to in 2 moves; notice that only the camel move is unable to be drawn currently; what if someone doesn't care which route the knight takes and only that it ends up on the target square after two knight moves? TL;DR: if the concern is with drawing knight moves quickly, then i think the snapping algorithm should be improved rather than this pull request being rejected, as it is already about as difficult as drawing knight moves exactly, while it is really not that hard to consistently draw a (4, 0) or (0, 4) arrow. |
I'm sorry, but I'm not convinced by your arguments that these use cases are common enough. For the time being, I'll be closing this. |
i already rigorously argued against "snapping" as the justification of not changing the behaviour; specifically, i ended my reply with:
and as for this:
that's because they usually notate it as two knight moves in the same direction, but if someone did, you wouldn't know it because the snapping mechanism prevents this from being possible, so it's arguably a nil point, and i am not suggesting to allow this behaviour anyways as it's easily expressible as one or two knight moves as i said, so it's doubly a nil point. in the diagram i showed that in the space of all possible moves that are equal to two knight moves, the only ones that are impossible to draw (without the workaround which is not obvious to try) are camel moves. i hope you will consider reevaluating the decision, as it is already annoying to be artificially "snapped" to what wasn't intended and it is a feature that also hampers natural chess thinking of "i want my knight to be a camel's move away in the future, and i don't care how it gets there but i know it must take at least two moves" as well as obfuscating the idea of a camel move unnecessarily, and there is no way to turn it off really (unless that was fixed by now? in which case fairyground doesn't use it apparently, so i doubt it was). if the concern is to increase ease of players in snapping their intention and you want a suggestion for how to improve the algorithm: snapping the zebra (3, 2) move in non-janggi variants to the knight move would help with errors caused by moving the mouse too far, but you could also (either alternatively or in addition) make the snapping triangle to the knight move smaller so that the camel move still works. for example, you could have half the size of the current triangle snap to a rook move and on the opposite side of the square have the same size triangle (half the size) snap to a knight, so that 3/4 of the area of the camel square snaps to the camel move (specifically, if you split the square into 4 squares, then the two most characteristic of the camel move's direction would be fully mapped to the camel move, and the other two would only have the half that is closer to the camel move's centre mapped). (though my judgement is that making the snapping regions of the camel square to knight and rook a quarter the size in area is much less likely to cause confusion than changing the zebra square to map entirely to knight instead of entirely to rook, though if you think it may be a good idea, i suggest mapping half of the zebra square to the knight move (the right-angle triangle closer to the knight move in angle) |
|
if you wish to maximize backwards-compatibility with player expectations, here is an even more rook & knight biased way of doing the snapping than what i described above, which leaves half of the camel squares' area to snap to the camel, the half that is arguably the most characteristic of intending to draw a camel move |
this is my first time contributing ^^;