Since islands are invalid, it would be useful to show something when an island is created.

Might be a good idea to filter out islands that are simply two dead ends connected, though...

Thanks.
In some senses, this game similar to Picross. In Switch Picross (https://www.google.com/search?q=switch+picross), there is a check mistake feature which really useful, especially playing large puzzle, at the very end of the game you found it doesn't connect, but don't want to start all over again.

This was reported on daily puzzles 2023-03-23, 2023-03-22, 2023-03-19. They're from the same weekly series (large wrapping board with hourglass shape).
"Solved!" message appears when a few pieces are still not connected. Reports with screenshots: 1, 2.

I wasn't able to reproduce this so far. I'd appreciate a saved progress from a puzzle where this happens.

Hi @gereleth! We were chatting about recording videos of solve strategies, so I started experimenting with a "replay" button. The advantage is it doesn't record the time spent thinking. (Also I think it's better not to record the panning and zooming.)

I was surprised how easy this was to implement.

Code on my replay branch is rather rough, but it basically works. Preview here: https://penrosepipes-git-replay-gordonwoodhull.vercel.app

Here is a video of a partial solve of a trihexa in "proofs mode":

https://www.youtube.com/watch?v=FS926PZWwPI

Here's a complete trihexa solve, recorded on my tablet, where I prefer to play:

https://youtu.be/hpJTyRG_Y2k?feature=shared

Would be glad to clean up this code you're interested.

Known bug: if you click replay twice it goes haywire replaying every move twice!

Today, https://hexapipes.vercel.app/daily 404s.

The settings (which turned out very valuable to me!) are a small text line that are easily lost. Making them bigger (a button?) and centered somewhere might make folks notice them more.

Thanks to @gordonwoodhull we have an initial implementation of the cube grid. Its development was discussed in #83. I'm fixing the remaining issues in the cubes branch (preview link).

Here's what I changed so far.

1. Reduced puzzle sizes

Cube grid is based on hexagonal grid with every hexagon divided into three rhombic tiles. So the tile count for cube grid is 3x that of the hexagonal grid. And even the smallest 5x5 puzzle had 25*3=75 tiles originally. Or 19*3=57 if we use a hexagon-shaped board with the corners cut off.

I wanted to have puzzles with roughly the same tile counts as in the hexagonal/square sizes. Each next size is approximately double of the previous one there.

This example is how a 7x7 puzzle looks after the downsize. I don't know if we can find any 7s here... Maybe I should just call the sizes differently, still thinking about this.

2. Refactored edgemark bends

See how connection marks bend in the image above. This is pretty tricky to implement as two halves of the mark should have different transforms applied to them.

I considered dropping transforms alltogether and just providing grid coordinates for the line segments. What stopped me was that the difference between wall marks and connection marks is a 90deg turn and that would not work for skewed tiles.

So far I made the TransformedPolygonTile provide grid coordinates of its connection mark's endpoint in addiition to the usual {x1, x2, y1, y2} output in polygon coordinates. That lets me display the reflected half in the correct location.

