Arrow Keys : move
X : confirm // delete block // chording
C : set / delete flag
- high score is now working (hopefully)
- new animation when deleting the blocks
- "best time" indicator for the game-over screen
- Numbers in "dark mode" are now the same colors as "light mode"
I've changed some colors in the game to make the animations pops a lil more
You have now to press a button (x or o) in order to exit the game over screen
Big thanks to RealShadowCaster for the help and all the brilliant ideas!
This is extremely polished in terms of visuals, animations and sound.
Paradoxically, the only part lacking is the actual game play :
Flood fill is bugged :
it triggers when revealing a number adjacent to a zero :
Even when a zero is revealed, the flood fill sometimes stops :
When losing, it's interesting to study the grid to see what could have been. Unfortunately, the otherwise super cool tile fall effect makes it impossible. Some visual difference between revealed numbers by player vs by computer would be welcome.
When winning, the timer goes on for a few seconds more.
The controls feel sluggish : minesweeper is about solving the grid as fast as possible. If I tap tree times right, one time down and then X, I most definitely don't want some of the inputs to get thrown away. Diagonal movements also almost never work. You are forced to slow down to the rhythm of the red cursor animation to get reliable inputs, very distracting.If a directional cross release is detected, you can let the cursor finish it's current move, but any new input should be treated as if the cursor had already reached it's destination tile.
Chording is not implemented (pressing X and O at the same time while the cursor is over a number that has exactly the correct number of flags around it to clear all non flags around the cursor). It's essential to speed solving.
Minesweeper is about beating your time, Each starting number of bombs could have a high score. With bombs being between 10 and 40, that's 30 numbers to save, fits nicely into the 64 numbers of cartdata and dset(). There's even enough room for a 3 or 4 character signature with memory poking, if you want.
I'm sorry if my comment feels too harsh, this version is just so near to excellence, and yet it doesn't play nice... Pretty frustrating. Will keep an eye on the cart progress.
Honestly, my favorite implementation of Minesweeper. I'm really glad I stuck around to learn more of the game this time, though it was easy with the design and beautiful sound effects. RealShadowCaster is right that it does have some bugs, (I think? I'm not a Minesweeper) but all in all, Nice job!
First of all, thank you for playing my game, and also for taking the time to write a very detailed critic, it help me a lot !
To be honest, I have discover this game while coding it, never get it as a child.. lol
For example, I didn't know there was such a thing as "Chording"
But thanks for the insights ! ahah
Anyway I've just finished to re-write some parts of the code, the flood fill was indeed broken, it should be fixed now.
I've added the "Chording" too, if you press "X" and "C" at the same time on an empty spot.
I've also implemented a "best time" system.
The controls should be better, I've removed the animation.
I hope this feels better now !
Controls are now much better and chording works great.
It's still ever so slightly sticky at times:
For example, if I do Up Flag Right quickly in this situation, the flag gets placed 2/3 of the time. The directions seem to be always registered but I'm guessing the order I'm releasing the directions and button change the flag outcome.
Diagonal movements are still a bit strange also.
Minor thing : the counter starts if you place a flag at start of the game when trying to remember which button is witch. This way you can die 1st click.
I wish the reveal animation of the 8 tiles around the chorded number would be a little faster (though the timing for the tiles more than 1 square away from the cursor is OK as is), right now I'm trying to use gut feeling based on the colour of partially revealed tiles when speed solving.
When winning a game, the new time erases the old one regardless of which one was the best.
When beating the high score, a congratulations message (instead of the PERFECT one) showing the old time would be welcome.
When hitting the bomb min or max during selection, the high scores get shifted around.
EDIT : Chording controls don't work well any more.
Hi again !
I've changed the button for the chording, it's now the same as the set flag button (I feel it kind of weird to press 2 buttons at the same time)
"When winning a game, the new time erases the old one regardless of which one was the best." ahah yeah I've just noticed that, I did the score system very fast I should have been more careful. It's fixed now
"When hitting the bomb min or max during selection, the high scores get shifted around." not sure to understand sorry, the "best time" change with the numbers of mines in the menu, which seems logical to me
I will certainly add a "new high score" message in the future, it's a great idea !
For the controls i'll see what I can do in the next update.
Thank you again for all these good infos !
EDIT: best time is still broken in v4.
About the high score shift :
At game start , you see the best time for 20 mines. Press left until the number shown is 10, the press left again. As intended, the number stays at 10, but the time displayed still shifts and gets out of synch.
When Microsoft minesweeper was released, most pc mice at the time only had two buttons. The chord action was Microsoft’s solution to replace the middle click(unix graphical workstations had three button mouse by default at the time), in order for the game to be mouse only. The chording move was actually named like that because you press multiple buttons at the same time on the mouse, as if playing a chord on a piano.
Chording with too buttons feels natural to those who played the original with a mouse, but you should adapt and experiment when the input device is changed.
On tablets, chording is implemented as double tap on the number, and flagging as double touch (two fingers on the screen at the same time) or with a toggle button on screen.
If you choose single button on number for chording, I’d recommend the probe button instead. This way the flag button is always safe and probe button is always a commitment.
I see you've updated again !
Chording with X is much better, remember to update the controls section to reflect the change. I would never have thought of it, it's great to have new eyes on an old game.
High score shift bug is still there.
Didn't comment on game over screen with colour shades to tell apart revealed tiles from others : it's great.
High scores properly updated with new message. Would still like to see how much better than before I did. Since the previous high score is overwritten, the best moment to show the information is just before the update, on the NEW HIGHSCORE message.
The game is great and pretty much finished as a single player game, but if you feel up to it, you could totally add local co-op multiplayer :
Controller 1 is the main and the only working one out of game. You could have mini cursors movable by controllers 2-8 locked in a mini-box in the selection screen as a playable reminder that multiplayer is supported.
When a game is started, and before the first probe is done by player 1, controllers moving spawn their cursor on the grid (1 colour/player).
To handle the display of cursors sharing a cell, an edge or a point, there is a simple trick : display all cursors in a random order each frame, making the shared parts blink in an electric/sparky way.
Alternatively, you could have each shared edge alternate pixel colors from every cursor sharing the edge. This might be more in line with the clean an sober style of the rest of the game.
Flags should be of the colour of the player who put them down, and not removed at game end. Crosses should be of the colour of the wrong flag.
Every player should be able to remove any flag.
If a player probes a bomb, the bomb is revealed in the player's colour and the player is out of the game. You can still let him move a dotted cursor (displayed first (below other cursors) so as not to bother players still alive) so he can point at cells and talk to others without putting his hands on the shared screen.
The game is only over if solved or if every player probed a bomb. A co-op high score should be distinct from the single player high score. You can use the fractional part of the bomb count's high score to save it, otherwise you'll run out of cartdata space. Divide your integers by a power of two to avoid rounding errors. Because it's not signed you have 16 bits worth of data in the fractional part of a pico8 number (only 15 bits in the integer part, 1 bit set to 0 for the + sign).
There is an alternate way to handle the flags in multiplayer :
You can treat flagging as a reverse proble and penalize/kill the player who tries to misplace a flag. This makes perfect sense in an online game so you can trust other people's flags, otherwise the board would be filled with kilometers of false flags put down by trolls with auto clickers. But I think trolling an making mistakes is part of the fun of local multiplayer. Dying to chording thanks to a misplaced flag from another player can be fun for everyone.
I did ! :)
Thank you for all the ideas, as you can see I've tried to implement most of it, all of it works pretty well and I'm super glad !!
For the highscore it's pretty weird, I didn't have this behavior at all (I've tried on multiple devices), it's working good. Was that v6 ?
The co-op sounds really great, but this is a little out of scope for this project I'm afraid, I think for now I'm done and ok with it! But maybe in the future..
I really appreciate the help/time and play testing, thank you very much !
Also very curious about this highscore bug I'll have to investigate ahah
EDIT: ok I see it, man i'll really have to read twice my code.. I'll fix that with a last update, I'll try to add the old "best time" to the game over screen too, sounds great to me !
Took a peek at the code, in function upd_menu(), line 379, you fix the values mines, slot_1 and slot_2 so they stay in their valid ranges, but because the interval width of slot and mines is not the same, you bump into the mines boundary before you hit the slot boundary. mines stays at the boundary while slot still gets updated, and things are now out of synch.
You are very brave ahah
"With bombs being between 10 and 40, that's 30 numbers to save, fits nicely into the 64 numbers of cartdata and dset()" I should have been listening to your wise advices ;) with 50 mines, I had no chances ahah
I've just updated to v7, I hope everything works fine now :)
Congratulation, v7 seems to work fine and is great for speed solving.
If you absolutely wanted to go up to 50 mines (or more), you could save each high score as a single number : the total time in seconds.
You'd need simple division and modulo to extract back the minutes and seconds from it. If you go this route, you have to deal with the format save change in one of the following ways :
1) Don't care, the high score table gets messed up, player will have to use the "clear data" manually to fix things. Nothing to do for the developer.
2) Auto reset the high scores : use another cartdata identifier string.
3) use a previously unused slot (63 for example) as a version number of save format. If the current version is 0, do the extraction, conversion and rewriting of the save data in the new format, including the format number. This is the kind of mess you are forced to deal with when losing the data is not acceptable (say 100 hours of farming simulation progress for example). This is luckily completely overkill in this situation.
[Please log in to post a comment]