FlaggedCell should not be clickable, on clicking which it is just borking the in-progress game currently. (see).

As the project does not rely on any support library, there is no real need to enable Jetifier.

The current UI / UX situation is pretty OKAYY, there are a lot of things that could be improved.

Things to do:

(in priority order?, maybe)

• #88
• #93
• #96
• #97
• #94
• #95
• #103
• #100
• #99
• Some of the SFX could be improved
• #105
• Reconsider color schemes of Day / Night theme
• #106

All contributions are welcome, any contribution / feedback would be ♡ly.

Contributions don't necessarily need to be code only, they could be font / UI / UX suggestions, references, or design files.

As the visibility modifier of MineGrid has been relaxed to public. There should no longer be need for DebugMineGrid and EmptyGrid.

Check if they need to exist, if not remove.

• Check and remove DebugMineGrid.
• Check and remove EmptyGrid.

Change cell reveal animation to scale up/down animation.

The current implementation of child cell composables doesn't quite support this.
The inverse cropped circle present in all of the child cell composables would interfere with the scale in/out animation.

FlaggedCell, UnFlaggedCell, ValueCell

That mask probably is needed to be pulled a composable layer back, maybe keeping the mask in the RawCell composable would solve this interference.

Continuing from #34

Some people like to live dangerously. They don't want to flag the cells even if they know they are mines. Instead, they keep everything in mind and carefully reveal the rest of the cells.

So, for them, it would be nice if the MinefieldController could check if all of the non-mine cells are revealed, and then, if true, call it a win.

Not only this should be a check, but this should be the check.

Meaning, even tho a player has flagged the required number of mines, the game shouldn't come to an end state (or success state) until all of the non-mine cells are revealed first.

This logic is required, as in some scenarios, the player could win the game by just guessing the mine cell position by randomly flagging mines (or by brute-forcing the combinations).

For example, when only three cells are left unrevealed, and there are only two mine cells required to be flagged. Now, the player could randomly flag any two cells as mines, and if he is right, the game automatically goes to the success state, and if he is wrong, nothing happens. So he could try out different combinations until the game automatically goes into the success state.

So, for the game to go into success state, all of the non-mine cells must be revealed first.

In the GameStartedTopBar show remaining / total count.

Add haptic feedback on clicking/flagging/unflagging a cell

ValueCellRevealer is not propagating MinefieldEvent.OnGameComplete event as there is no return statement in if true block, and MinefieldEvent.OnCellsUpdated is always being returned.

https://github.com/JayaSuryaT/minesweeper-j-compose/blob/5ced8ff5649731fe8e2289f6ae851e441ae230f9/minesweeper-engine/src/main/java/com/jayasuryat/minesweeperengine/controller/impl/handler/ValueCellRevealer.kt#L80-L86

Add a settings screen to customise following things

• Enable / disable sound
• Enable / disable vibration
• Selecting default flag / reveal mode
• Show / hide mode toggle

TODO

• Come up with UI / UX
• Create a new screen for settings
• Hook in logics to Enable / disable sound and vibration
• Hook in default mode selection logic
• Hook in logic for showing / hiding toggle in game screen
• Consider persisting all of the settings in preferences

Deprecate OnGridUpdated in favour of OnCellsUpdated.

Both events essentially serve the same purpose, but using OnCellsUpdated would be more performant as only the updated Cell(s) would be propagated through this event unlike OnGridUpdated which assumes that all the Cell(s) of the Grid have been updated. Which may lead to some redundant computations and side effects like #12.

Make generateGrid method of GridGenerator suspending

Currently, when the first cell is revealed (or whenever a bunch of cells gets revealed due to any action), the cell revelation order is like:

"Diagonally reveal up to the topmost (and the leftmost) cell (which is getting revealed), and then start revealing linearly one by one from left-to-right then top-to-bottom."

This works fine and looks good enough when the game is totally zoomed out, as it is easier to follow.

