[egeimicu] editing Emacs Lisp

consider editing code with an editor, a very common activity.

transformations to code, editing it, or even just navigating it, can be arbitrarily complex (e.g., jump from function use to function definition), so we want a computer programming language to be able to express and implement the possibilities.  many IDEs are extendable with an embedded language, famously Emacs.  then, we want to do arbitrarily complex edit operations on that embedded editing code, again wanting a programming language to express and implement those operations.  the need for programming languages to edit programming languages continues recursively, infinitely.

Emacs is pretty good for editing Emacs Lisp.  for example M-x apropos sexp lists many functions (and other things) for manipulating s-expressions.

previously, listing some of the possible editing actions.

[mjhowdnw] 3D maze of thin rods

fly anywhere, unimpeded by the rods.  you can see quite far because the rods are thin.  slide a cursor that rides on the rods to the exit.

2D mazes are usually overhead view, providing lots of visibility; thin rods with unlimited camera movement approximates that for 3D.

it might be difficult to tell which of a pair of visually intersecting rods is closer.  add artificial visual cues.

[lrjzlhie] navigating a 4D maze with WASD

present a 4D maze as an array of 2D slices.  navigate among cells in a slice with the keyboard arrow keys with the right hand.  navigate among slices with the W A S D keys with the left hand.

also possible are the two thumb sticks of typical game controllers.

annotations (perhaps literally the letters W A S D) in each cell signify which WASD moves between slices are available.  the UI is therefore somewhat noisy.

6D analogously possible in 3D.  (unspecified: how to move in 3D.)  as is the norm for 3D, you can't see the whole maze at once.  2^6 = 64 rooms in a 6D maze of order 2 could make a nice little puzzle.  64 is small enough to memorize.

[tiitqghi] tesseract rooms

connect 8 cubical rooms in tesseract topology, for a 3D game.  when using a door, you see at most two rooms at a time, so you never directly see the weird non-Euclidean geometry/topology (S^3, 3-sphere) of the hypersurface of the tesseract, namely 4 cubes connected like a tetrahedron around a vertex (vertex figure).  previously.

assuming you can't fly, provide an elevator in each room to travel to vertically adjacent rooms.

you can indirectly experience the weird geometry if you travel in certain loops: your orientation becomes off, probably rotated by 90 degrees (fun with parallel transport and the curvature tensor).  also, a loop of only 3 rooms can return you back to where you started, in contrast to needing at least 4 in flat Euclidean space (and loop lengths are always even numbers in flat space).  game encourages mastering this weirdness.

gravity stays consistent with the previous room.  one can get gravity to change orientation by traveling in a loop; let this be the key game mechanic.  you can't get gravity to change orientation traveling only horizontally in a loop through doors; you must use an elevator at least once.  (I think this is true, reasoning by analogy about the square faces of a 3D cube.)

8 rooms = 48 internal faces (wall, floors, ceilings).  although 3D game is the obvious implemention, 2D overhead view is also possible.  you only see the floor (face) that you are on.  leave things at the edge of a room to transfer from a floor to a wall.  (of course, for a 2D game, e.g., Zelda 1 dungeon, one could get similar weirdness with 6 2D rooms with cube topology.)

divide each cube orthogonally into 8 sub-cubes.  the tesseract then has 64 total rooms (but with adjacency very different from the 64 squares of a chess board).  each sub-cube has one special corner surrounded by weird geometry (4 cubes meet at a point).  I think geometry is locally flat (8 cubes meet at a point) around all the other corners.  64 rooms = 384 faces, counting both sides of faces.

most generally, a collection of polygons connected as a graph.  graph edges between pairs of polygon edges (signifying doors), and each polygon also has "up" and "down" edges (signifying elevator) connecting to other polygons.  perhaps bundle polygons into an abstract polyhedron to allow transfer of objects at an edge.

[hvpuzlgu] 6 knobs to rotate in 3D

3 knobs to rotate around standard axes (yaw, pitch, roll) (future post anchdwzz), 2 knobs to choose latitude and longitude of a different rotation axis, and 1 knob to rotate around that axis.

the "different rotation axis" remains locked to the object when the first three knobs are turned.

how many analogous knobs for 4D?

only one knob needed for 2D.

[btpqmyjz] navigating the diamond cubic crystal structure

in the diamond cubic crystal structure, each carbon atom connects to four others.  this provides a way to navigate 3-space with only a 4-way decision at each point: 4 buttons suffice, less than the 6 of going orthogonally.

