toward P3

[gordonwoodhull]

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!

Footnotes

1. I hope to find time to draw a diagram showing what arms will look like on P3. It will be weird, because the arms will rotate (and stretch) but the tile will not, but I think it will work. ↩

[gereleth]

Hi, Gordon! I'm really excited to see this.

It should work, just different maze walls right?

Absolutely! There's Penrose slitherlink, why not pipes)).

---

Regarding the rotations of rhombus tiles I thought of implementing them with some skew transform of a square tile. I made a REPL as a proof of concept that rotation transitions can look nice in this case. Of course the real difficulty is in figuring out correct transforms for different rhombus types and orientations. But maybe this is still less work than transitioning paths.

I also must confess that I changed a lot about grid implementations while working on "octagons + squares" grid. Basically I abstracted away a RegularPolygonTile that handles computing rotations, drawing tiles and pipes, detecting edgemark gestures - all the stuff that's local to the tile. So the grid delegates this local stuff to its polygon tile(s) and stays responsible for "global" questions like:

• where is tile number i located (index_to_xy)
• what's the number of tile located at x, y point (which_tile_at)
• what's the neighbour of tile i in direction d (find_neighbour)

Maybe there could be a SkewedPolygonTile that "unskews" the coordinates it receives and then reuses regular polygon logic for all the local matters.

I've long wanted to have this "cubes" tiling - implementing this might be a way to try out rhombic tiles without the additional Penrose complications. Grid logic here can reuse the HexaGrid and further subdivide each hexagon into three parts.

[gordonwoodhull]

I had the related thought of doing some kind of periodic rhombus tiles next week to test the variable length arms and different angles.

To make it easier I might do the simpler one-orientation rhombus first, even though it’s just squashed and rotated squares.

I had not considered a skew transform—will check out your REPL, thanks! That might be cleaner than the path transitions.

I have not looked at the octagon branch yet, but I will try to rebase on it before proceeding. It’s likely you will merge that before I finish this, and it sounds like you may have implemented some of the same abstractions I’ve been thinking about.

[gordonwoodhull]

The disadvantage of skewing a square tile in order to make a rhombus tile is that the pipes will bend at tile boundaries, if the tiles are oriented in different directions. The advantage is that the pipes still land in the center of the tile boundaries.

Hard to say which looks better / clearer without trying.

The new abstractions look very helpful!

[gordonwoodhull]

I am taking your advice and starting with cubes. This is... not working yet... but I think it's really close.

not.working.cube.tiles.mov

FWIW the tiles need to be scaled as well as skewed, because otherwise the diagonals will be longer than 1. Here's a fork of your REPL. I think you scale first then skew, because that way the skew angle is correct.

[gereleth]

I tried to solve one but my clicks land too unpredictably 😂. Individual tiles are looking great though 👍.

[gordonwoodhull]

Display and gameplay mostly work for the cubes grid (demo).

There are many bugs, among them:

• The generated puzzles are impossible. I haven't looked at the generation code very much, so I'm not sure if it needs to change or if the grid is improperly specified. Generation occasionally crashes the browser (endless loop).
• Clicking on the border between tiles can cause the wrong tile to rotate.
• There is an off-by-one bug in find_neighbor where the rows wrap.
• Smudges at tile boundaries are more visible because of the skew. I think the easiest thing to do is to clip each tile, although that may clutter the SVG with <defs>.
• I haven't yet tried to get marks to work / looked into SkewedPolygonTile. It seemed simpler to start by defining the extra transforms in the grid without changing the polygons.
• The naive non-wrapped grid might be too easy because the border is so bumpy.

Hope to continue this tomorrow.

[gereleth]

It's really coming together!

Generation is currently messed up because opposite directions in the grid are inconsistent. The directions are defined like in this image (tile index in black, direction numbers in blue). See how the opposite of direction 2 is sometimes 4 and sometimes 8.

You could rotate your squares like this instead. Here directions 1 and 2 look inside the hexagon, and 4 and 8 look outside. This way the opposites are consistent and the generator should make something solvable =).