But, when the player is zoomed in a fair bit, and if he reveals a cell, which in turn reveals a bunch of other cells, and cells offscreen start getting revealed. Here comes the problem, based on the position of cells and state of the board, the adjacent cells right next to the revealed cell might not get revealed in the first sweep and may take some to get revealed.

This particular problem is partially being solved by providing aural and haptic feedback. With this, the player should (ideally) get to know that cell revelation is in progress. Again, this is not a perfect solution to this problem, but it does help a bit.

One more thing that could help curb this problem is changing the revelation order to radially outwards from the clicked cell.

TLDR : Reveal cells radially outwards from the clicked cell.

Le Refactor

There is a decent amount of object creation, and mapping one thing to another happening, manually.
It would be nice if DI is introduced and all of the object creation and dependency provisioning is wired with it.

Add audio feedback on clicking/flagging/unflagging a cell

The "3" cell looks pretty similar to an unrevealed cell. Sometimes the player may assume it as an unrevealed cell and continue.

Need to update the colors of the value cells so that they are distinct from each other and from the unrevealed cells as well.

Add a screen to select different difficulties and drive GameConfiguration based on the selection.

Hi Jaya,
The game is enjoyable, and moving gradient over cells is pleasing. Good job.
But, the issue that I want to bring here is : If I play the game with autorotation turned on, every time I tilt the phone, the game is getting rotated, and I am losing progress. Please fix this.
You can either make the game unaffected by screen rotation or keep the progress even after rotating the screen.

Continuing on #33

All cell revelations were supposed to be sorted radially outwards, issue #33 only solved the initial cell revelation part.
Need to reveal cells in the same fashion even when the cells are revealed due to clicking of a MineCell.ValuedCell.

This could be done by utilizing RadiallySorter in ValueCellRevealer and sorting output before returning.

Different players have different style of playing this game. Some prefer flagging cells as their primary action, some prefer just revealing all the cells, and most players prefer a combination of these both. And long-pressing every time to flag a cell may slow some players down a bit.

It would be good to have a toggle to switch between clicking and flagging to accommodate different styles of playing the game better.