An open question is how we should determine if a bend is necessary. We could make this a grid property. But I can imagine, for example, a grid that mixes regular hexagons and cubes (wouldn't that be fun). Then some connections would need bends and some wouldn't. So maybe this should be decided locally - if two polygons sharing an edge are different and at least one of them is a transformed polygon then a bend is necessary. Again, still thinking about this.

Another question is how edgemark gestures should be handled when there's a bend. Currently you have to draw a connection mark as if living in the coordinates of the tile where you started the gesture. That may not be obvious)).

3. Zoom factor

The grid is scaled for hexagons so the cube tiles can look too small at their default size. I tried introducing a zoom factor (1.5) to pixels per grid unit calculations. That somewhat helped with initial scaling of the puzzle though smallest sizes now can look too zoomed in so this needs more work.

I also realized that some controls logic relies on grid units too - like panning starts when drag distance is greater than 1. In cube puzzles this seems to happen later than I expect - like I have to pass ~two tiles distance instead of one. So maybe I should scale grid coordinates instead?..

4. Other minor fixes

Fixed click to orient not working on touch screens, "Play" header item highlighting on cube pages.

Wow, I did not expect this list to turn out so long... 😅

Hello! First: this is a wonderful game!

I'm writing to share some UX feedback on the wrap variant.

This mode really benefits from the edge marks to rule out certain edges. However, since the click target for the edge markers is so tiny, I like to zoom in quite a bit to make clicking easier. My first comment is that zooming is rather slow. For example, to zoom in from an overview (where there's only 1 or 2 tiles repeated on the edges) to a zoom that's comfortable to click edges takes about 5 seconds. This is something like ~10 full rotations of the scroll wheel on my mouse.

The second comment is related to the first -- since zooming is rather slow, I find myself wishing there was a way to pan around the zoomed-in tiles.

Starting this issue to keep track of the game's SVG rendering glitches.

One example is this screenshot from Safari on iPhone where connections between triangular tiles look wrong (source tweet). I don't really know how to fix this but at least I won't forget now.

Are the puzzle generation scripts open source? I was thinking about classifying puzzles based on their difficulty – eg distinguishing puzzles where you need to only lock known pieces from ones where you need to take notes about edges from ones where even more complex strategies are needed.

Since the last update placement of the red and green bars is broken - for example, left-clicking and holding on the yellow X puts the red bar in the wrong location in the following screensnip:

It is pretty much random where the bars appear now - usually on the wrong edge of the current square/hex/whatever.
I'm seeing this on Chrome (Windows 10).

Etrat is my go-to puzzle these days. I can reliably solve a 10x10 in "proofs mode", working from the edges in, until I only have to guess maybe 4x4, and I've kind of learned how to move the loose edges around (although I don't understand what I'm doing in a rational way).

I've noticed an interesting quirk. I think it only affects this grid, and only at the bottom. If you have the assistant on and you press and hold in order to start locking, and then keep dragging outside the grid, it will spin any adjacent tiles until they make sense, i.e. they will not point outside anymore.

This is actually super useful for those little triangular "v"s.

I kind of wish this worked everywhere. I haven't looked at the code to figure out why it's doing this, but I like it.

In both Chrome and Firefox on a laptop with a good-sized screen, the 15x15 puzzle does not appear fully within the viewframe; scrolling by dragging is required. It would be great if there was a way to indicate that we would like a reduced-size puzzle so we don't have to drag while solving.

Did something break in the tile generation?

Start over = fully reset the puzzle to initial state

Maybe a separate button to randomize all cells except those currently locked.

I got stuck on today's daily and left the page.

When I went back it looked like this:

Freeze the game and stop the timer. =)

…maybe usings arrows → ↓ ↑ ←, space ?

It is hard to contribute to this project without an open source license.

Probably has to do with how a size page redirects to a random puzzle page.

Maybe an animated gif of solving process for a small puzzle? Or at least before/after pictures.

thread

...thank you. This is exactly the right amount of effort to be entertaining without being addictive, at least for me.

There are some issues with how zoom and pan functions work on Mac devices. Some were described in issue #40 that resulted in a setting to disable zoom and pan.

The problems as I understand them:

• pan direction is inverted
• panning is too fast

No one complained about zoom strangely 🤔

I'd love to improve the situation but I'm flying blind here as I don't have any Macs at hand to test on.

For panning directions my mental model is that when I'm zoomed into a large puzzle then I'm looking at it through a small view box. I touch a touchpad with two fingers and this action "grabs" the view box and I move it around to see a different portion of the puzzle. So if I'm looking at the top of the puzzle and I want to see the bottom instead then I'll pull my fingers down on the touchpad.

When people say that the panning direction is inverted does that mean that their mental model is different (view box stays stationary and you drag the puzzle instead, so fingers move up to go from top of puzzle to bottom) or that the model is the same but the actual result is wrong?

If it's a mental model difference then I see two options for resolving this:

1. (More manual) Add a setting that allows the user to invert panning direction
2. (More automatic) Try to detect how wheel events correspond to scroll events. Like if you scroll down a page by moving fingers up on the touchpad then you probably want the inverted direction. I don't yet know how brittle a solution like this would be)).

As for panning sensitivity it might be that some event throttling could help. I'll try to make a REPL where we can find out how panning action events look across devices / browsers.

cc @Aaron-Rumpler who volunteered to provide feedback about this =).

)

Edit: Working as designed (edge marks drawn by gesture) - would be nice for this to be configurable. Clicking the edges was easier for me on non-mobile.

Edge marks seem not to be working in Chrome 104.0.5112.81 (and were working previously). Mousing over the edge between cells does not cause the cursor to change. Clicking the edge between cells causes cell rotation.

Went to check out the first puzzle of 2023 but I get a 404. Oh no!

I can't always create an edgemark on the first try... Sometimes not even on the second one.

I've tried relaxing the conditions around placing an edgemark so that almost any small drag goes. This is both for mouse drags and touch drags.

A preview link to try it out: https://hexapipes-git-controls-fixes-gereleth.vercel.app/

Interested in feedback: are the edgemarks easier to create there? Do you make them by accident? Any marks appearing in the wrong place? And overall - is this an improvement over the current situation? =)

I was using this perfectly well with the browser zoom mode, and now with your browse/zoom update, that doesn't work very well. Can we please have an option to disable pan/zoom ?