Or you could use the hexagonal directions... But then each of the three squares would have its own set of directions so I don't know if this idea is any good)).

Either way I'm also thinking that maybe we shouldn't rely on grid.OPPOSITE constant and instead return opposite direction as part of find_neighbour output. This seems like a good thing to hide away inside the grid but will require some slight changes to solver, generator and game logic.

---

For wrong tiles rotating and wrap errors I thought that maybe literally doing this.hexagrid = new HexaGrid(...) could be helpful. Then for example you can use this.hexagrid.which_tile_at(x, y) to find the hexagon index and only need to look at the angle to tell which rhombus it is. Same with finding neighbours - get neighbour hexagon index first and then figure out where we are inside it. I really don't wish the pain of debugging hexagonal wrapping on anyone =).

---

Boundary smudges may be fixed by setting stroke-linejoin="bevel"on pipe insides in Tile.svelte. I originally set it to round to avoid these small artifacts seen between connected pipes. But maybe this can be solved some other way.

---

Re bumpy borders we could always crank up the avoidObvious setting).

[gordonwoodhull]

Excellent hints and feedback, thanks!

I agree it would be much better to reuse HexaGrid rather than duplicating all this code. I have been expedient to get things working, but I am glad to revise to make this maintainable.

Great point about the wrong opposites, knew I was missing something there.

[gordonwoodhull]

With the rotation and direction numbering & opposites all consistent, the cube grid is now working perfectly in non-wrap mode. (It's playable but difficult to complete in wrap mode, because of the off-by-one bug.)

I think it's harder than squares but easier than hexagons. The false perspective is disorienting! 😱

Quite a lot still to fix and clean up - realistically probably won't do a PR until next week.

[gereleth]

Wow, I just love solving buggy puzzles. Edge issues on wraps make things more challenging)).

Could you add a cubes option to the custom puzzle page? For experimenting with generator settings. I think that this puzzle would definitely benefit from bigger avoidObvious values. Maybe you can use the same generation settings as the square puzzles for now? Defined here.

[gordonwoodhull]

It looks like the P3 tiling rules have the same notion of "opposite sides". From the wikipedia page, with binary annotation:

Hmm, no matter how you number it, the two rhombs will have directions in different order, though. So yeah, maybe opposites should be hidden away.

[gordonwoodhull]

stroke-linejoin: bevel looks terrible on iOS but it's fine everywhere else, including Safari.

[gordonwoodhull]

My apologies, I probably won’t be able to clean up my code and contribute for a few weeks. I’m traveling to see my parents next week, and need to clean and pack and so on.

I’ll be sure to rebase and continue the improvements we discussed.

Very eager to get this in good shape and contribute, just ran out of time for now.

[gereleth]

No worries, have a good trip!

[gordonwoodhull]

Cubes are now completely working, including wrap and edge marks, although connecting marks do not work reliably on touchscreens (walls do). I also need to apply the transform for Orient / Lock mode, which I just tried for the first time.

I got wrap working last week. I was on vacation, so I didn't mention it here. Reusing HexaGrid as you suggested removed 70 lines of duplicated code, and fixed wrap and other issues.

Since then I've played more than 100 of the 5 x 5 cube wrap puzzles (which has 75 tiles). I find it quite fun. I think the corners where 3 tiles come together make it slightly easier than square grid, so I'm usually able to prove and auto-lock almost till the end. Best time under 2 minutes but it often takes 10.

I think the non-wrap should use the hexagon playing field shape so there aren't exposed corners. It's too easy with those.

I'm using transformation-matrix to invert the tile transformation and detect edge marks in the original coordinate system of the polygon. Hope the extra dependency is okay.

Needless to say, the transformation matrix approach is very general and will apply nicely to P3 tiles.

So neat how the maze generation code works perfectly with no changes for this grid. The only thing that "puzzles" me is that occasionally it draws a fully connected X - does it run out of other ideas? I think this only happens on the non-wrap.

I'll squash my commits into one and submit a PR tomorrow.

