Lidraughts

[Vengaboy]

uitmuntende site, veel toernooitjes ook

[LastigeKnul]

Het is een weloverwogen beslissing om deze feature niet in te bouwen. Een poos geleden had ik het hen al eens gevraagd, en toen gaf men aan dat het er niet inkomt. Op het lidraughts forum schrijft men nu: "The subject has been discussed before, but we still hold the position not to have one-click captures, at least not in live games." Jammer.

Ik wil me daar niet zomaar bij neerleggen. Ik heb die reactie van BumperBalloonCars gelezen en hem gevraagd zijn standpunt te herzien.

Zijn voornaamste argument is dat het verplicht aanklikken van meerdere velden bij slagzetten meer lijkt op het echte dammen op een houten bord.

Maar lidraughts is een afgeleide van lichess, en het merkwaardige is dat men bij lichess wel allerlei concessies heeft gedaan om de online schaker tegemoet te komen. Deze zijn zo vanzelfsprekend dat de meeste schakers zich het niet eens zullen realiseren. Het belangrijkste voorbeeld is de automatische rochade. Bij het normale schaken op een bord zijn dit twee handelingen, één met de koning en één met de toren. Deze twee handelingen gelden samen als één zet. Toch hoef je op lichess alleen maar de koning te verzetten, waarna de toren automatisch wordt gezet.

[Marcel Kosters]

Ik wil me daar niet zomaar bij neerleggen. Ik heb die reactie van BumperBalloonCars gelezen en hem gevraagd zijn standpunt te herzien. (...)

Er zal eenvoudig een "best of both worlds" te realiseren zijn. Handhaaf de door Lidraughts geprefereerde standaardinstelling van aanklikken van alle velden. Voor echt beginnende dammers is dat waarschijnlijk ook ontzettend leerzaam en "vormend".

En voeg in de instellingen een optie toe van automatisch / volledig slaan voor gevorderde spelers. Deze instelling moeten Wieger, Hendrik en alle andere gevorderde spelers slechts eenmaal in hun instellingen aanklikken en opslaan om in het vervolg - volstrekt begrijpelijk! - hun partijtjes te kunnen spelen en beleven zoals zij dat willen.

[Klaas van der Laan]

2x aanklikken is inderdaad heel vervelend. Ook voor jeugdige dynamische nieuwkomers lijkt mij. Beetje te schools.

Een schuifvariant (slepen met schijf en loslaten) lijkt me eventueel een goed compromis.

[Marcel Kosters]

Hoe dan ook, er lijkt geen reden om het een of het ander uit te sluiten. Met enkele vink opties moet iedere gebruiker maximaal aan zijn trekken kunnen komen. Al zal dat technisch wellicht meer haken en ogen hebben dan ik me realiseer?

[Rein Halbersma]

Technisch is het rechttoe-rechtaan, en alle broncode staat op GitHub. Maar klagen over missende features is natuurlijk leuker dan ze zelf implementeren.

[Wieger Wesselink]

Technisch is het rechttoe-rechtaan, en alle broncode staat op GitHub. Maar klagen over missende features is natuurlijk leuker dan ze zelf implementeren.

Rein, ik heb niet de indruk dat mensen hier nou zo hard aan het klagen zijn. Als de auteurs van lidraughts hadden aangegeven dat ze deze feature best willen toevoegen, maar dat ze het alleen niet belangrijk genoeg vinden om het zelf te willen implementeren, dan zou ik overwegen om daar een bijdrage aan te leveren. Ook al is het in Scala geschreven, waar ik nauwelijks ervaring mee heb. Maar het aanleveren van een feature waarvan de auteurs meermaals hebben aangegeven dat ze die ongewenst vinden lijkt mij niet de manier.

[Marcel Kosters]

Misschien weten de auteurs niet dat er EN bereidheid EN kunde is bij de feature verzoekers. Misschien dat - als er iemand is die in staat en bereid zou zijn zelf de verzochte feature toe te voegen - het de moeite waard is dit met de auteurs kort te sluiten?

Hopelijk staan zij op het standpunt: ,,Wij zien de toegevoegde waarde niet en gaan er daarom zelf geen energie in stoppen. Maar als anderen die waarde wel zien en dit zelf kunnen en willen realiseren: prima, ga je gang."

[Michel Stempher]

Misschien weten de auteurs niet dat er EN bereidheid EN kunde is bij de feature verzoekers. Misschien dat - als er iemand is die in staat en bereid zou zijn zelf de verzochte feature toe te voegen - het de moeite waard is dit met de auteurs kort te sluiten?

Hopelijk staan zij op het standpunt: ,,Wij zien de toegevoegde waarde niet en gaan er daarom zelf geen energie in stoppen. Maar als anderen die waarde wel zien en dit zelf kunnen en willen realiseren: prima, ga je gang."

