Hacker News new | ask | show | jobs
by nallerooth 2071 days ago
First cell I clicked on was a mine. So far it behaves exactly as the original. ;-)
1 comments

AFAIK the original ensures that the first cell clicked is not a mine.
Only on Ubuntu, in which the first click must be "0". On Windows it could for example be "2" and then you have to guess which of the adjacent 8 cells are the 2 mines...
That's not what's being discussed here; the above comments talk about whether it's guaranteed that the first click is not a mine, not that it's not adjacent to a mine. As far as I'm aware, just about every version guarantees that the first click is not a mine, but many (such as the Windows original) allow the first click to be adjacent to a mine.
What's really being discussed is whether the game works well though/you'd want to play it

Whether you lose on move 1 or move 2 due to bad luck is not a big difference

There is some luck involved in minesweeper anyway.
There are some variants without luck. For example there was one which guaranteed that you never get a mine when you have to guess, but always get one when you guess in a situation where you can still open another field safely.
This is true, I've played and won many minesweeper games and always wondered how this was done.
You generate the game map once it's known where the player clicked. During generation you take into account that the first clicked cell has to be mine-free. In general, when distributing mines, the algorithm has to take into account already that there must be N mines in the field, so avoid instances where it assigns two mines to the same field twice. You treat the starting field as just another "mine" whose position is hardcoded.

A simple algorithm would be to re-do the map generation until there is no mine collision, but with larger numbers of mines, the collision chance increases, so your runtime will go up superlinearly. A simple but very effective improvement is to keep the positions of the mines up until the collision and then only change the seed for subsequent mines. Then your algorithm should in fact scale much better. You can also use different methods, like assigning indices in a certain way so that invalid states are avoided completely. A bit more complicated but way "cleaner".

There is an even simpler approach: for maps with K total cells there would be always K-1 unclicked cells and a single clicked cell after the first click, so you can generate K-1 cells and insert a "gap" corresponding to the first clicked cell. This works because every unclicked cell has an equal probability to become a mine.
Even simpler still is to just move any mine clicked on in the first move into an empty square before processing the clicked square as normal.
This is what actually happens in the Windows original (it doesn't look for a random empty square, it tries them in reading order starting from the top left).
That needs a list of empty cells, otherwise you need to retry and get the same issue as the map-wide regeneration.