Happy to refactor further. I wasn't sure about the responsibility of controls vs grid for doing transformation - putting the code in the controls seemed less repetitive than adding the transformation matrix stuff to every grid, but maybe there's a better way.

Also the "grid tile" containing three actual tiles, each transformed its own way, is maybe not a good abstraction, just expedient.

[gereleth]

I played some 5x5 wraps, they're nice! Quite refreshing after the confusing evilness of etrat grid that I've been working on).

It's neat how this grid has two distinct types of corners (with 3 and 6 squares meeting). All the others I've encountered so far have a constant number of tiles meeting in a corner (3 for hexagons and octagons, 4 for squares, 5 for etrat). Places where 3 tiles meet allow for some solver shortcuts but I don't yet know how to apply them to only some places in the grid.
And imagine if each rhombus were a 2x2 square grid, then we'd have 3, 4 or 6 tiles meeting in different corners 🤯

Re connection marks I think it would be cool if they could bend at the tile border like the pipes do. I drew a rough example on the pinkish pipe here. But this might be tricky to implement. Like each of the two tiles should draw its own half using its own transforms? Or maybe let's end the mark at tile border at least. The part that's hanging off doesn't look good to me.

I think the non-wrap should use the hexagon playing field shape

There's a helper for that in hexagrid code, something like grid.useShape('hexagon'). It makes the corners empty to get a hexagonal field shape. I use that for dailies sometimes). You could iterate over empty hexagons and empty some rhombs in turn.

The only thing that "puzzles" me is that occasionally it draws a fully connected X

Fully connected tiles can happen during pregeneration if there is no other way to complete a puzzle. Imagine the red part here is already visited, and the upper left green corner is not. Both neighbouring red tiles are already T-shaped. And the only way to connect to the green corner is to turn one of them into an X. I don't want to introduce backtracking into pregeneration so I just allow this. A less bumpy field shape (like a hexagon) should make X tiles less likely to appear.

I haven't reviewed how the transformations work yet, I'll be able to do that once I finish with etrat branch. That grid is forcing me to learn about web workers because ensuring uniqueness takes too long to just leave it in the UI thread =).

[gordonwoodhull]

Etrat is tricky! I look forward to hours of figuring out proof patterns there.

I agree that the connection edge marks sticking out are ugly. Wrapping around the edge would be great. I haven't figured out how to get both EdgeMark tiles to draw while only one should record.

As an experiment, I added a flag to get_edgemark_line to shorten the mark, but this affected the walls as well, making them short and displaced.

I've run out of time this week, so I'll leave it like that for now.

I also reverted changes to the controls and created gridutils.js - so the grid has exclusive responsibility of the transform. This is needed for whichEdge for Orient / Lock mode and makes sense IMO. However, Orient / Lock still doesn't work, so I'll have to dig into that next week.

I want to fix everything before submitting a PR, so it's another week if not two.

[gordonwoodhull]

etrat-wrap is too difficult for me, and now I'm scared P3 is going to be too. 😭

Oh well, can't stop now...

[gereleth]

Penrose tiles can't wrap by design so they can't be too bad. I expect something around square or cube difficulty.

I don't quite understand yet what makes etrat so bad. It must be the triangular tiles? With square tiles if you have a turn and know one connection then at least you can say that the opposite side is a wall. That's often handy. With triangular tiles a turn + one its connection gives... mostly nothing. It's kinda similar to low branching hexagonal wraps that are hard too.

One other thing is that etrat puzzles tend to have hundreds and thousands of solutions at even moderate sizes. So even when a puzzle has a unique solution it likely has an obscene number of "almost solutions" that look very very plausible until one last part just doesn't connect. And lookups till you find a contradiction tend to be very long.

[gordonwoodhull]

Interesting that etrat has so many solutions!

Yes I get stuck on “almost” solutions, even with the 10x10 non-wrap. There will be one extra piece or two closed components. I have no idea how to fix it so I start over or give up.

I think you’re right that P3 should be like cubes only irregular, with 3-7 tiles meeting at a corner.

[gereleth]

