arqalite / rummy-nights Goto Github PK

Recently I've noticed a lot of things re-rendering unnecessarily or functions running infinitely in the background. Placing log! statements all around the code would help to see what things execute too often or for no reason.

Images load with a slight delay, which implies they either are redownloaded after each refresh (which is impacting performance and is wasting resources), or it takes a while to load them from cache (meaning there is a performance problem somewhere).

• Investigate the exact cause of images loading slowly.
• Make sure they cache properly, and ensure they load from cache on refresh.

We might want to let the user tweak a few things regarding the app and the game they are playing.

Currently thinking of:

• Add a settings modal menu in the intro screen
• #31

For the game screen:

• Let the user change the max score
• Implement a few systems for the various varieties of rummy (advantage, taking turns dealing cards)
• Decide if ties are allowed, or if tiebreakers are forced, or prompt each game.

This will be a dynamic list, things will be added/removed/ticked off as development goes on.

Players can return to the score table after the game ends to check scores, discuss individual games, whatever. However currently they can also go back to player select and modify the player list which shouldn't be allowed.

This needs to be solved before we implement any kind of game history tracking.

• Remove back button on score table if game has ended, ideally by not rendering it, but a display: hidden can also work.

During IRL testing, players wanted to discuss the final scores for quite a bit, so we need to ensure they can do that safely. #55 is one of the suggested features, and it would be worth disabling LocalStorage clearing to prevent games disappearing in the middle of discussions due to accidental refreshes.

• Remove LocalStorage clearing in winner screen.

Apparently opening the keyboard shrinks the viewport so we need to find a new way to pin stuff to the bottom of the screen.

get_game_status() runs on every re-render instead of running only when a score changes.

If playing with 4 people, the last person is not visible in the winner screen. This seems to persist on all screen sizes and aspect ratios.

• Adjust styling to fit between 2-4 players on the screen automatically.
• Test on mobile
• Test on desktop

When the game has started but the first round (first row of scores) isn't complete - back button should return to score table.

When the first round has started, the back button should go to the main menu, disabling editing players in an ongoing game to prevent issues.

• Modify the closure for the back button to check for game status and change the screen based on that.

Currently the tile bonus feature doesn't do anything if you try to use it twice in the same round. Ideally we should show an error message.

• Show an error message if the tile bonus button is clicked after being used once per round.

Finish a game, return to score table, you can add tile bonus.

When 2+ players are tied at the end of the game, the app tries to repeatedly sort the players, and keeps doing it infinitely.

• Change the sorting logic to handle 2+ tied players.
• Sort tied players by ID (preferred) or alphabetically.
• After the initial sorting is done, stop sorting to improve performance and avoid wasting CPU cycles (most likely we need a new state variable or a new atom for winner_screen.rs)

Related to #17 - when the game ends and there is a tie for 1st place, we go directly to the winner screen. Some players might prefer we give them the choice between playing a tiebreaker game to determine the true winner, or end it as-is and make everyone that tied the winner.

• Add logic to handle a tiebreaker game
• Add a modal to prompt for a tiebreaker if 2+ players are tied for 1st place
• Nice to have: a setting to default into a tiebreaker, or end directly depending on player choice

This can be most easily be replicated by adding players very quickly in the player select screen. Sometimes if you move too fast, the textbox doesn't have time to clear so you start typing in it and it keeps the text since the buffer is now reset with the new text.

Describe the bug
When typing in an input element (player name input or score input), the whole UI re-renders.

To Reproduce
Steps to reproduce the behavior:

• Open the inspect element page.
• Write slowly in an input element.
• The UI renders on every single character.

Expected behavior
UI renders once, then re-renders on submit, not on input.

We already have the button for it, but no functionality yet.

Ideally it should allow dragging elements around but I'm unsure how what would be implemented right now, so we could replace it with two buttons, one for up and one for down maybe.

Romanian Tile Rummy (RTR) has a bonus given to the player that has the matching tile with the exposed one (in Romanian, the "atu").
It would be nice if this can be tracked in-app so players don't have to manually add the points later.

• Figure out English naming for this - one candidate is "tile bonus".
• Add the button for it in the score screen.
• When clicked, the button should show a modal prompting the user to pick the player which got the bonus.
• The bonus should be applied on the next empty game and displayed as a tiny icon above that player's score in that respective game.
• The total score should reflect the added bonus.

Implementation could involve a second BTreeMap on the Player struct which will hold as keys the round where the bonus was granted, and the value.

Since Dioxus is under rapid development, the 0.2 release is quite behind on features, and 0.3 doesn't seem to be releasing soon, it might be worth switching to the master branch.

This does imply dealing with possible bugs, breaking changes and other fun things that come with following a master branch, but it might provide the benefit of getting new features and bug-fixes faster than normal. Both projects are not 1.0 yet anyway, so it doesn't matter that much. Plus it will make bug reporting and bug-fixing easier since the Dioxus team is referencing master for any issue.

• Create new branch and move to Dioxus master
• Fix code incompatibilities
• Test to make sure no breaking changes are introduced, or bugs that could affect stability/development.
• Merge into master if everything is good.

SessionStorage maybe?

After the game is finished and the winner screen is shown, if we return to the score table, the styling is incorrect. Unclear how and why that happens.

• Find the cause of the problem and update this issue with details
• Ensure styling is consistent when going back-and-forth between screens
• Investigate whether other screens are affected by this.

Describe the bug
In the game screen, the app saves to local storage endlessly. This is wasting CPU cycles and causing unnecessary read/writes.
It should only save when something actually changes, for now when the total score changes.

To Reproduce
Steps to reproduce the behavior:

• Start a new game, add players and go to the game screen.

Expected behavior
Game saves when score changes.