2D analogue: the vertices of a hexagonal honeycomb.  each vertex has 3 neighbors, less than the 4 of the square honeycomb.

in both 2D and 3D, there are two different types of nodes (vertices) that alternate: one type with outgoing edges in one set of orientations, the other going the other way.  the 4 buttons (for 3D) will correspond to different directions depending on which type of node you are at.  perhaps repeatedly hitting the same button executes a 2-cycle, bouncing back and forth along an edge.

a dungeon whose rooms each have up to 4 exits (e.g., Zelda 1), but the topology is not a plane but 3-space.

the Voronoi cell is the triakis truncated tetrahedral honeycomb, corresponding to the equilateral triangular honeycomb in 2D, with every other triangle upside-down.

consider one tetrahedron in the tetrahedral-octahedral honeycomb.  go to another tetrahedron by traveling orthogonally through a face, through an octahedron, to the next tetrahedron.  this is possible because tetrahedra and octahedra alternate in the honeycomb, and an octahedron has opposite pairs of parallel faces.  I strongly suspect this graph among tetrahedron centers is the diamond cubic lattice.

are there analogues in higher dimensions?  first thought for 4D is the edges of the 24-cell honeycomb, 16 edges per vertex.  but the edges of a tesseract honeycomb is better, 8 edges per vertex.  it should be possible to do better.

any graph (starting from any lattice in any number of dimensions) can be made into a cubic graph (all node degrees 3 or less) by replacing nodes with too many edges by rings (traffic roundabouts).  3 buttons suffice.  roundabouts allow U-turns by going all the way around, so one does not need to provide a "go back" button.  2 buttons suffice: exit roundabout or keep going around.  we would still prefer roundabouts with fewer outgoing edges.

[gwyhglin] permutation group maze

(say) 6 items in a row.  touch the space between adjacent items to swap them.  goal is to put the items in their "correct" order.  this is how bubble sort works, so it is always possible: isomorphic to the symmetric group.  6 items = 720 states (6!).

run a maze generation algorithm on the graph of states.  items in a row as before.  this time, the space between adjacent items has an indicator indicating whether that pair may currently be swapped.  (previously, push button maze.)  better is for the indicator to provide lookahead: if swapped, illustrate what further swaps will be possible in the next step.  720 states is probably the maximum a human can mentally keep track of, because he or she does not get an overhead view of all points (states) of the maze.  or, 5 items, 120 states.

illustrate items being in the right or wrong spots in memorable ways.

instead of 6 items in a row, let them be laid out in a connected graph.  select an edge to swap.  illustrating lookahead and memorably illustrating states seems more challenging.  maybe 6 kings and 6 kingdoms: things not only go wrong in a kingdom with the wrong king on a throne, but the troubles cascade throughout the realm.

vaguely similar: Grow Cube, but any permutation permitted.

back to 6 items in a row.  instead of swapping 2 adjacent items, consider cycling 3 consecutive items.  each set of 3 can be 3-cycled in two different directions.  this is isomorphic to the alternating group.  6 items, 360 states; 5 items, 60 states.  without any maze-like restrictions, it is easy (as confirmed by experiment) to correctly order to any start permutation with the correct parity.  one can use an algorithm similar to bubble sort.

as before, run a maze-generating algorithm on the underlying graph of states.

for a point-and-click UI, on-screen buttons corresponding to 3-cycling ABC and CDE can be on one side of the row of items, and BCD and DEF can be on the other side of the row.  overlapping 3-cycles are therefore not geometrically a UI problem.  (4-cycles and beyond would be less elegant.)  each 3-cycle button is divided into two parts corresponding to the two possible 3-cycling directions.  or, could use two mouse buttons.

for a touchscreen UI, simply swipe the 3 items in a row that you wish to cycle.  however, once we add maze-like restrictions, indicating which operations are permitted will require annotations off to the side.

depicting lookahead seems challenging.

as before, we can also consider items laid out not in a row but in some planar graph.  probably best is as a map of regions.  the map has some line segments drawn on it, each line segment passing through exactly 3 regions, indicating which regions may be cycled.  we could also try to have all regions the same shape (even translationally congruent) to illustrate that all items can fit into any slot, but it becomes tricky to insure that straight line segments exist through the 3-cycles we wish to permit.