I tried out the cubes code today and I think the transforms logic is currently a bit wasteful. On every click we compose a transform matrix, then invert it too... That's running a lot of the same computations again and again because we only have three distinct cube faces and so three distinct transforms. It should be enough to compute them only once!

I think a better way to go about this would be to do

TOP_FACE = new TransformedPolygonTile(SQUARE, transform_top)
RIGHT_FACE = new TransformedPolygonTile(SQUARE, transform_right)
LEFT_FACE = new TransformedPolygonTile(SQUARE, transform_left)

polygonAt(index) {
  return [RIGHT_FACE, TOP_FACE, LEFT_FACE][index%3]
}

The TransformedPolygonTile computes transformation matrix, its inverse, and the transform style string in its constructor. And then it does pretty much the same stuff as regular polygon tiles taking care of its own coordinate conversions where necessary.
Then the cubegrid logic can look pretty much the same as other grids with this.polygonAt(index).doStuff...and forget that its polygons are weird =).

I would also remove the translate part of the transform and just give each rhombus its own center coordinates instead. This just seems easier to reason about. Not that it's easy! I tried to implement something along these lines but got bogged down trying to understand transform computations.

Can you think of any problems with this approach? I don't really know how many distinct transforms a P3 grid would have. Is there a sane number of them or infinite variety? =)

[gordonwoodhull]

I agree the transform should only be computed once per tile “type”, and I like this TransformedPolygonTile idea. (I think you mentioned it before but I didn’t understand until now.)

Also transforms should not be computed or used for the grids that do not use this feature. I think I can revert those changes and only keep a few small changes to the grid interface.

As for removing the translate… Maybe? I have often wondered whether it is a good idea to have three tiles per grid position. It was the easiest way to reuse HexaGrid but it’s pretty messy.

For P3, I think each tile will need its own transform. There are only two shapes, so the skew and scale will be the same for many tiles, but I doubt it’s worth it to count all the possible rotations of those two shapes. (I’ll check though.)

Each tile’s transform and inverse could be computed once. These are 4x4 matrices so it’s not a lot of memory.

[gereleth]

Based on my coloring experiment there are 5 kite thick types and 5 dart thin types in P3, so 10 distinct transforms in total.

Rhomb offsets should be easy to do, I'd precompute OFFSETS = [{dx, dy}, ...] for three rhomb types - deltas from hexagon center to rhomb center. And then in which_tile_at and getVisibleTiles add an offset to hexagon center based on rhomb index. I think it makes sense to keep the grid responsible for tile position and the polygon responsible for tile shape.

[gordonwoodhull]

Surprising! I guess that's because it's all multiples of 36⁰.

[gordonwoodhull]

Okay, I think the cube grid is ready for review.

[gordonwoodhull]

Next step for me is to implement the P3 tiling itself. I think I’ll use the substitution / drill-down method detailed here:

https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/aperiodic-tilings/

I’m more familiar with D3 for SVG, so I’ll probably implement the geometric algorithm standalone, and come back to the tiles in a couple weeks when I have a generator for coordinate and rotation data.

[gordonwoodhull]

I have a demo of producing an approximate number of P3 tiles which intersect a polygon.

That Tatham paper says how to keep track of adjacency, and I've implemented coordinates for the Robinson triangles. (You can see them by adding ?coord - not sure if these are correct yet.) Tatham describes a simple recursive algorithm to find neighbors using the coordinates, and that will give us coalescing of the triangles into rhombuses and tile adjacency.

At that point the only challenge to Penrose pipes is the neighbours and opposites problem we talked about before. Your solution of the grid returning the opposite when returning a neighbour sounded good and I may give that a try in a couple of weeks.

[gordonwoodhull]

I shouldn't jinx myself by talking as if I know what all the problems are. "Patching" the border will also be tricky.

Take this example:

We will prune any half-tiles when we coalesce triangles into rhombuses, but here that will cause such a jagged upper-left corner once the half-blue is removed that we should either drop the red or add in the other half-blue. Same in the upper-right corner.

[gereleth]

Nice, I played some already. Even got some quasi-wrap experience by starting a large puzzle from the middle)).

