Release

Minesweeper

10

nathanielbabiak 2022-06-13 05:39 (Edited)

Please let me know if you find any bugs!

Credit to Timo for the Touch Zones GUI Library.

minesweeper.nx | Open in app
2022-06-24 02:04
minesweeper.nx | Open in app
2022-06-21 23:55
minesweeper.nx | Open in app
2022-06-13 05:39

TrashCan Games 2022-06-13 08:09

I love mine sweeper and this is really well made.


nathanielbabiak 2022-06-13 12:01 (Edited)

Thanks! I actually wrote it intending to use it in a tutorial. (Hopefully the major program flow and graphics code is super clear.) Tutorial's going to take a while though, since I realized I don't have a good understanding of touchscreen stuff - that part is kinda hacked together...


was8bit 2022-06-13 13:34

Very nice :)

For cellphones, the tiles will need to be 2x2 in size for touch purposes... as is it will prove difficult...

It would be easy enough to add, just change the bottom layer to CELL 1,1 and keep the top layer for the 1x1 stuff... code would need tweaked just a little to accomodate both options...


nathanielbabiak 2022-06-13 18:09 (Edited)

I addressed the touch difficulty of tiny cellphone screens a bit differently, it plays just fine for me by following these steps:

  1. Start the game (since the HTML renderer jumps around when you start)
  2. Make the LowRes NX console window mostly fill the whole touchscreen (to do so, use portrait/landscape and pinch-to-zoom)
  3. Note how much of the grid gets cropped on your phone.
  4. Tap Menu then set the width and height to suit your phone's cropping.
  5. Play!

On my Samsung Galaxy S9, I use 10x15 for portrait mode, and 20x8 for landscape mode.

(In landscape mode, I can't see the timer, and in both modes, I can't see the mine count. For some reason the HTML renderer just shows the game really large, and I can't zoom out. This is still preferable to using 2x2 size cells, since that would limit the mine grid size to only 10x7, which is too small.)


was8bit 2022-06-14 04:49

Most of my own tests and those of people i know have issues... but you are correct that the playing field would be too small with 2x2...


nathanielbabiak 2022-06-14 05:43 (Edited)

I have this on my screen - are you zooming in?

portrait

landscape

portrait 1.34 zoom

Alternatively, I might make it an exercise in the tutorial to change the size...


was8bit 2022-06-14 07:06 (Edited)

@tutorial... Ooo... there you go :)


was8bit 2022-06-14 07:08

Clever design to get the grid to fit the phone :)


SP4CEBAR 2022-06-20 10:35

This isn't just a game that looks or works like minesweeper, This IS Minesweeper!! I just cleared the minefield, and I loved it!


SP4CEBAR 2022-06-20 10:41 (Edited)

I once made minesweeper on a TI-84 graphical calculator, it thought me why I should be careful with GOTO to avoid memory leaks Also, what flood-fill algorithm did you use?

To make the minefield even bigger you could add 2D scrolling and BG data refreshing, my GUI library has a sub program for scrolling with rubber banding at the ends (was tricky to make, but it works) and with BG data refreshing in chunks, if you need inspiration you could look at that


nathanielbabiak 2022-06-21 03:42 (Edited)

