_fp5w

Aye skipper, that's a good idea.

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.

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 );
    }

Yeah, totally get your point. Generating one is inexpensive, maybe 1 ms to get it cranking. It's entirely possible that looping through untampered RNG combinations until a hole opens is more efficient than scrolling the field around.

The algorithm to locate the biggest hole on a 1,200 tile board takes around 45ms and I'm stubbornly itching to use it one way or another. But I'll see what's a more sane solution over shifting fields.

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.

Middle-click is the devil's button.

* Attempts to hide the 'middle click & drag' line.

Obviously you're referring to the rectilinear mechanics. But, would middle click work on a hex grid?

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.

Thanks, I'll put this as an option when creating a new game. As for myself, I definitely like the feel of nailing a larger crystal of empty space and get that Pavlovian sound.

What's funny is that most of the server code is already in place in dev, it's just disabled. I just need to carve some time to pick a direction and work on it. When a board is generated, there's already an algorithm that locates the center of the biggest empty space on a board, and if it exists, it assigns its address to game.clearest_tile.

    // first click, surprise!
    if( game.click_count === 1 && game.clearest_tile !== false ) {
        // sigh, this is too inelegant
        // game.board.private[payload.parameters.address].mine = false;

        // sigh, and this looks like garbage when shifted
        // this is what i get for picking a hexagonal board
        // game.shift_mines_to_center(payload.parameters.address);

        // todo: fixplz
    }

Obviously I can just clear that tile on that first click and be done with it. Or, highlight the emptiest tile on game board render. But the shift_mines_to_center algorithm is something that needs tweaking.

Gotcha. Thanks for taking the time to explain. I'll add some hotkeys (+/-) to initiate a zoom, but otherwise this is a result of my pure laziness.

Not that you can zoom like this now, but you can pan if you hold the ctrl key down and left - click + drag.

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.

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.

Oh, I think I get you. You mean the static HUD isn't doing anything for you zooming in the board. That's an oversight on my part, thanks for the report.

Edit: also, you should be able to zoom in on the tiles, but, you're possibly running into an untested edge case, of which there are tons. Mac and mobile is under-developed as I'm a firefox/desktop curmudgeon. As you and others have noted, there is some interface goofery, but otherwise a mousewheel should let you zoom in until you see a moire pattern on a crt.

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.

Edit 2: Ach, I meant 503 error!

* turns in web badge and protractor

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.

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.

Thanks, adding to fix list! Though I gave it rudimentary testing and a grumbling Safari EventTarget shim, I didn't chain myself to a mac and play for any extended period. Being an old desktop machine/FF fart, I'm kind of eyeballing mailing mice to people instead of tackling this. Much appreciated!

Also, oops, missed this part. There is zoom.

Unfortunately it requires mousewheel or some magic combination of your trackpad and pinch which, I just hate mobile and macs apparently. Key Z is to zoom-all.

Thanks! I actually did it that way on purpose. Reason being is that in multiplayer, you get points clicking around the blurry shape. So, competitive function with multiple players, and there's a risk of misclicking in the rush and nailing a mine.

I do however have an update coming up (sigh after this ... month ... eventually) which will address what you just said, and also try to make sure your first click always hits a hole. But not sure how it'll turn out just yet. I'm a romantic when it comes to random number generators so I didn't want to mess with a pre-generated board just to create a hole. Plan is to shift the entire board by X,Y tiles from where you click, and as you can imagine geometry of irregular shapes is a bit tricky.