Then grid gets put alongside tiles in local storage, both in instance and progress.

I don't get why it needs to be in progress, seems to me it should live in instance only. I haven't looked at the code yet but I'll review how createGrid should work with different-every-time grids.

---

Detached tiles strike again and my streak is dead. It was only six games long 🥲. At least the tab didn't hang).

I also saw an example where two thin rhombs were detached from the rest of the grid. So we can't even use "tile with no neighbours" logic to detect this situation. I thought of declaring these tiles empty if the generator can't reach them. But sometimes the generator will choose to start from a detached tile and then the whole grid ends up empty. This is exactly what happened in the previous detached example. Tricky stuff)).

[gordonwoodhull]

You're right, the progress state doesn't need grid.

I've switched to cull strategy, not as nice border in some cases but eliminates islands by repeatedly removing any rhombs with less than two neighbors.

Chose the harder tiles, renamed to penrose.

I think the walking stick is the major problem left. I'm looking at it now.

[gordonwoodhull]

[gordonwoodhull]

debugging

[gordonwoodhull]

[gordonwoodhull]

Even got some quasi-wrap experience by starting a large puzzle from the middle)).

In theory, I think you could have an infinite penrose pipes puzzle if the maze were generated on the fly as area is explored. Would be a huge endeavor though.

[gordonwoodhull]

In the new numbering, the flips are +10 on the old numbering (which was previously implemented incorrectly due to y increasing downward).

With flip accounted for, the skinny rhombs are offset 0; the thick rhombs are offset 1.

[gordonwoodhull]

Without cleaning anything else up, I'm pushing the simplified offset calculation.

const offset = rhomb.base % 10 < 5 ? 1 : 0;

It is fast, puzzle now loads in 1.5s for 100x100 = 18k tiles

Have to fix the example. Otherwise I think it's pretty solid.

For later: I should probably fix the offset problem on the penrose-fill-polygon side but I still don't completely understand.

Cull can do some stupid stuff on the border:

A combination of fill + cull is probably the answer.

[gereleth]

So can we assign directions with consistent opposites now?

[gordonwoodhull]

We could. Since the order of sides in this sense is different for thin vs thick rhombs, there would have to be a mapping for one of them.

On the other hand, what you did with the lesser index seems perfectly reasonable for any grid where you don't know the opposites, so maybe that's worth holding onto.

[gereleth]

Super glad to be rid of the walking stick! I hate the hack with inconsistent opposites too to be honest and I want to remove it. But I haven't managed to get consistent directions with the current code.

There must be a bug with determining base polygons because when I tried jigsaw marks again I got this result. See two yellow stars made of fat rhombs. Base 0 and 10 rhombs correctly tell that they're flipped versions of each other. But the rest (base 1, 3, 4, 12) just think they are identical when they should be flipped.

Instance data for debug purposes: penrose_5x5.json.txt. Downloading a puzzle should give this data but that's another todo along with importing a puzzle on custom page)).

I noticed that rhombs data has a key property that contains a string of eight numbers. If that key is only for use in getVisibleTiles then we can just use index instead. Using index doesn't work in wrap puzzles because we may see multiple copies of the same tile. But here the index should be unique enough since penrose grid doesn't wrap.

[gordonwoodhull]

I agree, by the jigsaw marks those stars should be consistently 0 - 4 or 10 - 14. Instead the pieces seem to be interchangeable.

Why then does the simple offset calculation work?

That key data isn't used by PenroseGrid; it's an artifact of classifying the rhombs by base. PenroseGrid.getVisibleTiles uses coord, from the tatham coordinates of the rhomb's triangles, but you're right it could just as well use index.

I'm out of time for this week. I'm sure there are many bugs but it runs nice.

It's live at penrosepipes.vercel.app.

[gordonwoodhull]

I think I have an idea about the wrong rhomb numbers. I assumed that tatham coordinates would correspond to the jigsaw edges but this is apparently not the case. Will look into it next week.

Also noted about saving the grid / geometry with the tiles to download.

It's too bad the data is so bulky. For the example I had to put it in a separate file because it's much larger than grids.js.

