Midway through this project, I ran into that pure HTML one here and chuckled that someone else was making their variant as well. It really cracked me up! Then there was another, and then I ran into another (yesterday's), so I went ahead and shared mine.
Obviously programmers like to reconstruct things as a hobby, make their own implementations, clones. Just surprising how many of us picked minesweeper. For me it was probably the fact that it didn't come with Windows 10, maybe, when I was jonesing to play it. Also I wanted to see if hexagons would work, without knowing about or seeing similar variants.
I'm glad I did this because it gave me first-hand working experience in a few theoretical things I knew would work but I didn't know what their quirks were, like setting up websockets/socket.io to work with SSL, using multiple rotating apache backends with a graceful restart to perform upgrades without downtimes, responsive and fast SVG rendering techniques.
That's utterly awesome and I hope the links didn't come across as "this has already been done"—quite the contrary—the intention is just "here are cool similar things if anyone's curious". A hexagonal version is a noble and clever addition!
Hm. I'll make the end condition configurable so you can pick that as an option. Right now I'm stuck at a second refactoring but the idea is to give the player flexibility on structuring the game when they start it. Right now the end-game routine is a very dumb implementation.
// meaning all tiles are touched or marked
// and guesses are correct
is_board_solved() {
for( var k in this.board.public ) {
// takes a single unguessed, unrevealed tile
if(
this.board.public[k].state === "unknown" &&
this.board.public[k].guess === false
) {
return( false );
}
// or one wrong mine guess
if(
this.board.public[k].guess === true &&
this.board.private[k].mine === false
) {
return( false );
}
}
return( true );
}
Yep :( Instead of firing up tethered Chrome in debug mode, grabbing a 7' St. Croix and going to a pier before sun sets ;) Time better spent, perhaps.
My hunch is it has to do with an implementation of EventTarget, the apparent source of all my Browser/JS problems this month. It did work on mobile prior to me refactoring things to the native event system, but, not since. My best suspect. I'll give it a look for an upcoming update, thanks for reminding me.
Though, honestly when it did work, the performance was ... garbage. I don't have too old of an Android phone or tablet, but it was still a performance struggle on both at simplest of settings and configurations. HTML5 + SVG + DND / touch libs simply weren't stellar for this sort of thing.
On this topic, a feature request: could you designate a letter key to perform the same function as a right click? Right click is difficult on my new laptop's touchpad...
Ha, thanks for the feedback. I'll address all the things I can from your list. Of the visual artefacts, only the last one makes sense to me, a lost mouseout event overtaken by events (yes, I was lazy.) Think it's possible the first two weirdnesses have to do with browser / video driver render optimizations? If you give me your OS / browser / ver / possibly graphics card, I could see if I can replicate it or do something about it.
The first two kind of look like a glitch introduced by a boundary of a blur filter. The individual tiles, when blurred, have an SVG filter (feGaussianBlur stdDeviation="3,3" or "7,5") applied to them. As a performance optimization, think this SVG library (Snap, successor to RaphaelJS) sets that filter to just barely fit over the element in question.
But if the elements move or if the viewport is manipulated to accommodate pan and zoom, these filters visually glitch. You start seeing parts of the blur kind of weirdly clipped off in middle of nowhere. To counter this visual glitch, I overrode the sizes of these filters to an absurd amount, going from -10000,-10000 to 10000,10000, and that fixed the initial rendering problem. But what you're showing kind of looks like a browser or library isn't honoring the set size of the blur filters and render updates from a mouse over/out are triggering a bad restoration of appearance.
As to the wonky grid, think it might be partly due to scaling and integer precision of the hexagon positioning and how various transforms are applied. The positions of tiles are transforms, ints with no decimal precision, but the transformation matrix for the zoom function is very floaty. How a browser handles that intersection of numbers and precisions is magic. At some zoom levels or window proportions (when i fiddle with it), the spacing gets truncated this way and that and some of them look like they round up or down. Maybe I'll offset those pixels by 0.5 and see if there's improvement.
Hey, thanks for the bug report and taking the time to SS this and track me down here. I'll trace it in memory logs to be sure, but, I think it's on a fence between a bug and a not-bug. Time to torque all the bolt heads for sure.
The recursive clearing routine honors your bad guesses and does not attempt to correct you. Confusing part is that the interface doesn't explain this when it proc's and a detonation occurs. But the maybe-new bug part here you found is likely that an edge detonation shouldn't trigger a clearing routine but I think it did in this case for some reason.
Part of this sort of thing tends to normally happen if you either accidentally do a near-simultaneous right-click and left-click on some sensitive mice, or TCP network latency causes commands to get transmitted in a fast burst. In that latter case, I don't think order of the clicking messages is messed up by network conditions, but, ... I'll double check that to be sure and keep an eye on it, so again, thanks for taking the time to report this.
My alpha tester has finished most of the large maps without hitting a single mine, after many grueling attempts. She started with the flower one and blew out her boyfriend's eardrum screaming about it when she won. We heard the scream bleed through on discord and then there was a man down in Overwatch.
Right now all the shaped maps are manually rasterized. I'm halfway to switching that process to a dynamic on-the-fly one since to my surprise and delight it turns out it's not computationally intensive. But all other than beginner/inter/expert are lazily set at that expert density, vaguely derived from the classic minesweeper's field percentages (20.625%).
The next update will let you select more granular game options, like exact difficulty per map, map tile size (dynamic rescaler), etc. Options right now are to play with multiple players, so you then have 3x lives per player, or of course cheat and invite yourself to the game in a different tab and finish the map ;)
Yep, that issue is a battle I've lost in the court of public opinion here, so mea culpa. Thanks- I'll see about improving it.
Though, in my defense this little clone is already very unlike like minesweeper in so many ways, starting with the geometry - less sides to touch a mine (6 instead of 8). Trade-off is that the number you see is more certain about its neighbors, so the quirk of the first strike grew on me.
Residing in the country with the "longest, continuous minefield in the world"[1], I very much appreciate the harsh reality of "your first click could be your last".
Thanks. If the node.js program crashes, you'll see Italy rendered as the 403 error message.
Edit: after yelling at the engine room and upping MaxRequestWorkers, you can see the 403 error page at this lazy URL: https://www.multisweeper.com/apology.html - it was generated by my first rasterizer prototype.
Ouch, bad luck! Incidentally, that's why the 'instant restart' option got put in. Had my alpha tester growl at me over it.
Thanks, that's already in the works and I'll put in an option for a safe first click. Wrote more about this to another person here, but suffice it to say I'm trying to shift the entire board's biggest randomly generated hole to your first click instead of (re)generating the board with an artificial hole. Because I don't want to tamper with RNG, and I'm a fool. This is the harder overcomplicated way of doing it, so it's taking some time, but it'll be in the next update.
Hmm. Good thinking. But in case your first click lands in a dense field, that method won't cut a notch in the fabric for you to chisel at. Like a dummy, I'm taking the waiter-pulling-tablecloth-off approach here, but lets see if I get stuck on it.
If you read up on classic Minesweeper, that's what they do, is if your first click is a mine it relocates it to the first open spot off the top left corner.
It's also why you shouldn't click in the top left corner in the game if you're hoping for a good cascade, because you're less likely to get one.
Thanks, the beginner/intermediate/expert levels are the only ones that give a different difficulty. All the other maps are expert - hardcoded at about the % age of a classic minesweeper mine density. Trade off is you get three lives, though most people (sigh, like me) just reset when they hit their first daisy.
Plan is to rebuild the menu hexagon with these options so you can set it however you like, but this is a side hobby so won't be until next month that I'll get to it. If you spy on what's sent via socket.io, you can override the density parameter in console and request new games ;)
My favorite part of the game doesn't exist anymore, was actually the death screen animations but somewhere between code updates I tabled it and never reinstated it. Random tiles would minimize into the distance and then rotate every few seconds and everything would blur out except the correct numbers, spitting in your face sort of. Was eerie.
Removed it and other animations when render and animation speed became an issue and I focused on optimizing render speeds. Then I never got around to putting them back in. Like, a webgl version of this could probably have a hundred times more hexagons and you wouldn't lose any FPS. But in SVG, it's weird. Biggest surprise, Chrome is finally slow at something - SVG renders - whereas FireFox blazed right through it.
Then a very polite Canadian kid I met on a minecraft server helped me with it, tracing the fundamental issues (thanks, BubbyMK2!). Apparently using rectangles (svg:rect) is particularly slow in SVG, because it forces a redraw outside its clipping boundary. But if you draw a rectangle as a path, no sweat. Or some such.
Obviously programmers like to reconstruct things as a hobby, make their own implementations, clones. Just surprising how many of us picked minesweeper. For me it was probably the fact that it didn't come with Windows 10, maybe, when I was jonesing to play it. Also I wanted to see if hexagons would work, without knowing about or seeing similar variants.
I'm glad I did this because it gave me first-hand working experience in a few theoretical things I knew would work but I didn't know what their quirks were, like setting up websockets/socket.io to work with SSL, using multiple rotating apache backends with a graceful restart to perform upgrades without downtimes, responsive and fast SVG rendering techniques.