Talk:Minesweeper game
Too long?
It took several hours to write the task description and to code this tasks initial Python solution. I will probably set the sample output to scroll when the page gets too long, but other language examples may well have to be sub-pages.
I freely admit that the task was chosen with an eye to attracting those new to programming :-)
--Paddy3118 10:58, 10 July 2010 (UTC)
Differences in behavior from classic game
The clearing criteria seems wrong or ill-defined. In the classic game if you clear a square that has one or more adjacent mines no further clearing happens. If the square has zero adjacent mines a clearing is opened to an edge of non-zero numbers. (The small size of the board and mine probability makes it hard to properly demonstrate the clearing criteria) --Dgamey 09:55, 11 July 2010 (UTC)
- I must say that I just made up what I thought was the clearing algorithm on games I had played some time ago, and I was probably unconsciously trying to minimise complexity in an already large task. Could we go with this simpler clearing strategy, at risk of impairing the playability of the game? --Paddy3118 11:01, 11 July 2010 (UTC)
- The classic clearing criterion is to only auto-reveal cells if they have no mines in the neighbors at all. It's pretty trivial to do this given that you need to calculate that figure anyway for display on the cell, and you can just call the clearing function (safely) recursively. (It gets slightly tricker with a very large grid since it's possible to get into problems with recursion depth, if that's something your language implementation imposes a cap on, but that's a refinement really.) –Donal Fellows 11:37, 11 July 2010 (UTC)
- Why must it be recursive clearing? Not all languages support recursion. Even for the large grid in a classic game 16 x 30 it wouldn't too bad. --Dgamey 13:27, 11 July 2010 (UTC)
- Doesn't have to be, but it is easy for (almost) everyone to implement. –Donal Fellows 14:10, 11 July 2010 (UTC)
- There's also the loop/recursion transform. --Michael Mol 15:50, 11 July 2010 (UTC)
- Doesn't have to be, but it is easy for (almost) everyone to implement. –Donal Fellows 14:10, 11 July 2010 (UTC)
- I'd suggest making the "resursive clearing" feature optional. That enables the bulk of the task, and lets anyone sufficiently clever come along and handle the part that may be more difficult for some languages. --Michael Mol 15:50, 11 July 2010 (UTC)
- Why must it be recursive clearing? Not all languages support recursion. Even for the large grid in a classic game 16 x 30 it wouldn't too bad. --Dgamey 13:27, 11 July 2010 (UTC)
- Oh! I thought that we were just discussing what the clearing is rather than whether it should be left out? don't think it would be much of a game without a clearing feature of some sort. --Paddy3118 16:50, 11 July 2010 (UTC)
- I've played implementations that didn't recursively clear, but it sounded to me like Dgamey was concerned about the task definition either being unclear, incorrect and/or limiting the use of languages which can solve the task in "spirit" (i.e. allow one to play a game recognizably like Minesweeper), but not easily solve it in its entierity. I was pondering a compromise, but I may have misinterpreted the conversation. --Michael Mol 22:40, 11 July 2010 (UTC)
- I was referring to the HOW the clearing was done (i.e. recursion/iteration) rather than IF. Yes it should be a requirement. Just not how. --Dgamey 03:01, 12 July 2010 (UTC)
- Oh! I thought that we were just discussing what the clearing is rather than whether it should be left out? don't think it would be much of a game without a clearing feature of some sort. --Paddy3118 16:50, 11 July 2010 (UTC)
- The grid size and mine density chosen in the task (i.e. 6x4 and from 4 to 12 mines) won't show off the recursive clearing well. There won't be many squares with 0 adjacent bombs which is what is needed for that clearing is supposed to kick in. The classic game was (a) 9x9 10 mines, (b) 16x16 and 40 mines, and (c) 16x30 and 99 mines. I suggest making the values of the starting parameters a suggestion. --Dgamey 03:01, 12 July 2010 (UTC)
- I agree that the grid size is too small to really bring out the clearing routine, but I thought that this would have a major affect on the size of entries. Sample output would be large no matter how short the actual implementation. I like the idea of changing the explanation of clearing to a suggestion though. --Paddy3118 04:41, 12 July 2010 (UTC)
- The grid size and mine density chosen in the task (i.e. 6x4 and from 4 to 12 mines) won't show off the recursive clearing well. There won't be many squares with 0 adjacent bombs which is what is needed for that clearing is supposed to kick in. The classic game was (a) 9x9 10 mines, (b) 16x16 and 40 mines, and (c) 16x30 and 99 mines. I suggest making the values of the starting parameters a suggestion. --Dgamey 03:01, 12 July 2010 (UTC)
FWIW, the real difference between this task and the classic game is that in the classic implementation, the first square you clear is never a mine; if there is a mine there, the game moves it away. In fact, there was (is?) a cheat which lets you find out where the mines are, and you can use that to confirm it yourself. (Alas, I don't remember the details of the cheat; it was a long time ago.) The moving of a mine only ever worked for the first square you cleared though. I don't suggest that anyone implements it, but it's one of the marks of the real original; it had a lot more thought applied to it than it appeared to have at the time. –Donal Fellows 23:31, 11 July 2010 (UTC)
- Interesting feature. I believe the cheat was taken away before XP. --Dgamey 03:01, 12 July 2010 (UTC)