It's useful to have redundancy for various calculations, but I think the saved form could deduplicate.

[gordonwoodhull]

It might sound like an overreaction, but I’ve taken down these deployments for now.

On Saturday I played for a couple hours after I was too tired to work.

I think the perspective distortion made me somewhat ill & gave me vertigo for a few hours after. Like I couldn’t tell which way was up. Not fun. And it comes back if I think about those twists and turns.

Granted I’m susceptible to motion sickness from video games, but I don’t want to put something out that could harm people.

I want to try somehow making the pipes of uniform dimension. I.e. the tiles still skewed and rotated but the pipes not.

So let’s hold off on this a bit.

[gereleth]

So sorry this happened to you! I didn't have such severe symptoms myself but I think I can understand the feeling. I do have to blink and shake my head occasionally to avoid dizziness while playing largish penrose pipes. The chaotically crumpled space is not easy on the eyes.

Displaying pipes without perspective distortion is not without problems either... It's gonna be really tricky to get them to connect smoothly at weird angles. And the pipes change shape on rotation - this is especially noticeable on thin rhombs.
(Please disregard the coloring in my screenshot, I only made the geometry look somewhat correct)

[gordonwoodhull]

Hi @gereleth! I combined the technique for animating arms independently (from the very beginning of this ticket) with clip polygons from PR #101 to produce a demo of Penrose Pipes with uniform pipe widths:

I suspect that I solved this wrong, not that there is a bug in the maze. But I can't figure this one out.

Now the shapes are completely unfamiliar, but I think this is fair - what do you think?

https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/5

It has one severe bug where it is unable to draw arms that go off the grid. If you look closely you will see another glitch implied by arms going straight to neighbour but clipped by polygon. 😉

[gordonwoodhull]

Haha the edge marks need to be direct and not transformed, too

[gordonwoodhull]

After playing a bunch of rounds, I'd say it's confusing but not disorienting: I'm not getting the vertigo I got from the previous version.

But not having familiar or consistent piece shapes makes it more difficult. If the stats are correct it's taking me 5min for a puzzle that took 2min in the previous version.

Lots of work before I can release this, even more work before it would be ready for PR.

[gereleth]

It's confusing all right, I can't tell a straight piece from a turn at a glance!

You're drawing the pipe line to the center of neighbour, right? In my attempt above I was trying to go for edge middle. Maybe these two approaches could be combined - like we go for edge middle first and then towards neighbour center to ensure a smooth connection. That might make straights mostly straight (with some bendy ends).

In your buggy-looking puzzle the tile on the left of the green deadend looks like it still has disconnects. So it's probably a sneaky T looking outside 😄.

[gordonwoodhull]

Definitely worth trying. I don't like adding extra bends but if it helps the pieces be more recognizable, that would be nice.

I may also experiment with splines as it's a very wavy layout already.

And yes that must have been a sneaky T. I am often getting tripped up by 3s on the border. I think every other piece is unambiguous there.

[gordonwoodhull]

Okay! I think this looks pretty nice.

https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/7

There is an optical illusion where it looks like the narrow rhombs have swollen pipes, but I have measured it and it's not real, just one of those standard optical illusions.

It has a knob symbol_portion which sets how far to draw the recognizable tile shape before then heading toward the counterpart on the next tile. The above is 0.7, which I think is a nice compromise.

Zero draws directly to the center of the next tile, as in last week's iteration.

Values larger than 1 draw past the edge without splining (just for reference):

Lower numbers get more wavy:

It's not bad without Beziers, but a a little jittery:

https://penrosepipes-git-p3-gordonwoodhull.vercel.app/penrose/7

I'm halfway to fixing the edge pieces; many other things to fix but I think it's quite playable now.

[gereleth]

The 0.7 variant looks awesome, I love it! The shapes are recognizable and the connections are smooth. Being closer to edge middles got rid of corner glitches too. I haven't looked at the code but the results are very nice =).

[gordonwoodhull]

Thanks!

I still need to clean up, putting the changes safely under flags so they don't break the other grids. In particular clip paths should be enabled only for this grid and for iOS to fix #91.