(This is also an extension of #34)

CellFlagger currently only verifies if all the MineCell(s) are flagged or not. (see)

If all of them are flagged then propagates OnGameComplete event. Which is not correct as there could be some cells which are inappropriately flagged, i.e., non MineCell(s) being flagged as well.

With this condition, essentially all one has to do to win the game is, just flag every cell.

Need to incorporate logic to also ensure that the total flagged count matches the total mine count of the Grid along with the existing conditions, before declaring that the game is complete.

STR :

1. Launch game in Extreme difficulty mode.
2. Reveal any cell.
3. While the revealed cells are still animating in, navigate back to difficulty selection screen.
4. Sound and vibration feedback would still be playing for a while in difficulty selection screen.

Right now all the Grid(s) being generated are assuming a default starCell (see).
And because of this, there is a possibility that the initially clicked cell can be a mine and the game may get over after the first click.

Need to make startCell param of GridGenerator dynamic.

Should start off with an essentially an "empty" grid, and from there considering the first click the grid should be generated (as it is being done already).

If a player changes the app theme (system theme to be precise) while the game is in progress, the game progress is lost.

This issue may get resolved with #38

No page animation after introducing difficulty-selection screen.
Earlier it was handled manually, now probably need check and setup page animations with navigation-compose

Resuming game

It would be nice if the user could resume the game from where they left off the last time.

The flow could be something like this :

1. User chooses a difficulty level, starts the game.
2. Leaves the game / closes the app.
3. User reopens the game.
4. User is directly navigated to the game screen with the same grid where he left off the last time.
5. He can continue from there or navigate back to the difficulty selection screen.
6. On continuing, the user should be presented with the same grid that they had played and left the last time.
7. In the difficulty selection screen, on selecting a difficulty level and starting a game, if a previous unfinished game with the same difficulty level exists, the user should be prompted with a dialog about whether he wants to continue or to start over.
8. Based on what the user chooses, an appropriate game board should be rendered in the game screen.

How?

• Choose a KMM library for DB (SQLDelight chosen).
• Extend the data module to have a DB to be able to store objects.
• #72
• #74
• #78
• #81
• #75
• Handle game restart.
• #79
• #80
• #82
• #83

The animating gradient background is a little bit distracting.
-as per user feedback.

And if not for that, making the gradient animation slower would give it a more "soothing" or "calming" vibe.

• Work out an optimal duration such that:
  • It is not distracting,
  • it looks soothing/calming
  • And if possible, not so slow that it might not look as if it were not animating.
• Update the gradient with that 'optimal duration'.

Cells are getting revealed in a weird fashion, especially the edge cells at the bottom.

On clicking of already revealed ValuedCell.Cell at the edge of the Grid, unrelated cells are getting revealed.

Currently the initial grid generation logic is tied to GameViewModel.
It would be better to decouple the initial state generation logic from the GameViewModel.

If resuming the game becomes a feature, this would come in handy.

Dark theme is looking like garbagio on some devices, so, Tackle the forced dark theme

Instead of keeping the UI and game state in composables, introduce ViewModel(s) to maintain the same.

There are a bunch of user preferences to be stored, see #53.

TODO

• Choose a persistence library (preferably a KMM one, see here)
• Create a new module for persisting data
• Do the thing (implement persistence logic)

ValueCellRevealer propagating already revealed cells in OnCellsUpdated event.

(See) for RevealedCell

(See) for FlaggedCell

Altho this will not affect UI as MutableStatefulGrid is using structuralEqualityPolicy() to generate the MutableState, so, based on diffs there might not be any recompositions triggered for these particular cells.

But, any custom logic present at any of the StatefulGrid implementation in the updateCellsWith method's onEach block will get triggered unnecessarily.

So, anyways as these cells don't need to be part of the event, at these particular branches we can just return emptyList()

STR

• Finish a game by either moving to GameOver or GameCompleted state.
• Observe GameFeedback getting triggered (sound and vibration).
• Navigate back from the GameScreen.
• Observer GameFeedback getting triggered again.

This is most probably being caused due to not wrapping GameFeedback properly in a side-effect.

Add a prebuilt release variant APK so that folks can try out the app without having the need to build the project.

This issue continues on the problem discussed @ #33

When the player is zoomed in a fair bit, and if he reveals a cell, which in turn reveals a bunch of other cells, and cells offscreen start getting revealed.

This particular problem is partially being solved by providing aural and haptic feedback. With this, the player should (ideally) get to know that cell revelation is in progress. Again, this is not a perfect solution to this problem, but it does help a bit.

The player might not be aware of what is happening in the background (offscreen to be precise).

Even tho this is not a huge deal-breaker, it would be nice if we had a better solution for this problem.

Any idea is welcome✌️, things which could be considered are:

1. More emphatic haptic and aural feedback
2. Visual cues (like a progress bar or something, non-intrusive of-course)

Or, any completely different idea 💡

Some people like to live dangerously. They don't want to flag the cells even if they know they are mines. Instead, they keep everything in mind and carefully reveal the rest of the cells.

So, for them, it would be nice if the MinefieldController could check if all of the non-mine cells are revealed, and then, if true, call it a win.

(this is just an exaggeration, it's a good/must? to have feature :p)

If a player locks the device while the game is in progress, the game progress is being lost. (even tho if the app is in the foreground)

This issue may get resolved with #38

Add zoom/pan state persistence across theme changes.

On changing (system) theme, the game state is persisted but the zoom and pan are being reset to default.

Options to consider :

• Instead of exposing zoom/pan as a modifier, expose them as concrete value(s) which could be persisted using:
  • rememberSaveable
  • Or hoisting the value to the nearest viewmodel
• Different / better ideas are welcome

https://github.com/JayaSuryaT/minesweeper-j-compose/blob/05110a71b6fda0bece0f00f6c383c4c4bc140e43/minesweeper-ui/src/main/java/com/jayasuryat/minesweeperui/grid/Minefield.kt#L33