I'm not sure why I got this "improved average of 12" when... I haven't solved 11 of the last 12 puzzles (so I shouldn't have an average at all), and definitely haven't solved any daily in under 5 minutes for a while.

After switching tabs and back the message disappeared.

Not sure it's necessary, might be a UX improvement.

Hi @gereleth!

Since a couple months after you released hexapipes, I've been wondering what it would be like to play this game on Penrose tiles.

In particular, it looks like P3 with two different sizes of rhombuses would be a good match for this game.

Weird things about P3:

• Every tile has four neighbors, but it's not a grid.
• It is rotationally 5-fold symmetric around exactly one point, and is aperiodic - it doesn't wrap.
• The number of tiles that meet at a corner is between 3 - 7.

I am hoping that gameplay will also be weird but not broken. It should work, just different maze walls right?

I can only work on this on nights and weekends, so it may take me a while to build this. So I will share my progress in this ticket, rebase regularly, and publish the results from my fork at penrosepipes.vercel.app.

I will of course contribute back once something works, assuming it's still maintainable and makes sense to you. I think it will still be comprehensible. There may be something like a graph abstraction above the grid, the game using the graph instead of the grid.

I've published the first change, which is subtle but important. To handle P3 and other tiles that are not rotationally symmetric, we can imagine arms of different lengths and different angles going to points on the edge of the tile which are on a straight line to the center of the neighboring tile. ¹

Now instead of rotating the <g> using transform:rotate(...), we can bitwise rotate the tile, obtain its directions, and return the corresponding deltas.

We restore animation by applying the CSS transition to the path instead of the transform.

	.pipe path {
		transition: d 100ms;
	}

If you look closely, the animation is not as good, and we might consider adding keyframes so that the arms don't get as short during the animation. But I think it maintains the illusion well enough.

The transition only works on Chrome and Firefox; on WebKit Safari/iOS it degrades to no transition. I am sure there are workarounds for WebKit but I haven't looked into it yet.

grid.getDirections(...) already has an optional rotate parameter, but there is a wrinkle: we need the arms to always be listed in the same order for the animation to make sense. So we also rotate grid.DIRECTIONS by the same amount before filtering.

At the current commit (ac09e1c) I haven't yet implemented arm identity for the square grid, and you can see the bug that arises if arm directions are not returned in "original" order.

Here's a screen recording. Believe it or not, the tile is rotating clockwise, but the animation is deceptive: .

I'll publish the fix for this next week!

If this happens to you and you want to help me debug then please post a comment here.

I haven't been able to reproduce yet on the devices I have at hand.

• Locking
• Edge marks
• Control modes

A speedster player told me that the current 100ms animations feel too sluggish.

I'm considering adding a setting for animation speed. Maybe with 3 levels: usual (100 ms), fast (30? ms) and instant (0 ms).

You can try out different durations by inspecting a pipe and editing this circled value in the browser.

Any thoughts on this? =)

I think the “start over” button used to reset the timer. IMO it should!

Love this game, totally addicted. The recent interface improvements are awesome!

Maintaining the same scroll position would be nice too I guess.

Hi there.

I discovered pipes puzzles a couple days ago and i'm loving it.
I'm learning the ropes, sucessfully resolving my first puzzles. I like the idea of stats making you improve and being an incentive to be faster and faster.

Since i'm learning, i'm nowhere near to be super fast. So there is one more rule i try to follow : no wasted clicks.
As a minesweeper enthusiast, there is a stat that is also used to measure your skill : Efficiency.
The effeciency stat is not how fast you solve the puzzle, but how precise you are, with the less useless clicks.

I suppose you could track how many rotations you did to solve the puzzle and compare with how many rotations are truly needed (calculated while generating the puzzle). The closer you are to 100%, the more precise you are.

Combine this with the classic MO3, AO5 and AO12, and you can aim to be not only fast, but also super precise.

Thanks for reading :)

I really like this game. Great execution and a great idea. Is it your idea originally?

It works great at 5x5, with no performance issues. At 10x10 it is lagging a little, and at 40x40 it is really slow. At 40 it takes about one second for the hex to turn every time I press.

I am using a Samsung Galaxy s20. It is a mid or high end phone, two years old.

I can't promise anything but do you want me to look into the code and see if it can be optimised?

Do you have any thoughts as to why it is slow?

See attached image, there are 2 separate parts in (almost) identical green colour.

Seems the randomisation screwed up?

In the 10x10 hexagonal wrap puzzle 756 there is an ambiguous section.

Here is the nearly finished puzzle with the ambiguous area unfinished: nearly done 756.

Hi thanks so much for this awesome game!
I’m playing on phone/tablet and it is impossible for me to use the gestures to lock tiles or to mark the walls (occasionally I will accidentally mark the walls but I can never seem to do it on purpose).

Perhaps there is some kind of gesture or double tap or mode or something to help with that? Also, I think it would be nice to just be able to reset the board to the starting point somehow.

When I play a big puzzle on my phone and it's almost solved I sometimes spend a lot of time just scrolling around looking for that last disconnected piece. Some kind of help to find it would be nice.

If you walk away from an incomplete puzzle, the "Start over" button will reset the puzzle but not the timer. I'd like to be able to reset both of them for such a case.

It would be neat to be able to play wraps up to the same size as non-wraps!

Some people are stressed out by the timer, let them hide it.

ctrl-z for undo
shift-ctrl-z for redo (?)

And two buttons too.

Should multiple rotations of the same tile be combined into one undo?

As of now the site is using just the default Svelte Kit skeleton project layout and design.

It would be nice to change the puzzle page layout so that the puzzle takes most of the page and the controls/navigation are somewhere in a top bar or a side bar. This would maximize available play area.

I'm lacking in design skills so glad to accept any help: ideas, references, examples of similar layouts elsewhere. Mockups or pull requests if you're feeling generous =).