And there is a backlog of things to fix in the Penrose tiles generator that we have discussed before. (E.g. I had to reverse the list of rhombus points and then offset differently for thick vs thin rhombuses, the equivalent of your neighbor_idx workaround.)

Given this will take some time, but I'm eager to get this out in the world, here's my plan:

1. Fix all gameplay bugs.
2. Launch at penrosepipes.vercel.app and announce on HN, X, etc, making it clear that this is a prototype and my intention is to clean it up and merge to hexapipes.
3. Deal with less urgent but annoying design problems like the inconsistencies in the generator, and any issues you raise in code review. Respond to feedback from players. Make the generator a proper package and publish it to npm.
4. File a PR.
5. Assuming we agree on something that can be merged, penrosepipes.vercel.app can serve in the long term as a staging area for further improvements. I'd like to improve the ragged edge resolution, think the splines could be even smoother, etc.

Given my time constraints, this will take months.

I'm so happy with how it turned out. The aesthetic is something greater than what I and you put into it - reminds me of fanciful fonts from the 19th century, with just a touch of psychedelia. Or maybe Art Deco.

[gereleth]

I made a quick fix for the missing legs problem in the p3 branch. The logic is to just keep the same direction if we don't have a neighbour to bend for =). My commit touched a lot of lines but the only meaningful changes were around line 220 (the rest was auto formatting on save). I think this looks ok (preview link).

A more sophisticated approach could use invisible neighbours for bend info but that would be overkill imho =).

[gordonwoodhull]

That's a nice solution! Indeed I was trying to look for the invisible neighbors, which is not necessary here. In fact I think it's better to go straight to emphasize that there is nothing there.

I haven't tried slowing down the animation yet, but I think it will transition fine, since there are the same number of points per arm (and it's not trying to change between line and curve).

I've been playing a lot this week and it really picks up in difficulty on larger grids. This means that if you are playing at your limit, the variation in grid sizes (from a little larger than NxN tiles to almost 3xNxN) can make the difficulty and play times of a particular size erratic.

So I think I will shrink the polygon after generation and throw out tiles until the size is closer to NxN. Seems wasteful but it should be fast since I can use binary search and the triangle intersection code that I got from SO is wicked fast.

[gordonwoodhull]

I'm tired this weekend, so I've been messing with ragged border resolution rather than fixing the other grids.

There was an obvious (in hindsight) bug in the fill algorithm, where it was checking for a string suffix incorrectly:

-            tri => find_tris.some(find => find.indexOf(tri.coord) === find.length - tri.coord.length),
+            tri => find_tris.some(find => find.endsWith(tri.coord)),

With that corrected, the fill algorithm delivers less portion of tiles with two sides on the border 80% of the time, across many grid sizes. The drawback is that it isn't specifically looking at degree, so it delivers grids with some tiles with three sides on the border 2-6% of the time (worse for small grids). So we'll still need to run cull after fill.

Typical cull:

versus fill:

I've been playing a lot of Penrose Pipes at many sizes, and I remain very happy with the gameplay and the aesthetic.

It will be fun to see the more difficult grids your solver produces. The dailies are very hard even with the cube grid, whereas Penrose is pretty easy with the current settings. I have to go to really big grids to get stuck at all in "proofs mode".

[gordonwoodhull]

Hi @gereleth - do you have linting or formatting tools I should apply so that merges are less messy?

[gereleth]

I use prettier for formatting, npm run format should do it. I normally just have VSCode format files on save.

[gordonwoodhull]

Okay, soft launch of penrosepipes.vercel.app is live!

Please test to see if you find any more issues. I'll announce later this week.

[gordonwoodhull]

Posted on HN and X, please upvote: https://news.ycombinator.com/item?id=37842719

I'll probably repost on Sunday morning. EDIT: The rules say not to repost, although some blog said it's okay. Oh well, was nicely received if by a limited number of people.

I changed the footer a little bit to add links to both repos and handles. Hopefully it's clear where to post feedback... will adjust if necessary.