Ignoring one's currently available pieces and half-completed puzzles (which is a very big ignore!), the value of a piece should look something like v=v(points,rewardPiece,complexity,t), where t is the mean number of remaining rounds until game end. My contention is then that dv/dpoints is increasing in t, while dv/drewardPiece is decreasing in t. In fact, since one generally acquires more and more diverse pieces as the game goes by, the absolute value of dv/dcomplexity should also decrease over time.

I'll take a look at the single-player rules, and see if I can get some specific calculations done.

This sounds about right to me. Rather than jumping straight to the solo-rules, which I think could be comparably difficult to the multiplayer rules, perhaps we can try a controlled experiment. Here's what I'm thinking, a mini-game called "Project L: 0-1-2-3-4-5":

• The Project-L game cards are sorted into piles according to points, one is drawn at random from each pile, and the six cards are stacked faces hidden from 5 on bottom to 0 on top.
• The mini-game is for one player, or possibly multiple players in parallel.
• Player(s) seek to complete their card stack in as few turns as possible.
• The zero point card can be passed.
• The turn-action rules are the typical ones.
• For one-player, the win condition is finishing in the minimal number of turns.
• For two-players, the winner completes the stack in fewer turns.
• In case of a tie, all sorts of breaker options are available
• Scoring by pieces, minimum physical time, etc.

There are a few reasons behind this mini-game. Since the state space is strictly limited, the multiway graph of all possible plays could possibly be enumerated, especially using branch and prune. This would require considering at most about a half-million plausible solutions, heavily weighted to the last two or three levels. A lot of pruning can be done by the fact that solutions with too many pieces take much longer to play. This sounds like a challenging problem to solve, but I think it's do-able. If we try and fail to get exact results, at least we're starting something...

In total, there are over 300,000 possible six-card sets, and that leaves room for variation of difficulty. Once a solver is made for one particular game, it can be mapped over examples, and the examples could then be compared for difficulty. This would be an excellent chapter for the games book, I think.

Also worth mentioning, I have solved all the Project-L cards, but ended up getting side-tracked and possibly never found an opportunity to report all results:

we can talk more about this soon...

Hi Victor, Thanks for your interest!

We are slowly but surely moving ahead with this project, and FindExactCover should go through WFR pretty soon. The final write-up will be more interesting than these basically public-facing notes I have here, because we're starting to understand why timing statistics look the way they do. Unfortunately, we still haven't succeeded in compiling Knuth's Dancing Links X, which is the main outstanding "To do" item on this mini-project.

That's nice that you figured out how to go faster making the cover matrices. I also improved this code while I was running more tests on the actual solvers (where the bottleneck really is):

PieceRotations[True, True][piece_] := Union[
  ResourceFunction["ArrayRotations"][piece]]

PieceRotations[True, False][piece_] := Union[
  ResourceFunction["ArrayRotations"][piece, False]]

PieceRotations[_, _][piece_] := {piece}

