Pearl: mechanising the constraints

chrisboyle / sgtpuzzles

Android port of Simon Tatham's Puzzles

https://chris.boyle.name/puzzles

Other

592 stars 167 forks source link

Pearl: mechanising the constraints #505

Closed goyalyashpal closed 2 years ago

goyalyashpal commented 2 years ago

all but one of the conditions/constraints on the game pearl: are very VERY easy to be mechanised in theory (i.e. not saying wrt implementation in code).

Black circle has to be a bend, but str8 thereafter, so, 2×2 L pivoted at it.
White has to be a str8, so, 3×1 straight line, centered at it.
Make these things rotatable - similar to things in net or twiddle
The one condition left will be that white's straight has to turn at one of its ends, that cant be mechanised beautifully as far as i can think, but it's not required to be mechanised either.

i know it's not super important thing, but just thought to get more eyes on it

goyalyashpal commented 2 years ago

illustration showing

Rotation cycle:	00	01	11	10
white straights			--- not needed ---
black Ls long (my preferred)			--- not possible in shown ---
black Ls short

goyalyashpal commented 2 years ago

The only major downside i can think of, is that additonal logic will be needed for the conditions like "11" above where "L" cant exist, due to the wall/edge. that is, where the black circle is near an edge(s).

goyalyashpal commented 2 years ago

while playing palisade, i realised that this logic of thinking may bleed into many games and thus, either create inconsistency, or create lots of work without any significant gain. so, closing it. it was nice to think about this, but not much practical.

goyalyashpal commented 6 months ago

while playing slant, i felt that rather than providing this on whole board together... this can be (experimentally) given as a control option for individual element.

so say, choose this contol option, and apply it on some "square" (in slant parlance) and it provide a template which satisfies just the "specification" of that square i.e. the obvious game constraints; and then option to transform (like rotate) that template. So in slant, sq labelled 4 will get 4 outwards diagonals; sq(0) will get ring like diagonals and so on.

this per-element template, while staying non-obtrusive (in UX), can also help users to navigate some tough-y corners of a game while getting started, and get direct visual taste of working of game at a smoother learning curve.

and it feels even better to think about, so much so that i want to experiment with implementing it.