Thanks! Your GUI library is really pretty, but ultimately minesweeper (not this version, the code's still sketchy) will be an example in a tutorial, so I'm going to limit the scope of the code as much as possible.

To your other points:

I only plan to use GOTO for c-style cycle, cycle(n), and break(n) functions in the final version.

LowRes NX doesn't allow more than 128 recursions. For the flood fill algorithm, I implemented a queue with an additional matrix to track the gray pixels. If the algorithm skips the gray pixel tracking, it hits pixels more than once.

Scroll bars are a cool idea, but the complexity there isn't due to the touchscreen control, it's the adaptive tile refresh, rather than chunk refresh. (This video doesn't mention it in the audio, but the video shows some examples of it.) The second tutorial example I've started is Super Mario, specifically to explain this (among other things). So, it'll be there, just not here.

Honestly it's really a struggle to figure out what gets cut-out and left-in!


SP4CEBAR 2022-06-21 15:41 (Edited)

Thank you, good luck with your tutorials!

I may have used a similar flood fill algorithm, I've used a one-dimensional "to do list" array together with a 2-dimensional minefield array to mark a tile when it is found

I tried adaptive tile refresh here but it would miss 1% of the tiles, I decided to use chunks instead because a chunk is harder to miss, and yet my chunk loader still misses some of them

I like how "among other things" are three hyperlinks


nathanielbabiak 2022-06-21 23:56 (Edited)

Final version is uploaded, all animations are included. The code is refactored. I'm pretty happy with the result, especially:


SP4CEBAR 2022-06-22 15:07

At the start of a game in this minesweeper variant, the first tile is usually not empty
I think many other minesweeper variants generate the minefield right after the user taps the first tile, another way to start with an empty tile is to automatically find an empty tile and open it, right when the game starts (the game picks the first tile)


nathanielbabiak 2022-06-23 00:36 (Edited)

This version does that - it ensures you don't get a mine on your first click. However, it doesn't ensure your first click occurs in a "0" box, only a non-mined box. This behavior matches the original minesweeper.

Maybe you're accustomed to the late-90's version? It used 10 mines on a 9x9 grid, rather than an 8x8. It has a higher chance of the first click being a "0".

To approximate the late-90's version here, use 10 mines and a 10x8 grid, you'll hit more "0" boxes on your first click. :-)


nathanielbabiak 2022-06-23 02:34 (Edited)

My last post is wrong, if this (insanely detailed) account of Minesweeper history is correct.

Apparently, the original and "official" minesweeper guarantee the first click won't contain a mine, but from 2007 onwards, with the Vista version, Microsoft has attempted to popularize a few changes from those earlier versions, and those changes cause the "minesweeper community" (???) to not recognize the later versions as "official" games.

Those changes include the thing you referenced - first clicks would land on a "0" box, rather than merely guaranteeing it's not a mine.

...it seems I have an exercise for the tutorial...

:-)


SP4CEBAR 2022-06-23 12:14

Good luck!
The only official Minesweeper version I've played is the one on windows 7, so I'm used to the Microsoft versions


nathanielbabiak 2022-06-24 02:09

SP4CEBAR, you're right, it plays so much better with a "0" first-click! The queue scripting language made it super easy to implement this - honestly it took me all of 10 minutes.

This version also fixes a bug with the menu and reset buttons. Previously, dragging inside the menu or face caused the button to be shown "stuck". Currently, this behavior is treated as a drag outside the button. (It'd be too nuanced for a tutorial to implement a separate button handler for those two multi-cell buttons, so I'm fine with the current implementation.)


SP4CEBAR 2022-06-24 12:10 (Edited)

that's nice!

My previous GUIs check for each GUI element (button, slider, etc.) if touch coordinates are within its boundaries, and it memorizes which element was tapped (TAP). This element is the active element until TOUCH is false. whenever you tap a button, you can drag out of it, and drag back into it and still activate the button. I just noted that my buttons work on touch, I think it's better If they work on release.

I'm currently working on a complicated file-based GUI system, which uses a map of bytes to translate the coordinates of the touched cell (touch.x\8, touch.y\8) to a byte value which is the GUI ID. when tapped (TAP) this ID is stored as the active GUI element. This way it can immediately call the right GUI element and it doesn't need to check each element. The GUI file has a tree data structure (which was pretty hard to make) so that it can store parameters as well. I want to make a GUI editor for this file-based GUI system


nathanielbabiak 2022-06-24 14:33 (Edited)

You should check out Timo's upload Touch Zones GUI Library.

It's the official one for LowRes, and does 'work on release' among other things. It was pretty tough to learn, so I put a comment at the bottom of that upload with some graphic plots showing its output.


nathanielbabiak 2022-06-24 14:37

Agreed on the comment "pretty hard to make"! Jump tables are really tough in a language without pointers!


SP4CEBAR 2022-06-24 16:08 (Edited)

Modifying the buttons to work on release wouldn't be too hard, but I'll check out the library


SP4CEBAR 2022-06-24 16:19 (Edited)

When making a tree-structure, I tried to store addresses in RAM to make it easy to read, but that came with one challenge: whenever an item is added, I use COPY to shift all the data that comes after it, this makes a gap where I can safely write the item, but then most of the addresses are outdated, and most of them need to be updated, and it's kind of hard to know which addresses

So it now stores file sizes instead of addresses this also gives it a smaller file size, but it does mean that the program needs to index the file first (and again after each added item) (or it has to keep searching through it whenever it wants to access it), but it seems to work well


nathanielbabiak 2022-06-24 17:06 (Edited)

Try a linked list instead? Stepping through all the GUI elements one-at-a-time isn't going to cause a performance hit, so you don't really need an index. (Unless you meant index as in tracking metadata, rather than a lookup to ensure O(1) speed, in which case I misunderstood.)


SP4CEBAR 2022-06-25 11:41

With index I mean an absolute or relative memory address that links to another place in memory


Log in to reply.