On Tue, Feb 14, 2023 at 7:26 PM [email protected] <[email protected]> wrote:
> To make a long story short, one of the features I incorporated was that no > mine can be present in any cell surrounding initial click. In essence, the > cell you click will always be a zero. This is how Microsoft’s version works > as well. > Neat! I never knew that. If you set up the minefield prior to clicking, you need to do some checks > on initial click and move mines around. > By waiting for the user to click, it ensures we can do the minefield > generation all in one go, which is just a bit simpler. > I figured the behaviour was so weird there had to be a good reason. While it may be more complicated to move the mines around after the initial click, it might be worth it to avoid giving the user a long hiccup in game play. > Re: the Flag. I’ve gone back and forth on it. Myself and a few others were > having trouble distinguishing an ASCII character from the surrounding > numbers at a quick glance. > Personally I found the checkerboard a bit more readable. Better yet would > be an inverted ASCII but I haven’t managed to work on that yet. > Yes. An inverted capital 'P' was exactly what I was thinking of. The top of the capital P in the Model 100 font touches the edge of the character cell, so it won't look quite as nice as the AsciiPixels flag, but I think it'll be darn close. Alternately, if you're going outside the standard ASCII range, consider GRPH + M which types what I think is supposed to be "Mailbox with Flag Up". Make sure to check out what happens when you click a number cell, and it > has the appropriate number of flags around it. > Yes! That works great. Do you already have plans to implement the other half of the behaviour, where one clicks on a number which is equal to the count of surrounding flags and unknown spaces? All the unknown squares must be mines, so they can be automatically flagged. —b9