PieceTranslates[piece_, shift_, dims_
  ] := With[{inset = PadRight[PadRight[#,
        dims[[2]], 0] & /@ piece,
     dims[[1]], {ConstantArray[0, dims[[2]] ]}]},
  Catenate[Outer[RotateRight[inset, {#1, #2}] &,
    Range[0, shift[[1]] ], Range[0, shift[[2]]], 1]]]

PartialCoverRows[tfRot_, tfRef_
   ][template_, piece_] := Module[{
   tot = Total[piece, 2],
   zeroes = Position[template, 0],
   rot = PieceRotations[tfRot, tfRef][piece],
   dims = Dimensions[template], shift, candidates},
  shift = Map[dims - Dimensions[#] &, rot];
  candidates = Catenate[MapThread[
     If[MemberQ[Sign[#2], -1],
       Nothing, PieceTranslates[#1, #2, dims]] &,
     {rot, shift}]];
  Select[Outer[#1[[Sequence @@ #2]] &,
    candidates, zeroes, 1],
   Total[#] == tot &]]

MatricesToCoverMatrix[template_, pieces_,
  OptionsPattern[{
    "Rotations" -> True,
    "Reflections" -> True,
    "PlaceOne" -> False
    }]] := If[TrueQ[OptionValue["PlaceOne"]],
  Catenate[MapThread[Function[{piece, ind},
     Join[ind, #] & /@ PartialCoverRows[
        OptionValue["Rotations"], OptionValue["Reflections"]
        ][template, piece]],
    {pieces, IdentityMatrix[Length[pieces]]}]],
  Catenate[PartialCoverRows[
       OptionValue["Rotations"], OptionValue["Reflections"]
       ][template, #] & /@ pieces]] 

Would you want to see this as a WFR? If yes, can you think of a better name for it?

It should be about as fast as what you have, but it's also keyed in with some options and better free space recognition. The design is so that it's easy to make the cover matrix for "Scott's pentomino problem" from Knuth's arxiv article:

pentominoProblem = MatricesToCoverMatrix[
   ArrayPad[ConstantArray[1, {2, 2}], 3, 0],
   upToPentominos[[5]], "PlaceOne" -> True];

Dimensions@pentominoProblem

Out[]= {1568, 72} 

We can find all solutions of this matrix, but our times are still a little slow compared to industry standard (due I think to not having compiled code). Assuming you can make this matrix, what's your fastest time for solving it with Mathematica code?

-- you have earned Featured Contributor Badge Your exceptional post has been selected for our editorial column Staff Picks http://wolfr.am/StaffPicks and Your Profile is now distinguished by a Featured Contributor Badge and is displayed on the Featured Contributor Board. Thank you!

Yes, Caveat Emptor! Because we generated so much content more than was really necessary to get the point across, now we're adding more off our list of omissions with insightful results about the Project L Board Game. There's nothing better than getting carried away generating tangentially related exciting content; the purpose of Project L Board Analysis is to provide reproducibility so that we as your summer school students can verify our results and raise an open-ended, evolving solution with Q & A; there's a chance for innovation and originality, like The Story of Spikey. From a mathematical viewpoint the board game "Project L" simply asks players to solve exact cover problems given limited resources and time constraints. The description helps tremendously; Project L is the kind of thing you wanna play with your friends and learn more about because there are so many shapes like the yellow monominoes, green dominoes, orange or blue trominos, and five singly-colored tetrominos. These are called Polyominoes and there are 90 in the picture. Project L Board Analysis can be rephrased as a combinatorial problem within which the full set of tiles is the starting point, that players would build up by the end of the game. For each puzzle, the weight metrics are:

1. The number of points in the top left corner,
2. The grid size (or weight) of the polyomino rewards piece,
3. The grid size of the to-fill-in recessed, white, inner regions.

Since the player with the highest score wins, we can assume that every point value P is in fact an expected time T = P to completion. This assumption is the number of points which is awarded in the top left corner, assuming a linear relationship between complexity and time to completion. W/T' = (T/T') * W/T. With the link between P = T, we can write W/T' = (P/T') * W/P. The player can choose three consecutive actions:

• A puzzle is drawn from the bank at no cost.
• A tile of weight N is played into the puzzle.
• A tile of weight 1 is drawn from the bank.
• A tile of weight N is traded to the bank for another of max weight N+1.
• Multiple tiles of total weight X can be played into consecutive puzzles. (This play of X per one time interval is usually the player's maximum power action, since total weight is a summation of up to four individual tile weights (players can have at max four puzzles on board). The expected time is mostly less than or equal to the actual time to completion T', based on the data science that's how most puzzles in the game are balanced.

With Harshal Gajjar's commendable method from the Tiling of Polyominoes and Brad, (thank you so much for writing it is so good that these results are effectively reproducible. Learning more about gTest and mTest is my thing.), let's take a closer look.

mirrorv[tile_] := Module[{line = {}, tMirror = {}},
  tMirror = {};
  For[i = 1, i <= Length[tile], i++,
   line = {};
   For[j = Length[tile[[1]]], j >= 1, j--,
    AppendTo[line, tile[[i, j]]];
    ];
   AppendTo[tMirror, line];
   ];
  tMirror
  ]
rotatec[tile_] := Module[{line = {}, tMirror = {}},
  tMirror = {};
  For[i = 1, i <= Length[tile[[1]]], i++,
   line = {};
   For[j = Length[tile], j >= 1, j--,
    AppendTo[line, tile[[j, i]]];
    ];
   AppendTo[tMirror, line];
   ];
  tMirror
  ]
allTiles[tile_] := Module[{list = {}},
  list = Join[NestList[rotatec, tile, 3],
    NestList[rotatec, mirrorv[tile], 3]];
  list = DeleteDuplicates[list];
  list
  ]
tiles = {
  {{1}},
  {{1, 1}},
  {{1, 0},
   {1, 1}},
  {{1, 1, 1}},
  {{1, 1},
   {1, 1}},
  {{0, 1, 0},
   {1, 1, 1}},
  {{1, 0, 0},
   {1, 1, 1}},
  {{1, 1, 1, 1}},
  {{0, 1, 1}, 
   {1, 1, 0}}
  }
tiles = Flatten[allTiles /@ tiles, 1];
ArrayPlot[#, ImageSize -> 100, Frame -> None, Mesh -> True, 
   ColorRules -> {0 -> Transparent, 
     1 -> 
      Table[
       Part[{Red, Yellow, Green, Purple, Orange, LightBlue, Blue, 
         Pink, LightOrange}, RandomInteger[8] + 1], 9]}] & /@ tiles

PolyominoGraph[arrayMesh_] := 
 Construct[
  With[{edges = 
      ReplaceAll[MeshPrimitives[#, 1], 
       Line[x_] :> UndirectedEdge @@ Round[x]]}, 
    Graph[edges, 
     VertexCoordinates -> (# -> # & /@ 
        Union[edges /. UndirectedEdge -> Sequence])]] &, arrayMesh]
form = PolyominoGraph[ArrayMesh[tiles[[11]]]]
emptiness = PolyominoGraph[ArrayMesh[ConstantArray[1, {2, 3}]]]

PolyominoCoverMatrix[forms_, emptiness_] := 
 With[{form4Cycles = 
    Map[Sort, 
     FindCycle[#, {4}, All] & /@ 
      Flatten[FindIsomorphicSubgraph[emptiness, #, All] & /@ forms], 
     3], 
   emptiness4Cycles = Map[Sort, FindCycle[emptiness, {4}, All], 2]}, 
  MapThread[
   Join, {IdentityMatrix[Length@form4Cycles], 
    Function[{cycles}, 
      ReplacePart[
       Array[0 &, Length@emptiness4Cycles], # -> 1 & /@ 
        Flatten[Position[emptiness4Cycles, #] & /@ cycles]]] /@ 
     form4Cycles}]]
CoverGraph[coverMatrix_] := 
 ResourceFunction["NestWhileGraph"][
  Function[{state}, 
   Select[
    state + # & /@ coverMatrix, ! MemberQ[#, 2] &]], {ConstantArray[0,
     Last[Dimensions[coverMatrix]]]}, UnsameQ @@ # &, 2]
CoverGraph[PolyominoCoverMatrix[{form}, emptiness]]
CoverGraph[
 PolyominoCoverMatrix[{form}, 
  PolyominoGraph[ArrayMesh[ConstantArray[1, {3, 4}]]]]]

What are the possible ways that five point puzzles from Project L can be solved, with a relative efficiency greater than one? That is it takes shorter than expected in that we can solve the puzzle faster than the puzzle's point value in the top left corner. How do we define units for time? Can we really measure the tile's usefulness by the proportion of puzzle solutions that display the tile?

The dancing links method allows x to exist in a detached state; it continues to exist on a separate linked list from the one at that we are looking such that we can swap it back in for what's left of right (what's right of left). It's going to be fun. Here's my notebook for the tiling of polyominoes.

f = {{1, 0, 1, 1}, {1, 1, 1, 0}, {0, 0, 1, 1}};
embeds[f_, {n_, m_}] := Flatten[
   Table[
    ArrayPad[
     f,
     {{i - 1, n - i - Length[f]}, {j - 1, m - j - Length[First[f]]}}
     ],
    {i, n - Length[f] + 1},
    {j, m - Length[First[f]] + 1}
    ], 1];
Grid@Partition[
  ArrayPlot[#,
     ImageSize -> 100] & /@
   embeds[f, {5, 5}], 6]
mirrors[tile_] := Reverse[tile, {2}]
rotates[tile_] := Transpose[Reverse[tile]]
tileSet[tile_] := DeleteDuplicates[
  Join[
   NestList[rotates, tile, 3],
   NestList[rotates, mirrors[tile], 3]
   ]
  ]
tiles = {
   {{1}},
   {{1, 1}},
   {{1, 0}, {1, 1}},
   {{1, 1, 1}}, {{1, 1}, {1, 1}},
   {{0, 1, 0}, {1, 1, 1}},
   {{1, 0, 0}, {1, 1, 1}},
   {{1, 1, 1, 1}}, {{0, 1, 1}, {1, 1, 0}}
   };
tiles = Flatten[tileSet /@ tiles, 1];
myColorFunction = ColorData[{"ArmyColors", "Reversed"}];
enhancedArrayPlot[tile_] := ArrayPlot[
   tile,
   Mesh -> True,
   ImageSize -> 50,
   MeshStyle -> Orange,
   ColorRules -> {
     0 -> Transparent,
     1 -> myColorFunction[RandomReal[]]
     }
   ];
Grid[Partition[enhancedArrayPlot /@ tiles, 14], Frame -> All]

I think this really gets to the crux of Project L which is about solving exact cover problems. The idea is, and I finally see the light now, to use polyomino pieces to complete the puzzles within the given set of constraints. For instance let's say I take my fist, and use that as a unit of measurement to build from the simple description of one fist, and then I build upon that. The puzzle gets big, the constraints get big, and the puzzle gets big..nothing else other than the key component of the strategy game known as Project L, where simple mechanics can build up to a sophisticated discourse on resource management, power, and efficiency.

Yes, I know how numpy is the primary foundation of mathematics and computation in Python, whereas in this scenario we're implementing the function of embedding visual representations of the polyominoes and the puzzles, the utility of analyzing piece pseudo-rotations and reflections, and generating possible solutions for tiling puzzles:

rawData = {
   {{1, 0, 0, 1, 1}, {1, 0, 0, 0, 0}, {1, 0, 0, 0, 0}, {0, 0, 0, 0, 
     1}, {1, 1, 0, 0, 1}},
   {{0, 0, 0, 0, 1}, {0, 0, 0, 0, 1}, {1, 0, 0, 0, 0}, {1, 0, 0, 0, 
     0}, {1, 1, 1, 1, 1}},
   {{1, 0, 0, 0, 1}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {1, 0, 0, 0, 
     1}, {1, 1, 1, 1, 1}},
   {{0, 0, 0, 0, 1}, {1, 0, 0, 0, 0}, {1, 0, 0, 0, 0}, {0, 0, 0, 0, 
     1}, {1, 1, 1, 1, 1}},
   {{0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {1, 1, 0, 1, 
     1}, {1, 1, 1, 1, 1}}
   };
VisualizeMatrix[matrix_] := MatrixPlot[matrix,
  Mesh -> All,
  ImageSize -> 100,
  FrameTicks -> None,
  ColorRules -> {1 -> Cyan, 0 -> Pink}
  ]
ShearModal[piece_] := Module[
  {
   dims = Dimensions[piece],
   newArray
   },
  newArray = ArrayPad[
    piece,
    {{0, 1}, {0, 0}}
    ];
  MapIndexed[(#1 /. Rule @@@ Transpose[
        {
         Range[dims[[2]]],
         RotateRight[Range[dims[[2]]], #2[[1]] - 1]
         }
        ]) &, newArray]]
PieceTranslates[piece_, shift_, dims_] := RotateRight[
    PadRight[piece, dims], #] & /@
  Tuples[Range[0, #] & /@ shift]
translation = PieceTranslates[rawData[[1]], {2, 3}, {5, 5}];
Row[{
  Grid[{VisualizeMatrix[#], ArrayPlot[ShearModal[#],
       ColorFunction -> "SunsetColors",
       ImageSize -> 100]} & /@ rawData],
  Grid[Transpose[Partition[MatrixPlot[#,
        ColorFunction -> "LakeColors",
        FrameTicks -> None,
        ImageSize -> 100] & /@
      translation,
     6,
     6,
     {1, 1},
     {}]],
   Frame -> All ]
  }]

Yeah, there's a balance between point value and the utility of reward pieces throughout the gameplay, that's an inherent feature of the game itself where the utility can be mutable. Do we need it to be immutable? Probably not. If you use your imagination the value of a puzzle can be quantified based on these parameters. But why? That would constrain our understanding of the dynamics of multiplayer games and the structure of space-time, which just foreshadows our ability to adapt faster to the future of work.

Considering how the actions of other players could impact individual strategies, there are further choices that can allow us to freely enumerate, for those of us who see these possible plays (and it really does come down to that) for the controlled mini-game version, of Project L, wherein there's a multiway graph and if you look at it from different angles you sort of kind of see that there's neither beginnings nor ends, to the game's complexity and the optimal strategies that we might be able to identify via the timeless computational tutorials on mathematics or the rough introduction to how game analysis works; how can we go beyond intuition to quantify and strategize gameplay?

PieceRotations[_, _][piece_] := {piece}
PartialCoverRows[allowRotation_, allowReflection_][templateMatrix_, 
  pieceMatrix_] := Module[
  {
   zeroPositionsInTemplate = Position[templateMatrix, 0],
   dimensionsOfTemplate = Dimensions[templateMatrix],
   totalOnesInPiece = Total[pieceMatrix, 2],
   rotationsAndReflectionsOfPiece,
   whichPlacements,
   shiftsForPlacement
   },
  rotationsAndReflectionsOfPiece = 
   PieceRotations[allowRotation, allowReflection][pieceMatrix];
  shiftsForPlacement = Map[
    dimensionsOfTemplate - Dimensions[#] &,
    rotationsAndReflectionsOfPiece
    ];
  whichPlacements = Catenate[
    MapThread[
     If[
       MemberQ[Sign[#2], -1],
       Nothing,
       PieceTranslates[#1, #2, dimensionsOfTemplate]
       ] &,
     {
      rotationsAndReflectionsOfPiece,
      shiftsForPlacement
      }]
    ];
  Select[
   Outer[#1[[Sequence @@ #2]] &, whichPlacements, 
    zeroPositionsInTemplate, 1],
   Total[#] == totalOnesInPiece &]
  ]

originalMatrix = ArrayPad[ConstantArray[1, {2, 2}], 2, 0];
freshColorFunction = Function[
   value,
   If[value == 1,
    ColorData["SunsetColors"][RandomReal[]],
    White]];
limeColor = RGBColor[0.75, 1, 0];
arrayPlotWithFreshColors = ArrayPlot[originalMatrix,
   Mesh -> True,
   Frame -> True,
   ImageSize -> 400,
   FrameTicks -> None,
   ColorFunction -> freshColorFunction,
   MeshStyle -> Directive[limeColor, Dashed]
   ];
MatricesToCoverMatrix[template_,
  pieces_,
  OptionsPattern[{
    "Rotations" -> True,
    "Reflections" -> True,
    "PlaceOne" -> False}]] := If[
  TrueQ[OptionValue["PlaceOne"]],
  Catenate[
   MapThread[
    Function[{piece, ind},
     Join[ind, #] & /@ PartialCoverRows[
        OptionValue["Rotations"],
        OptionValue["Reflections"]][template, piece]],
    {pieces, IdentityMatrix[Length[pieces]]}]],
  Catenate[
   PartialCoverRows[
       OptionValue["Rotations"],
       OptionValue["Reflections"]
       ][template, #] & /@ pieces]]
newMatrix = MatricesToCoverMatrix[
   originalMatrix,
   rawData,
   "PlaceOne" -> True
   ];
navyColor = RGBColor[0, 0, 0.5];
newPlot = ArrayPlot[newMatrix,
   ImageSize -> 400,
   ColorRules -> {1 -> navyColor, 0 -> White}
   ];
{arrayPlotWithFreshColors, newPlot}

When you see things through the lens of exact cover problems, where we've got to use polyominoes - the geometric shapes that could represent things like space weather, or the number of angels that could fit on the needle of a pin, we can fill those specific patterns and puzzles. The Mathematica code can simulate these polyomino pieces so that we can maximize the score wherein the ratio of the puzzle's point value to the actual time taken to solve it, whether we consider each puzzle piece, which doesn't actually exist, to be built up via this metric such that building the polyomino engine shows us how to measure the spending capability of the puzzle, such that we can build upon our backtracking algorithms, heapify them..are we analyzing the game's mechanics deeply enough for our purposes? How can we complete a set of puzzles in the fewest number of turns possible?

basicPentomino = {{1, 1, 1}, {1, 0, 0}, {1, 0, 0}};
maroonColor = RGBColor[0.5, 0, 0];
arrayPlotPentomino = ArrayPlot[basicPentomino,
   Mesh -> True,
   ImageSize -> 200,
   ColorFunction -> "GrayYellowTones",
   MeshStyle -> Directive[maroonColor, Dashed]
   ];
embedPieceInGrid[piece_, gridDimensions_] := Module[
   {
    pieceDimensions = Dimensions[piece],
    emptyGrid = ConstantArray[0, gridDimensions],
    embeddedGrids
    },
   embeddedGrids = ConstantArray[
     emptyGrid,
     gridDimensions - pieceDimensions + {1, 1}
     ];
   Table[
    embeddedGrids[[row, column]][[row ;;
        row + pieceDimensions[[1]] - 1, column ;;
        column + pieceDimensions[[2]] - 1]] = piece,
    {
     row,
     gridDimensions[[1]] - pieceDimensions[[1]] + 1
     },
    {
     column,
     gridDimensions[[2]] - pieceDimensions[[2]] + 1
     }
    ];
   Flatten[embeddedGrids, 1]];
pentominoEmbeddings = embedPieceInGrid[basicPentomino, {5, 5}];
gridOfArrayPlots = Grid@Partition[
    ArrayPlot[#,
       ImageSize -> Tiny,
       ColorFunction -> "GrayYellowTones"
       ] & /@ pentominoEmbeddings, 9];
{arrayPlotPentomino, gridOfArrayPlots}

Just pretend that a seemingly simple board game like Project L can become a rich subject for proposing how we can find all solutions to a given problem more quickly than the current implementations. It's like when you're bubbling up on a binary tree and want to swap places, to put it lightly we can just represent everything as a matrix of 0s and 1s, so when we get to the end it unfolds in such a way that we have this auspicious doubly linked list which serves as the foundation of the toroidal structure that allows us to join the recursive, depth-first, backtracking algorithm mania wherein every node has to be some special link; the links dance in the sense that nodes can be easily re-moved and reinserted, and we can't help but cover and uncover the rows, the dead ends, and the list structure that gives us an exhaustive search where depth means accuracy and the iterative approach is exponentially complex. And vectorization just recursively solves exact cover problems, when I ask questions and do the Sudoku puzzle research.

And now for a joke:

I can't understand what's taking so long. I thought this problem was so easy it would already be solved by now. Inefficiency!

Just to put things into perspective, here's a problem that apparently haunted me for over ten years (admittedly, while I was working on some other things in physics too) : :

Problem Statement. 6. Find all possible tilings ways to fit four copies of the following tile in a 7 by 7 grid, without any holes. Make a graphics function to display the results.

And, again copying from a 10+ year old notebook, the polyomino tile is plotted as follows:

ArrayPlot[{{1, 0, 1, 1}, {1, 1, 1, 0}, {0, 0, 1, 1}}, Mesh -> True]

Graphics[{Green, 
  Polygon[{{0, 1}, {2, 1}, {2, 0}, {4, 0}, {4, 1}, {3, 1}, {3, 2}, {4,
      2}, {4, 3}, {2, 3}, {2, 2}, {1, 2}, {1, 3}, {0, 3}}], Red, 
  Line[{{0, 1}, {2, 1}, {2, 0}, {4, 0}, {4, 1}, {3, 1}, {3, 2}, {4, 
     2}, {4, 3}, {2, 3}, {2, 2}, {1, 2}, {1, 3}, {0, 3}, {0, 1}}]}]

This problem is very similar to the one mentioned above, since it involves placing four tiles. However, it is not an exact cover we're looking for, only a partial. Since partial tilings can have holes, an additional constraint is added that results should be sorted by genus. For definiteness sake, let us state that the tile transforms by rotations and reflections and that a hole is any contiguous empty region not incident on the boundary of the 7x7 grid.

Now rather than getting to the 7x7 case right away, let's just "tool up" and run a series of smallish test case to make sure that the tools are working correctly. The 5x5 case is easy enough to work out by hand, essentially it has only two solutions, one of genus zero and multiplicity eight, and another with genus 1 and multiplicity 4:

Grid[Partition[ArrayPlot[#, ImageSize -> 80,
     Frame -> None,
     ColorRules -> {
       1 -> Blend[{Yellow, Orange}],
       2 -> Lighter[Blend[{Magenta, Red}, .25],
         0.4], 0 -> Darker@Gray}] & /@ Join[
    DeleteDuplicatesBy[
     Union[ResourceFunction["ArrayRotations"][{
        {1, 0, 1, 1, 0},
        {1, 1, 1, 0, 0},
        {2, 2, 1, 1, 0},
        {0, 2, 2, 2, 0},
        {2, 2, 0, 2, 0}
        }]], Sort@{#, # /. {1 -> 2, 2 -> 1}} &],
    DeleteDuplicatesBy[ResourceFunction["ArrayRotations"][{
       {0, 1, 0, 1, 1},
       {0, 1, 1, 1, 0},
       {2, 2, 0, 1, 1},
       {0, 2, 2, 2, 0},
       {2, 2, 0, 2, 0}
       }], Sort@{#, # /. {1 -> 2, 2 -> 1}} &]]
  , 4], Spacings -> {1, 1}]

Now let's try to get the same result, without just typing numbers into a matrix as are seen to fit. First, we transform the matrix polyomino into a mesh, then into a graph:

PolyominoGraph[arrayMesh_] := Construct[With[{edges = ReplaceAll[
       MeshPrimitives[#, 1], 
       Line[x_] :> UndirectedEdge @@ Round[x]]},
    Graph[edges, VertexCoordinates -> (# -> # & /@ Union[
         edges /. UndirectedEdge -> Sequence])]
    ] &, arrayMesh]

form = PolyominoGraph[
  ArrayMesh[{{1, 0, 1, 1}, {1, 1, 1, 0}, {0, 0, 1, 1}}]]

And we can do the same with the grid space where this tile and one other copy will be placed:

emptiness = PolyominoGraph[ArrayMesh[ConstantArray[1, {5,5}]]]

Now for some magic (using 13.1 because we noticed a bug!), sorry you'll have to figure the nuts and bolts of these next two functions on your own:

PolyominoCoverMatrix[forms_, emptiness_] := With[{
   form4Cycles = Map[Sort, FindCycle[#, {4}, All] & /@ Flatten[
       FindIsomorphicSubgraph[emptiness, #, All] & /@ forms], 3],
   emptiness4Cycles = Map[Sort, FindCycle[emptiness, {4}, All], 2]},
  MapThread[Join, {IdentityMatrix[Length@form4Cycles],
    Function[{cycles}, ReplacePart[Array[0 &, Length@emptiness4Cycles],
       # -> 1 & /@ 
        Flatten[Position[emptiness4Cycles, #] & /@ cycles]]
      ] /@ form4Cycles}]]

CoverGraph[coverMatrix_] := ResourceFunction["NestWhileGraph"][
  Function[{state}, 
   Select[state + # & /@ coverMatrix, ! MemberQ[#, 2] &]],
  {ConstantArray[0, Last[Dimensions[coverMatrix]]]}, UnsameQ @@ # &,  2]

Using FindIsomorphicSubgraph (new in V.13 and bug-fixed in V.13.1), and a new WFR from the games post, NestWhileGraph, we can quickly dispatch the test case, and finally solve the difficult problem from 10 years ago. First a cover matrix is constructed, then NestWhileGraph comprehensively sums rows to find non-overlapping placements:

CoverGraph[PolyominoCoverMatrix[{form},emptiness]]

And indeed if we look closely at the 12 vertices with graph distance 2 from the origin, undoubtedly we would again find the 12 relatively obvious solutions listed above. We can ramp up to a 6x6 grid and still find, fairly instantaneously, the following graph:

CoverGraph[PolyominoCoverMatrix[{form},
  PolyominoGraph[ArrayMesh[ConstantArray[1, {6, 6}]]]]]

And counting vertices by numbers of tiles placed, we find 40 configurations with 3 tiles on a 6x6 grid:

Histogram[ Total /@ VertexList[gTest][[All, 1 ;; First[Dimensions[mTest]]]]]

Now when we go to the 7x7 case, the computation takes more noticeable time, and the graph turns out to be very large, too large in fact, to show up nicely as a plot:

AbsoluteTiming[ gPoly = CoverGraph[PolyominoCoverMatrix[{form},
    PolyominoGraph[ArrayMesh[ConstantArray[1, {7, 7}]]]]]]

With a little more analysis, we can immediately solve the counting problem, first sorting the graph vertices by number of tiles, and next by genus:

ord = Plus[Divide[Mean[#], 2], 1/2] & /@ Map[Sort,
     FindCycle[emptiness, {4}, All], 2] /. UndirectedEdge -> Plus;

leveldVertices = Function[{count},
    Select[VertexList[gPoly2],
     Total[#[[1 ;; First[Dimensions[mSolve]]]]] == count &]
    ] /@ Range[0, 4];

leveledMatrices = Map[
   ReplacePart[ConstantArray[0, {7, 7}],
     MapThread[If[#2 == 1, #1 -> 1, #1 -> 0] &,
      {ord, #[[First[Dimensions[mSolve]] + 1 ;; -1]]}]] &,
   leveldVertices, {2}];

Genus[mat_] := Length[Select[WeaklyConnectedComponents[
    NearestNeighborGraph[Position[mat, 0], {All, 1}]],
   ! MemberQ[Flatten[#], 1 | 7] &]]

data = KeySort[CountsBy[#, Genus]] & /@ leveledMatrices

Out[]=<|0 -> 1|>, <|0 -> 160|>, <|0 -> 2628, 1 -> 828, 
 2 -> 232|>, <|0 -> 3384, 1 -> 4640, 2 -> 3072, 3 -> 1008, 
 4 -> 240|>, <|0 -> 96, 1 -> 322, 2 -> 560, 3 -> 632, 4 -> 392, 
 5 -> 142, 6 -> 40, 7 -> 4|>

BarChart[Values /@ data, ChartLayout -> "Stacked"]

It looks like there are 96 placements of 4 tiles on 7x7 grid with genus 0. Now let's plot some of these arrangements to see what they look like, and the four genus 7 cases might also be interesting. First we need to transform the data a bit, and a depict function:

tileVals = MapThread[If[#2 == 1, #1 -> x, #1 -> 0] &, {ord, #}] & /@ 
   mSolve[[All, First[Dimensions[mSolve]] + 1 ;; -1]];

coloredCovers = Total[
     Map[ReplacePart[ConstantArray[0, {7, 7}], #] &, 
      MapIndexed[# /. x -> #2[[1]] &, 
       tileVals[[Position[#, 1][[All, 1]]]]]]] & /@ 
   Select[VertexList[gPoly2], 
     Total[#[[1 ;; First[Dimensions[mSolve]]]] ] == 4 &][[All, 
     1 ;; First[Dimensions[mSolve]]]];

CoverPlot[cover_] := ArrayPlot[cover,
  ColorRules -> 
   Append[MapIndexed[#2[[1]] -> #1 &, {Blend[{Yellow, Orange}],
      Blend[{Green, Cyan}, .5], Lighter[Blue, .5],
      Lighter[Blend[{Magenta, Red}, .25], 0.4]}], 0 -> Darker@Gray],
  Frame -> None, Mesh -> True, MeshStyle -> Black]

A random sample, labeled by genus:

Grid[{Labeled[Show[CoverPlot@#, ImageSize -> 80], 
     Text@Style[Genus[#], Gray]] & /@ 
   RandomChoice[coloredCovers, 6]},
 Spacings -> {1, 1}]

The 96 results for genus 0:

Grid[Partition[Labeled[Show[CoverPlot@#, ImageSize -> 80],
     Text@Style[Genus[#], Gray]] & /@ 
   Select[coloredCovers, Genus[#] == 0 &], 6],
 Spacings -> {1, 1}]

And four more results for genus 7:

Grid[{Labeled[Show[CoverPlot@#, ImageSize -> 80],
     Text@Style[Genus[#], Gray]] & /@ 
   Select[coloredCovers, Genus[#] == 7 &]},
 Spacings -> {1, 1}]

And please notice obvious dihedral symmetry in this set of results!

As a double check, I can run a completely different algorithm based on MultiwayDeletionsGraph for which the input is not a cover matrix, rather is a cover graph derived from the cover matrix:

PairwiseOverlapGraph[coverMatrix_] := 
 With[{len = Length@coverMatrix},
  Graph[Range[len], Flatten[If[
       ! MemberQ[Total[coverMatrix[[#]]], 2],
       UndirectedEdge @@ #, {}] & /@ Subsets[Range[len], {2}]]]]

PairwiseOverlapGraph[PolyominoCoverMatrix[{form},
 PolyominoGraph[ArrayMesh[ConstantArray[1, {7, 7}]]]]]

The augmented MultiwayDeletionsGraph with method "ExactCover" then crawls this graph and can produce an isomorphic solution graph output, but in less than 2 seconds! A factor of 10 faster! However, this is not really scientific reproducibility because in both cases the machine operator is the same person, namely, me. If another scientist wants to verify or dispute the solution above, please add a comment to this thread! Also, if anyone can beat the 2s time, please say how and how fast, thanks.

The last thing I would like to mention is that Knuth's DLX algorithm can probably outperform MultiwayDeletionsGraph by an order of magnitude. What I really hope to do (instead of just copying someone else's implementation) is formulate a graph input similar to what is directly above, that can then be fed into a new method for MultiwayDeletionsGraph. I think this is possible, but I haven't had the time to work out all the details just yet. Anyone?