eugeneloza/metar-sweeper

Metar Sweeper is a minesweeper game :) Moved to https://gitlab.com/EugeneLoza/Metar-Sweeper

Metar-Sweeper

Metar Sweeper is a minesweeper game :)

metar-sweeper's Issues

Sometimes number of mines is "-1"

Very strange interface bug: when the map is solved the number of mines left becomes -1 and the program doesn't report 'map finished'. Witneced this at least two times, at both there was at least one mine explostion.

Resizable cells

At this point the cellsize is fixed to 20x20 yielding only 70x35 map max. It may be resized easily by variable. I'm not sure we need more for Decoherence. But might be good for a standalone app.

Form resize fails for Linux

Form is not resized for borderstyle=bssingle for linux... I had to manually specify borderstyle=bsnone while changing the form size. This is a bug of GTK2, maybe, connected to beginformupdate/endformupdate sequence.

Show information about map generation parameters

Maybe it's a good idea to add statistics for number of required second-order logic steps & guesssteps with total guess probability for the map.

Weird map types

Should we add a support for non-standart map types? I mean the solution for Decoherence.
The maps may be regular (each tile has equa amount of neighbous) and irregular (The number of neighbours may be different for different tiles).
The simplest regular maps are:
Triangles - 3 neighbours
Rombic or cubic - 4 neighbours.
Hexagonal - 6 neighbours
Octagonal (the present solution) - 8 neighbours.
3D - 6, 10 or 26 neigbours depending on implementation.
P.s. The field will be visually deformed at render in Decoherence, but I speak of the logic.
The present map generation algorithm may work for all these with minor modifications.

Irregular maps are another logic. They are much harder and slower to solve, and require a significant algorithm modification.

Require at least N guesssteps [Decoherence]

For Decoherence we shall need strong metar-locks to demand at least N guessteps for the player. But the present algorithm just requires the number of guessteps be minimal, best if zero.
Solution A: Add mines until required guessworks result is satisfactory. Problem: number of mines is metar lock level.
Solution B: Regenerate the map until guessworks no higher than lock pick chance. Problem: sometimes it is impossible to, e.g. for 10 mines at 10x10 map.
Solution C: (Decoherence-specific) Generate a 100% solvable map for N-M mines and then place M mines untill guessworks resuilt is satisfactory.

Array of TPanel works too slow

Array of Tpanel-child works awfully slow.
Solution A: replace for TImage;
Solution B: optimize the performance;
Solution C: Use 2D Castle Game Engine solution (Preferred due to Decoherence project / would work faster / would give me good 2D engine experience I'll need soon / but bad because it'll require at least libpng.dll in Windows (maybe not bad at all?) and surprises with Linux dependencies)

Optimize the map generation algoritm performance

At this point the algorithm generates 60x30 map awfully slow. Should be optimized. While we are going to use small maps for Decoherence, it is important to have the thing as optimal as possible. Moreover, standalone app is also a good side-result, as the algorithm generates 'almost' solvable maps, which none of other minesweepers does.
Optimizing multipass second-order logic is the way, but it won't make a miracle, just double the speed at max.

One way is not to solve the map for each added mines, but to make a M<N mines map random and randomize it until it's solvable in the given conditions. Then use a strict algorithm to finish the map. M is approximately 0.2(or 0.3)*map area.
Problem: bad for non-guess map generation.
Problem: may be bugged.

Tpanel create fail for large maps

Windows yields an error while trying to handle huge maps, like 200x100. Switching to Timage will do the job.

Mines reset at every mapx, mapy changes

At this time number of mines in the options resets to 40% of map area at every mapx, mapy onchange. Should we avoid this?

Guessworks: too large guessstep issued

At least once I've experienced a 0.5 guesstep, while I demand it to be no less than 0.7. Why???

Difficulty level and presets

Maybe there is a good idea to make user instead of manually inputting of all the parameters in options just to select a pre-determined map type, e.g. 10x10, 40 mines, solvable / 15x15, 50 mines, almost solvable.
Difficulty is usually strongly connected to number of mines divided by map area. E.g. if mines fill 40% of the area this is a rather hard map. And if this number is 10% then it's very easy.

Advanced map generation algorithm

About the commented code part in second order logic.
While the absolutely equal alrithm works in one pass, it doesn't in multipass. While this won't make the maps much harder, it's bad not to use such a possibility.
See code comments.