gordonwoodhull / hexapipes Goto Github PK

This fork of hexapipes implements clipping of pipes to the tile polygon. Additionally, the arms are drawn 20% longer to compensate for iOS line cap rendering issues. The idea is, draw past the edge of the tile and then clip.

This was originally proposed as gereleth#101

Base hexapipes instead uses stroke-linejoin: round and extends the colored part out past the edge of the tile in order to "smudge" the subpixel line that will appear otherwise.

The smudge works better where it works, on the non-Penrose tiles and on operating systems besides iOS. The jury is still out on which is better for the cube grid.

Tile polygon clipping should be optional, and only enabled for Penrose and for iOS.

I used simple splines with the two control points set equal, because these are easy to understand. The spline is confined to a triangle formed by the three points, and tangent to two of its legs.

The points of the triangle are the center of the tile, the end of the “symbol”, and the point where the line between symbol arm ends on the two tiles intersects with the edge between them.

The final slope of the arm of one tile is the same as the starting slope of the arm on the next tile, but I think it would be smoother if the velocity of the spline going through the tile edge is the same on both sides.

IIUC this means the two control points should remain on the sides of the triangle, but their distance from the center point and edge point should be a constant. You can see this in vector drawing programs where the magnitude and direction of control points across an end point and into the next segment are mirrored.

This fork of hexapipes implements "arms" rotation, where the rotation is passed into grid.getPipesPath() and the grid is responsible for rotating the arms to match.

In base hexapipes, the entire tile is rotated and pipes don't need to be redrawn per tile.

Only PenroseGrid supports "arms" rotation, so other grids do not currently rotate their tiles when clicked.

"Arms" rotation should be refactored to be optional, and should only be applied to PenroseGrid. It could be useful for other grids where angles between arm positions are non-uniform.

Needs a keyframe in there to animate correctly, right now the arms just go through the center:

Either I made a mistake when rebasing, or there are divergent assumptions in the code.

'Could not generate a puzzle with a unique solution. Maybe try again.'

This is the only grid that completely fails to appear... probably it is something stupid, and easy to fix once identified.

I broke something along the way to Penrose tiles. Should be easy to fix.

The core hexapipes system assumes that a grid will be valid after construction.

This is a reasonable assumption for static grids, but works less well for the Penrose grid, which will be selected and generated randomly from an infinite space of possible grids.

To get it working, I split this grid into construction and initialization phases. This allows the grid to be replaced after construction of the grid object, but there is still an extra grid generated and then thrown away – actually two, because both the puzzle instance and the worker construct and then initialize their own grid objects!

This isn't too much of an efficiency concern, but it's messy, and it makes Penrose grids confusing to troubleshoot.

Compounding the problem, gridInfo in grids.js is initialized by constructing an example grid, and is instantiated on both the puzzle and the worker. So that means that a total of four Penrose grids get calculated and then thrown away on the Penrose pages, and two get thrown away on the other pages. An easy solution for this part is to make example grid construction lazy, and I've implemented this successfully in 86e8227, but it's a partial solution.

The correct solution would involve one of:

1. Always construct and initialize grids separately - a constructed grid would not immediately be valid.
2. Always wait to construct grids until we know if we have data to initialize them. Cleaner but perhaps requires deeper thought.

Penrose pipes is too easy because of the border.

The infinite lazily-generated puzzle is possible, but

• it's a significant engineering and algorithmic challenge
• it would probably be unsatisfying as a game

Another possibility, as suggested by @gereleth in email, is to only require the player to solve the part of a larger puzzle within a region.

That region of the puzzle would need to be connected, so this might require a change to the generator. If any tiles outside the region are generated, they are not used.

"Region" (or section, area, portion - pick one) would be a third topology of grid, along nowrap and wrap.

Visually, the border tiles could fade out to transparent toward the border sides to indicate that those sides don't matter.

I copied the cube grid to get started with the Penrose grid, and so this grid inherited pointy edge marks:

It would be much nicer for the edge marks to be curvy like the pipes, and there are at least two ways to do this:

• Using SVG's stroke-dasharray
• By doing the math to split the splines

It will have the same effect either way. stroke-dasharray will be less code and probably easier; perhaps pathLength can be set to draw the edgemark as a portion of the total length of the pipe spline.

Related to #3 flag for controlling tile polygon clipping, the implementation of tile polygon clipping is inefficient because a clipping path is created for every tile.

There only needs to be a clipping path for each base polygon, because the clip path is relative to the tile center point.

The easy way to implement this is to put the SVG clip paths into a hash and assign an ID. However, for clarity and for debugging purposes, it would be better for polygons to identify their base polygon name/ID, and use that to id their clipPath and the association with tiles.

Then there also the cube grid case, where only one clip path is needed because the square is transformed three ways.

This error shows up in the console on the "choose your grid" page, and then clicking on any grid type does not go to the grid – until you reload, because the URL is rewritten correctly.

          A related problem is that "click to orient" control mode doesn't work correctly on penrose grid.

Originally posted by @gereleth in #2 (comment)

This worked earlier.

In the interest in getting Penrose Pipes out the door, I implemented the Orient/Lock dot using the tile transform and rotation.

This is equivalent to the cube grid implementation, where the same transforms are applied to the g.pipe, since the dot uses the same coordinate system.

This has the following weaknesses:

• The dot is squished according to the transform, and this means it's very squished on the skinny rhombs.
• If I extrapolate the 3D planes of all these jumbled tiles, it gives me a touch of vertigo, but it's not nearly as bad as when the pipes did were in false perspective.
• There is no animation on the dot.
• The dot is not perfectly centered inside its arm - ideally it should be placed on the spline at a little distance from the edge, similar to #7.

I'm not sure, but I think rotations would have to be passed into grid.getGuideDotPosition() and polygon.get_guide_dot_position() and the polygon would need to cache a dot position per direction.

It's also worth noting that this mode makes it easy to trigger #8 wrong animation for 180º turns.

Previous discussion in #6.

So we can import it on the custom puzzle page =).

If you navigate away or refresh the page, you get a new puzzle.

This used to work. The other grids seem okay.