Nou, uit alles blijkt dat de programmeurs gewoon ontzettend eigenwijs zijn. Ze stellen bijvoorbeeld dat in live games een dergelijke feature ongewenst is, omdat het de beleving van een damspel zou wegnemen. De kans lijkt me daarmee groot dat ze best bereid zijn iets in te voeren bij tactics, analyses etc., maar absoluut niet bij de live games.

[Rein Halbersma]

Technisch is het rechttoe-rechtaan, en alle broncode staat op GitHub. Maar klagen over missende features is natuurlijk leuker dan ze zelf implementeren.

Rein, ik heb niet de indruk dat mensen hier nou zo hard aan het klagen zijn. Als de auteurs van lidraughts hadden aangegeven dat ze deze feature best willen toevoegen, maar dat ze het alleen niet belangrijk genoeg vinden om het zelf te willen implementeren, dan zou ik overwegen om daar een bijdrage aan te leveren. Ook al is het in Scala geschreven, waar ik nauwelijks ervaring mee heb. Maar het aanleveren van een feature waarvan de auteurs meermaals hebben aangegeven dat ze die ongewenst vinden lijkt mij niet de manier.

Ik denk dat een GitHub pull request een slagingskans van <5% heeft, maar dat is nog altijd veel hoger dan de <0,1% die het nu heeft. Maar om daarvoor Scala te leren, is wellicht niet zo’n goede investering, dat ben ik wel met je eens.

[LastigeKnul]

Er is een belangwekkende reactie gekomen van RoepStoep op het verzoek voor eenvoudigere manieren op te zetten in lidraughts. Hij roept ook nadrukkelijk op tot meer suggesties:

Thanks for your input everyone! There are two separate issues at play here. One is the option to play full capture sequences at once, and the other is the way the moves/captures are executed on the board (automatic, one-click, etc).

We have put this first issue on the roadmap, and are planning to add a "full captures" setting for the analysis boards (which would apply to analysis, studies and puzzles when enabled). Live games are still a different matter for reasons outlined earlier, as your way of moving the pieces there does not only affect your own play, but also that of your opponent.

With this new setting enabled you could drag or click a piece immediately to the ending square of a capture sequence, without having to perform all the steps in between yourself. When there are different capture paths possible, you would first have to click to a point where the paths diverge, after which you can click to the ending square.

A different issue is the way moves can be executed on the board, for which several proposals have been made as well. We think fully automatic captures can be safely discarded for the reasons @Tim outlines (it will make things messy and confusing). For the same reasons, it doesn't seem like a good idea to move pieces by clicking a target square alone, in cases where there is only one piece that can move there. The most intuitive way to move a piece starts with clicking/dragging the piece you want to move. Mixing in other ways (that only happen in certain situations) hardly adds any value, but potentially brings a lot of confusion.

Single-click moves are a different matter (clicking a piece with only one move will automatically play that move, capture or not). This is still initiated with a click on the piece you want to move, and thus is most natural. On the other hand this could also be confusing for people that aren't used to it, because you have to keep in mind that the board behaves differently in some situations. For example, many people show the habit of hovering pieces while thinking, deciding whether to drop it or play something else. It is especially annoying with puzzles when this results in an unwanted move being played immediately.

We would love to hear more opinions from the community about this. Our preference is to only move pieces by drag-and-drop, or by clicking the piece followed by its target square, regardless whether the move is forced or not. There is certainly value in keeping the way of moving pieces consistent across all boards and positions. However, if the consensus is that one-click moves are an addition as well, this can be included as a side-effect of the new "full captures" setting (in which case something like "quick moves" might be a more appropriate name).

[Klaas van der Laan]

Dragging and dropping is most natural with the real board game. Perhaps for a visual effect: let the track light up while dragging the track and after dropping, remove the stones one by one in the same order as they were captured. Then no intermediate click is needed.

[Wieger Wesselink]

RoepStoep richt zich op beginnende dammers. Zijn uitgangspunten sluiten een efficiente zetinvoer uit.

[LastigeKnul]

RoepStoep richt zich op beginnende dammers. Zijn uitgangspunten sluiten een efficiente zetinvoer uit.

Nee hoor. Lees zijn laatste zin hierboven.

[ildjarn]

With this new setting enabled you could drag or click a piece immediately to the ending square of a capture sequence, without having to perform all the steps in between yourself. When there are different capture paths possible, you would first have to click to a point where the paths diverge, after which you can click to the ending square.

Please note that there are situations where multiple intermediate squares must be clicked to disambiguate captures.
See e.g. http://sanguis.xs4all.nl/dammen/show_problem.php?ID=123 where the 7th move would require multiple intermediate squares.