I've never played the original (that's the game that originally inspired the concept of Minesweeper, right?) so I don't how it compares. But either way I really like this, especially on the hard difficult: I can usually figure out most of a guaranteed safe path by "feeling around" where the mines are but in hard mode I always have to take a few calculated risks and really factor in the shield as well.
My high score so far is 685. I wonder if that is any good😅
I’m not sure if Minesweeper was inspired by this but there’s definite similarities
I’ll be honest, I didn’t/couldn’t work out how to program in a check to make sure that it’s always possible to get through the minefield! But in my playthroughs it’s pretty much always been possible haha
Well, you’ve beat my high score on hard of 629 so well done there!
Haha, I have never encountered a case where the other side was not accessible either, so I think that's pretty unlikely to happen given the number of mines and size of the playfield. If you'd really like to prevent this you could solve this via a graph search algorithm. Easiest way to do that besides implementing the search yourself is to take some existing pathfinding implementation (super common in game development for enemy AI etc., so there's probably one for Pulp out there) and make it check if there's a path from entry to exit, where mines are impassible obstacles. If the algorithm can't find any path, then simply regenerate the mines and check again.
When I did briefly think about it, I thought it sounded tricky to check every possible path from say, bottom left upwards, then move one along and repeat it - 1) I had no idea how to code that and 2) I thought it sounded quite intensive for the Playdate, though there's not that many squares so I guess it would be fine.
Thanks for the link, that's going to be an interesting read.
Come to think of it, the Wikipedia page I linked to is a bit dry and used a lot of computer science and graph theory jargon. The concepts behind it are not very difficult at all though: they boil down to traversing your grid in a particular way while keeping track of which spaces you've already visited. I would instead recommend to Google for "game pathfinding" or "depth-first search" and look for a more straightforward explanation.
Besides graph search there are also "shortest path" algorithms (like Dijkstra's or A*) that give you the shorter path from A to B that doesn't go through obstacles. You don't really need those because you just want to check if the path exists at all. But if you happen to find a library that does shortest path that will also work, because those algorithms will return an error or report that the "shortest path is infinity long" if no path can be found at all.
All these algorithms are actually very efficient (execution time "scales linearly" depending on the size of your grid). I recently implemented one in Commodore 64 Basic and that worked fine, so for the Playdate it should definitely not be a problem!
← Return to game
Comments
Log in with itch.io to leave a comment.
I've never played the original (that's the game that originally inspired the concept of Minesweeper, right?) so I don't how it compares. But either way I really like this, especially on the hard difficult: I can usually figure out most of a guaranteed safe path by "feeling around" where the mines are but in hard mode I always have to take a few calculated risks and really factor in the shield as well.
My high score so far is 685. I wonder if that is any good😅
Thanks vert much for the kind words :D
I’m not sure if Minesweeper was inspired by this but there’s definite similarities
I’ll be honest, I didn’t/couldn’t work out how to program in a check to make sure that it’s always possible to get through the minefield! But in my playthroughs it’s pretty much always been possible haha
Well, you’ve beat my high score on hard of 629 so well done there!
Haha, I have never encountered a case where the other side was not accessible either, so I think that's pretty unlikely to happen given the number of mines and size of the playfield. If you'd really like to prevent this you could solve this via a graph search algorithm. Easiest way to do that besides implementing the search yourself is to take some existing pathfinding implementation (super common in game development for enemy AI etc., so there's probably one for Pulp out there) and make it check if there's a path from entry to exit, where mines are impassible obstacles. If the algorithm can't find any path, then simply regenerate the mines and check again.
When I did briefly think about it, I thought it sounded tricky to check every possible path from say, bottom left upwards, then move one along and repeat it - 1) I had no idea how to code that and 2) I thought it sounded quite intensive for the Playdate, though there's not that many squares so I guess it would be fine.
Thanks for the link, that's going to be an interesting read.
Come to think of it, the Wikipedia page I linked to is a bit dry and used a lot of computer science and graph theory jargon. The concepts behind it are not very difficult at all though: they boil down to traversing your grid in a particular way while keeping track of which spaces you've already visited. I would instead recommend to Google for "game pathfinding" or "depth-first search" and look for a more straightforward explanation.
Besides graph search there are also "shortest path" algorithms (like Dijkstra's or A*) that give you the shorter path from A to B that doesn't go through obstacles. You don't really need those because you just want to check if the path exists at all. But if you happen to find a library that does shortest path that will also work, because those algorithms will return an error or report that the "shortest path is infinity long" if no path can be found at all.
All these algorithms are actually very efficient (execution time "scales linearly" depending on the size of your grid). I recently implemented one in Commodore 64 Basic and that worked fine, so for the Playdate it should definitely not be a problem!