9 dots (9!/2 = 181440 states) in a 3 by 3 grid seems an attractive layout for many possible 3 cycles in straight lines, vaguely similar to pattern-unlock on Android smartphones.  also 8 dots (omit center), 7 dots (like capital H), 6 dots (right triangle), 5 dots (like capital L or T or X).  6, 7, and 9 dots permit diagonal 3-cycles through the center dot.

physical UI: map of regions.  at every junction of 3 regions meeting at a point (tri-point) is a knob which can be turned in two possible directions to execute a 3 cycle.  lights on the knob and haptic feedback can indicate whether an operation is permitted according to the underlying maze.  a tesselation of regular hexagons has three hexagons meeting at each point.

depicting lookahead seems even more challenging.  memorably depicting states remains desirable.

the 15-puzzle is isomorphic to the alternating group, though I don't know details.

beyond symmetric and alternating groups, we could consider permutation representations of other finite groups, though many are large.  they may be tricky enough not to need imposing a maze over them (e.g., Rubik's cube group).  among finite simple groups, the Mathieu groups seem promising.

[lvuhuxtd] 3D layers

adapt the feature of "layers" of 2D drawing programs into a 3D design program.  this has likely already been done.

move stuff between layers.  translate an entire layer.  duplicate and delete layers.

provide such a feature in Minecraft.  inspired by the nether: what if the nether were more useful for building stuff in the overworld, even in creative mode?  store partially built stuff there, which can easily be fetched.

a stack of many 3D layers almost feels like 4D.  however, layers can be reordered, and one can't do 4D rotations.

[ppvfjatl] programmable mouse

some features desirable in a hypothetical programmable mouse:

1. any (decent) programmable mouse can assign programmable mouse buttons to actions "button 1" (left click), "button 2" (middle click), "button 3" (right click), "button 8" (browser back), "button 9" (browser forward).  however, we would also like to access actions "button 4" (scroll up), "button 5" (scroll down), "button 6" (scroll left), and "button 7" (scroll right), assigning them to arbitrary buttons, not just to the scroll wheel.

   "button 6" and "button 7" actions are rare.  they are emitted by Logitech MX Ergo: the scroll wheel clicks left and right, which was surprising to discover.

2. the button numbers above are as reported by the xev program.  how large can button numbers be?  at first, the USB HID spec for mouse seems to suggest the largest possible button number is 8, but the common existence of button 9 (browser forward) disproves that.  we would like a programmable mouse to be able to emit button numbers as high as they can go.

3. clicking the scroll wheel left and right, mentioned above, is a desirable feature.

4. assign scroll wheel (up, down, left, right, and push) to arbitrary actions.

5. assign a button to mean double-click of a button action.  and triple-click.

6. scroll wheel acceleration: if the user makes many rapid "clicks" with the scroll wheel, it emits extra scroll actions (not one-to-one with clicks), allowing rapid long distance scrolling.

7. many gaming mice offer a button or two to adjust DPI.  let those buttons be programmable, assignable to something other than adjusting DPI.

8. drag lock: click a button once to send a button-down action, then click again to indicate button released.  LED or haptic to indicate that this is in progress.

[uphrssad] logarithm calculator interface

two rows of digits, x and log10(x), inspired by (common) log tables.

move a cursor to select a digit to adjust.  can adjust either row.  the other row recalculates instantly.

shortcut: set all digits to the right of cursor to zero.

perhaps if you adjust a digit, all digits to the right automatically get set to zero.  if so, digits must be entered from most significant to least.  however, panning through a range with the next less significant digit set to 5 seems like a useful operation to enable.

if you try to go beyond 9, does it stop, cycle back to 0, or adjust the next most significant digit?  provide both of the last two: buttons adjust individual digits, cycling back to zero.  a knob adjusts the next most significant digit, allowing panning through a range.

range of x: 1.00... to 9.99... ; range of log10: 0.000... to 0.999...  no need to worry about sign, overflow, floating point.

difficulty: as an example, assume 3 digits on each row as above.  entering x=9.99 has the correct answer log10(x)=0.99957 which should round to 1.000 but that number cannot be represented.  suppose it instead outputs 0.999.  but 10^0.999 = 9.98 not 9.99 .

perhaps a plus indicator 0.999+ denoting a number between 0.9995 and 1.

similar issues happen around 1.00 = 10^0.000 = 10^0.001 = 10^0.002 , and probably other places.  previously.

another partial solution: UI element to specify which row represents the exact number.  perhaps it lights up (indicating availability) only in corner cases such as above where x != inverse(f(x)).  editing a digit probably chooses that row to be exact, though vaguely plausible not to.  if not, internal representation is messy.

the shortcut mentioned above to set digits to the right to zero and the UI element to select the row which represents an exact number seem related: "exact" means all digits to the right (especially those beyond the display) are zero.

consider the same thing but in binary and log base 2.  blinky lights, buttons to toggle bits (but we also want pan).  range of x is 1.00... to 1.11... , so the leading bit, always on, is superfluous.  shortcut to set all bits to the right to zero is even more necessary, as UI will likely present many bits.

provide another device or mode with a similar interface to convert between binary and decimal.

app?  undo?  copy/paste?  error-correcting code for accurate copying?  input and output are general problems.  logs then get added, multiplied, etc., elsewhere.

[ipdnldrn] navigating a Hilbert curve

consider a Hilbert curve on a grid.  navigate around the grid with 4 arrow keys.  navigate along the curve in 2 directions, forward and backward.  zoom in, zoom out (zooming has some tricky details).  8 buttons total.

[ivoikwee] Verifiable randomness

Casinos have many games that rely on randomness.  It's surprising that they haven't deployed technologies that allow players to verify that the randomness is actually random: players might enjoy having proof that the house isn't cheating them (at least, not cheating by sampling from a probability distribution different from what the player is expecting).  We propose a cryptographic scheme to do this: the house proves to the player that the house would have had to do an exorbitant amount of work to choose a random seed that favors the house.

House secretly chooses a nonce NH and announces Hash(NH), the cryptographic hash of NH.  It is in the house's best interest to choose NH so that it is different every time and hard to guess by the players, e.g., 256 bits of true randomness.

Players then each publicly announce their own nonce strings in two stages.  First, each player announces Hash(NP) of their nonce string NP.  The strings NP should be different every time and hard for an adversary to guess, e.g, 256 bits of true randomness.

In the second stage, all players then publicly announce their NP.  Everyone can verify that the hashes match what was announced in stage 1.  We do player nonce announcement in two stages to thwart the house planting a confederate among the players.  If the players were to announce their nonces directly, the confederate, announcing last (somehow), also having access to the house's secret NH, could choose a NP that cancels out the other players' nonces and manipulates the pseudo random number generator.  Players' nonces must have a lot of entropy to prevent a house confederate from inverting hashes via brute force.  Hash function needs to be collision resistant so that a house confederate among the players cannot construct two nonces with the same hash, then strategically reveal one of them in stage 2.

Still need to think carefully whether the house bribing some players might be a problem.  In general, collusion between players in multiplayer games is tricky.

Instead of 256 bits of true randomness, it might be possible to substitute less randomness and a computationally expensive hashing function like Argon2i.

House secretly combines NH and all the players' NPs in a specified deterministic way to seed a specified cryptographically secure pseudo random number generator.  The nonce-combining operation needs to use a cryptographic hash so that neither the house nor the players can manipulate or predict the PRNG by carefully selecting their nonces.

Then, play the game, sampling in a specified way from the PRNG when randomness is needed.

After the game, house reveals NH.  Players can verify that its hash matches the Hash(NH) announced earlier.  Now that they know NH and all the previously publicly announced player NPs, each player can recreate and verify all random sampling that occurred during the game.

For a game like poker, this means players can, after a hand, determine what everyone's cards were, so learn who was bluffing.

All this is easy to do for online gaming.  Physical casinos would have to stop using classic physical randomizing devices like cards, dice, and roulette wheels.  Those classic randomizing devices have served to convince players that the house is not generating skewed randomness; this proposal represents improved technology to that end.  (Slot machines are already controlled by computers; it's basically online gaming.)  Perhaps the classic devices can be kept as tools to help players generate their nonces, like adding entropy to /dev/random.  (Previously, a speed cube might be a good compact entropy generating device.)  However, they are not ideal because the classic devices are designed to generate their randomness publicly; in contrast, a player must keep secret his or her random player nonce during stage 1.

If the house's announced NH does not hash to the previously announced hash, or if the samples from the PRNG do not match what the seed should have produced, then the player has the option to invalidate the preceding play.  Presumably the player will only exercise the option if the player lost.  If there are many players, then any player can exercise the option.  However, if the house plants a confederate among the players, they might be able to conspire to invalidate games in which the house, or players colluding with the house, lose.  Such behavior might be obvious, and the house regularly failing to behave correctly will contribute to a bad reputation.  However, this general problem still needs more attention.  Maybe the house pays all players the maximum payout if the house behaves incorrectly.

Possible methods for nonce generation and transmission: mobile phone app, QR code.

Perhaps this kind of multi-party initialization of a random number generator could be done for drawing lottery numbers, nowadays done with transparent ball machines that serve to try to convince players that the balls are being picked uniformly randomly.  The two-stage procedure described above for players submitting nonces requires more work by the players, more than just buying a lottery ticket.

[citevhpr] abandoning sentence capitalization

this blog will gradually transition to abandoning capitalization at the beginning of sentences.  the reason is to avoid fighting with autocorrect on touchscreen keyboards: a word capitalized (at the beginning of a sentence) gets added to the dictionary in capitalized form, as if it were a proper noun.  when typing the word later, the capitalized form is then sometimes automatically preferred, even if now not the first word of a sentence.  also, it is annoying to have to adjust capitalization when adding words to or removing words from the beginning of a sentence.

proper nouns will remain capitalized: i helped my uncle Jack off a horse.

(challenge: craft a sentence which is ambiguous when following the standard conventions of sentence capitalization, but which becomes unambiguous if only proper nouns are capitalized.  it would be similar to the example above, but with the word jack as the first word of the sentence.)

when i can remember to do so, sentences will continue to be separated by two spaces to avoid ambiguity with abbreviations with periods (e.g., e.g.) in the middle of a sentence.   three spaces might be even better now that we no longer have the cue of capital letters to mark sentence boundaries.   however, i'm currently having to fight software insisting on encoding three spaces as  _  instead of   _ .

[ohooqvfv] Worst button-mashing game ever

Phase 1: Mash a button a million times to earn the right to face the final boss.  At 8 button presses per second, this will take 35 hours.  Probably best is to allow any button to count as a button press to decrease the stress on any one button or finger.  In order to discourage pressing multiple buttons simultaneously or rapidly alternating between different buttons, the first press of a button different from the previous press does not count: repeated presses of the same button is the object of (this part of) the game.

Then, the final boss is purely RNG.  What should the probability of winning be?  Perhaps 1/4: choose wisely for a single button press among A B X Y.

Inspired by the difficulty of speedrunning when there is a task late in the game that is heavily dependent on the random number generator.  In particular, this was inspired by the reverse engineering of the RNG for Sploosh Kaboom in Zelda Wind Waker (Linkus7, et al.).  Our button-mashing game seeks to create the worst possible speedrun experience.

Slightly more sophisticated Phase 1: each button mash has 25% probability of earning 1 point, sort of similar to the final boss.  You need to accumulate 250,000 points to complete Phase 1.

Evil: The Phase 1 RNG could be deterministic, the same every time.  But no unassisted human will be able to memorize the very very long sequence that lets you complete Phase 1 faster.  Let the Phase 1 RNG also depend on user inputs, so a single "mistake" causes the subsequent play to become totally different.  The sponge construction (e.g., Keccak) might be good for this kind of RNG.

The final boss should remain totally unpredictable.

[zldaysbj] Touchscreen Hackenbush

Hackenbush seems like a game perfectly suited for a touch screens app.  Swipe to cut, two-finger zoom if some region needs magnification.

[ttvonnhe] Action sequences to be rewatched in slow motion

What movie action sequences are enjoyable to watch artificially slowed down?  There is good stuff going on that is too quick for the eye to notice at normal speed.

This is modern filmmaking: some, perhaps most, of the audience is going to watch the movie on a platform (e.g., PC, smart TV) that can do slow motion.  Modern filmmaking anticipates interaction.  It is not the old-school big screen where the audience got no interactive control.

[dtlxfpth] Three-way switch with push buttons

Consider replacing the common electrical setup of two up-down light switches controlling one light in XOR fashion with two push buttons.  Each push button toggles the current state of the light.  The wiring of the three-way switch remains the same: we are only concerned with the user interface.  Push buttons avoid the confusing local state of a light switch being on (up) but the light being off.

[vkoimpmq] Common and uncommon cases in documentation

Consider structuring documentation around the adage "make the common case easy, but keep the uncommon case possible".

First, document how to do the common cases.  Then, show how there's enough rope to do whatever uncommon case the user might dream up.

This assumes your product has such features, which is a big assumption.  A lot of products these days are depressingly designed around allowing the user to do common cases but intentionally preventing the user from doing uncommon cases, e.g., with DRM or closed source.

If free (libre) software is the way one is providing the means to do uncommon cases, documentation should include documentation about the source code, including how to modify.

[weylfetj] Watching computer chess for a long time

Have a computer play chess against itself for a long time, months to years.  What about this might be entertaining for people to spectate?

One thing that probably won't be entertaining is a single game with a very long time control.  It will probably be a boring draw.  It is also a bad fit with technological advancement.  Computers (and software) become better over time, but a game becomes easier over time, with fewer and fewer pieces.

Three possibilities likely more entertaining:

1. Watch the development of opening theory.  Let the computer play many games against itself and do Monte Carlo tree search, probably also with reinforcement learning as Alphazero did.

As the computer becomes more powerful over time, the opening transposition table can become larger, neural networks can become larger, searches can become deeper and wider.  All of these (hopefully) lead to improvement in opening play.

A human spectating the computer's development, giving it attention occasionally, can query, what are the most interesting changes the computer discovered in opening theory since the human last checked?  Why did those changes occur?  (The reason may be because of a discovery of a key move, and continuation, that busts a line previously believed to be good.)  These are the same questions one asks about the development of opening theory in human games.

Some difficult UI issues: how can a computer quantify how interesting a change to opening theory is?  How can a computer explain why a opening is better?

2. Watch the development of endgame theory.  The simplest version is a progression over time of the computation of endgame tablebases from few pieces to more.  Again, this sort of lines up with computers becoming more powerful over time.

On one hand, it doesn't line up too well computers becoming more powerful because a tablebase of N+1 pieces requires so much more computing power than N that one may have to wait years for computers to become powerful enough to go one piece more.

On the other hand, there are some incremental steps that may be entertaining to spectate that require less computation than calculating a whole tablebase.  Find the positions one more step away from checkmate (or reduction) than previously calculated.  Show the interesting positions.  Keep refining machine learning to compress better existing tablebases or portions thereof.  Show interesting positions that the machine learning algorithm "recently" learned to play or classify correctly, and explain how it's doing so.  (But neural networks are especially bad when explanations of how or why are desired.)  Again, there are a bunch of UI issues, including how to quantify "interesting".

3. We reconsider a variation of the initial rejected idea of a single deeply calculated game of a computer playing itself.  Assuming we can quantify "interesting", we can have the computer play many not-so-deep games against itself and provide to spectators only the most interesting ones, at a rate tuned and suitable for the attention humans will give it.  (Probably around 1 game per week.)  Or maybe instead of an interesting game, just an interesting position that occurred in a game.  Humans will demand higher thresholds of interestingness over time: they become bored of things similar to what they have already seen.  The computer becoming more powerful over time can play more games, filter more exclusively, and deliver higher interestingness over time.  This repeated self-play could also be part of a Monte Carlo framework described above for improving computer play.

We don't have to limit to orthodox chess.  Consider calculating these on Chess960 and other chess variants.

[xpffilzj] Variations on Tetravex

Consider some variations on Tetravex as a computer game (GNOME Tetravex).

Pieces can be rotated (physical versions of the puzzle can do this).  Some sort of knob UI with haptic feedback would be nice.  Pieces can be flipped, resulting in mirror image.  Up-down and left-right spring-loaded levers would be nice, allowing the user to choose which way to flip, though regular arrow keys are probably just as good.  Or, not mirror image: the other side is a completely different piece, creating an additional challenge of choosing which side of the piece to use.

Cube-shaped pieces could extend the theme even further.  We might want a physical input device for rotating a selected cube on a display.  Although the faces could be completely independent, it would be elegant if wedges across an edge share the same color.  There's probably considerable challenge in making the puzzle globally difficult (e.g., having a unique solution).

Toroidal universe.

Various other shapes that tile edge-to-edge: rectangles (only 180 degree rotations, unlike squares), equilateral triangles, regular hexagons.

Higher dimensions: cubes, boxes, 24-cell.  The obvious analogue in, say, 3D is to make it a face matching puzzle, but we could also consider keeping it an edge matching puzzle.  For example, for cubes, their edges are colored and the 4 cubes that meet at an edge must share the same edge color.  Similarly, in 2D (or more), we could consider a vertex matching puzzle.

More than one tile type: useful are uniform tilings and uniform honeycombs in various dimensions, though I think there are nice tilings that are not uniform, for example, rectangles (though that's only one tile type).

Pieces having distinct and distinctive names might be useful for remembering what pieces you have and what they look like.  Maybe an image in the center:  Faces of people you know.