It currently saves endlessly.

Dioxus devs intend for the crate to be used with their CLI tool - however when development of this app started, it was not compiling properly. Assuming it's fixed now, it might be worth testing if migrating to Dioxus CLI is feasible, and if so, if there are any benefits to moving to it and ditching Trunk.

AFAIK one blocking issue is that Dioxus CLI doesn't handle service workers properly, and we need that for PWA functionality (#25).

• Download and install Dioxus CLI locally.
• Configure CLI to match the current Trunk setup - determine which features are missing, and which features exist in CLI that don't exist in Trunk (and figure out if we would benefit from using them)
• Test PWA functionality with Dioxus CLI - is the app installable on Android, does it work offline?
• If it's feasible, migrate from Trunk to Dioxus CLI

Make sure LocalStorage/SessionStorage is read only once per session to improve performance.

During early development we had PWA set up, however we ran into issues with caching and testing updates since the browsers would load the cached version instead of the new one even after a hard refresh. Simultaneously, photos would load with a delay, which either means performance issues when loading images, or they weren't cached properly/at all.

• Replace service worker with a custom-built one.
• Update manifest to reflect the newest updates.
• Tell Trunk to load the above files.
• #26
• Develop and test installability on Android (and iOS sometime in the future)
• Develop and test offline functionality (the app should 100% run without internet)

Describe the bug
I cannot add players using the add player button in the player select screen. Using Enter on the keyboard works though.

To Reproduce
Go to player select, enter a player's name, and press the add button. Nothing happens.

Expected behavior
Player gets added to the game.

Smartphone (please complete the following information):

• Device: Asus Zenfone 8
• OS: Android 11
• Browser: Chrome, app installed locally
• Version: v0.1.0

If 2 or more players reach or pass the threshold for winning the game and they're tied, the winner screen spazzes out and keeps shuffling the tied players around.

We need two things:

• #19
• #18

This was fixed for Firefox and Chrome (Android) a while back, but desktop Chrome and probably both Safaris still have it.

Input boxes in the score table have the spinner arrows next to it which are both unhelpful (scores are expected to be in the hundreds and multiples of 5 and 10, not individual points) and not aesthetically pleasing.

• Remove spinners via CSS
• Test Chrome and Firefox on both Windows and Android
• At some point, get Safari tested.

Is your feature request related to a problem? Please describe.
If you create a game with 4 players and move them around the list - once you start the game their IDs are also shuffled. This causes the score input focus to jump from ID to ID instead of the visible order of the players.

Describe the solution you'd like
When the start game button is clicked after adding players, reassign IDs so they match the player order.

This will affect the color assignments - but considering that is not a developed feature yet, we'll ignore that.

Players should be able to start a new game immediately if they want to play again with the same group.

• Add a button in the winner screen to allow restarting a game.

After a game ends, let the user go back and forth between game screen and winner screen.

• Add a button in the game screen, to return to the winner screen.

Rummy has as many variations as there are cultures in the world, each with its own rules and quirks.

The app aims to be as inclusive as possible, so we have a goal to support as many variations of the game as possible.
However there needs to be a "default" that the app will automatically configure when the game starts.

As of v0.1, the game defaults to Romanian Tile Rummy rules, with a maximum of 4 players and a max score of 1000.
Given that this is a personal project, I believe it's best to keep Romanian Tile Rummy as the default, but there is still work to be done.

• #50
• #51

For now the focus has been mobile, so the design is mobile-first, which leads to weird layout and element styling on desktops.

A workaround has been limiting the max-width to a phone size on desktop, but this isn't great.

• Style intro screen for desktops.
• Style player select for desktops.
• Style score table for desktops.
• Style winner screen for desktops.
• Test on as many aspect ratios and resolutions as possible.
• Test mobile after each change to ensure mobile is not affected.
• Ensure future features and additions are designed with both platforms in mind.

If you use the exit button to close game and return to main menu, it doesn't ask you to confirm if you really want to delete the game.

I think the button should just return to the main menu without deleting the game.

Is your feature request related to a problem? Please describe.
When the game ends, and you return to the game screen, it still shows the message "Good luck and have fun!".

Describe the solution you'd like
It would be nice if it showed "X won!" or something similar instead.

This is clearly not our problem per-se, but if you disable CSS you can click a player's name to grant them the tile bonus without checking if it was already granted.

• Add checks in the player name closure to prevent this.

Currently the app is written using a fixed width (the smallest width Firefox on Windows allows) but there are devices with narrower viewport than that, i.e my Asus Zenfone 8 on default settings.

The app has broken styling on them, with stuff overflowing off the edges of their parents.

• Switch to using relative units instead of pixels for positioning / aligning elements.
• Use breakpoints to style for very small screens, normal screens, and very large ones
• For testing, we'll use the Zenfone's display scaling and try out all the options.

This might require other developments before it can be properly implemented, but it should be pretty easy. Going for a black background might be all we need.

I think we need to make a settings menu first, in the intro screen and maybe in the score table too, and then add this.

...it and start game.

This changes the order of players everywhere, not just the winner screen.

Now that v0.1 is live, the repo became public - which means we need to clean up things and make sure people can contribute. Also the release system that GitHub uses relies a lot on pull requests - something that hasn't been used to its fullest now.

• Add a CONTRIBUTING.md file detailing the development and contribution process.
• Create a set of rules for commits, pull requests and merging.
• Try my best to follow those rules. :)

Clippy currently complains about score_table() being too big, exceeding its standard of 100 lines per fn.
It would make sense to split it into multiple function components, and while we're at it, refactor and spruce up the code.

• Split score_table() into multiple components.
• Refactor the code to make it more efficient, readable and/or less redundant.