Simon Tatham's Portable Puzzle Collection

[GerReader]

Originally Posted by ploum

Thanks for the work. I’m addicted. I reported a couple of bugs on Github, I hope it’s the best place to do that.

GitHub is indeed the best place. Thanks for catching the bug in Creek, I can reproduce it and I am looking into it.

For the issue with Signpost, I'd like to discuss this here first.

My thoughts behind greying out only the cells in the middle of a sequence, and keeping the cells at the start and end active were that the start and end cells both still need to be connected, and that greying out the start would be the confusing way to do it. Grey-out should indicate that one can ignore there cells; but the start cell is still relevant so it should not be greyed out?

Furthermore, the start cell in a sequence is additonally marked with a dot left to the arrow, so this should also protect a little bit to accidentally re-connecting this cell to another target.

A possible change could be to grey out all arrows in a sequence, but keep the letter sequence indicators of the start and end cell in black. Alternatively grey out the start/middle arrows, keep the end cell all black, and the start cell with a black letter but a grey arrow. Third option: Middle cells all greyed out, start cell black letter/grey arrow, end cell grey letter/black arrow.

Would this be less confusing while still keeping enough attention on the relevant start/end cells? Thoughts? I think the third option might be the best, as this shows most clearly that the start cell is the entry point to a sequence, and the end cell the exit from the sequence?

[ploum]

My brain is working the following way : if a dot is black, it needs to be connected. If an arrow is black, it needs to connect to a dot. Everything else is scanned out.

AFAIK, it was exactly that in the previous version. Is there a problem with that way of working ? For the numbers, it makes sense to keep black the numbers of both ends while greying out those in the middle of a sequence.

Of course, that’s only my way of seeing it ;-)

[GerReader]

Originally Posted by ploum

My brain is working the following way : if a dot is black, it needs to be connected. If an arrow is black, it needs to connect to a dot. Everything else is scanned out.

AFAIK, it was exactly that in the previous version. Is there a problem with that way of working ? For the numbers, it makes sense to keep black the numbers of both ends while greying out those in the middle of a sequence.

Of course, that’s only my way of seeing it ;-)

It is a little bit tricky. I completely rewrote and simplified the logic how colors are assigned to game elements, as it is rather convoluted in the original, and I had to translate all to greyscale. Further complicating was that especially for this game the screen redraw on eInk needed to be heavily optimized.

I made some tests this morning, and I think I now prefer solution 2) from above:

a) Start of sequence: Black number/letter, black dot, grey arrow
b) Middle of sequence: Grey number/letter, grey arrow
c) End of sequence: Black number/letter, black arrow
d) Unconnected cell: Black number, black dot, black arrow

This should also be as close to the original as possible, and as I understand it, like your description.

[GerReader]

Implemented bugfix & UI changes discussed here with ploum:

• Signpost: Changed coloring of start / end cells in a sequence.
• Creek: Fixed bug that a disconnected grid still counted as valid solution.

[ploum]

Thanks a lot. Sounds great. Thanks for your work, I’m completely addict to those games ;-)