Skip to content

Comment on Solving Minesweeper and making it better (2015)parent

Comments

The flip side of that is if you're playing a large board quickly and the need to guess only emerges towards the end of a good run, sometimes you might want that last "help" button to save the last mine being a 50/50 shot

The final version of the game with the automation turned off actually plays identically bar that option.

When the mental pattern matching includes quick identification of known unknowables you can often identify some of the 50/50s of a given board quite early in the game. There is no point in postponing those decisions. Failing fast gives you more boards per minute.

On this level the game becomes 95% dexterity and 4% the "metagame" OP was talking about, which is triaging probable unknowables between guessing early and hoping for more information. The tiny rest is occasionally waking up from pattern matching autopilot mode to apply some logic to very rare patterns.

The metagame is theoretically more interesting than that. Is it more efficient to initiate the game with one random guess (as people usually do), or is it more efficient to initiate the game by rapidly clicking N random squares and accepting the danger? If so, which N is optimal? :)

Hmm... I'm tempted to say you should be looking at the number of squares uncovered, M.

If you got a good first click, you wouldn't want to waste it on unnecessary risk. If you got a bad first click, you'd want to keep guessing until you either died or uncovered another large section.

IIRC my N settled at around N=2.7, which means that a lucky first click would abort the queued random clicks between clicks two and three.

After that, the most important decisions for a fast match were deciding which mines not to tag because the final auto-tag would get them anyway and which empty fields not to uncover because they would be uncovered faster with an "uncover all surrounding" click on a saturated number. Clicking was definitely the bottleneck for me, so the main goal of the eye/pattern match was to keep the click-queue filled at all times. The eyes would always focus somewhere close but not too close to where the clicking happened, so that the pattern match could work on a stable image. Or sometimes just rest for a few clicks, when the hand could not keep up.

Fond memories of stupid things.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.