Currently, our frontend has explicit calls back to localhost... we should resolve them so they correctly use relative paths.

Add the skip, reverse, draw 2, draw 4, and wild cards.

Make sure we finish a game when someone wins

Confirm you can search for a created game using a cypress test. Testing steps would be as follows

1. Create 6 games with different names
2. You will need to return to the lobby page between creating each game.
3. Set the page to only show 5 rows per page
4. Search for the 6th name in the search bar
5. Confirm that the 6th game shows up on the page.

Let's get a chat feature built in so we can trash talk each other

We have a nav drawer to show players, but the player has to mouse over it to see it. Let's change it so it stays open all the time.

I propose we rework the routes to be the following:

• GET /newgame -> POST /games
• GET /update/:game/:username -> GET /games/:game
• POST /startgame/:game/:username -> POST /games/:game/start
• POST /login/:game/:username -> POST /login (Handled in JWT?)
• POST /play/:game/:username/:number/:color -> `POST /games/:game/play
• POST /draw/:game/:username -> POST /games/:game/draw

The frontend should also be reworked to do the following:

• Use the new route names and post parameters in the request body
• Rename about to /game/:gameid
• Adjust the baseService to use relative URLs if possible instead of hardcoding based on the build env.

While I'm doing this, I'd also like to do the following:

• Rename newPayload to getGameState
• Add a Name and Host field to the Game struct so that the host can be checked in these requests and each game can have a name in the lobby.

deckUtils.go generates a shuffled Uno deck, but this deck isn't being used yet by the Uno game logic or client.

We are low in test coverage. Let's get this up above 90%

So, I would love to put in a PR to fix the volume mapping, but this Repo is not open for public contributions.

Would you like me to create a fork? Or are you planning on adding all of the class as contributors?

After merging a PR into dev, all of the actions trigger, and then fail for the following reason:

They should be updated to handle this case.

The interface needs to be able to connect to a local docker container mongoDB, the Google Cloud Firestore, optionally a Mock DB.

Now that we have the Database interface put in place, we need to flesh out the database interactions for our production Firebase database.

Acceptance Criteria

• Update the Database methods for db/FirebaseDB to use the firebase driver
• Update the connect method for FirebaseDB to load in whatever credentials are needed to connect to the prod Firebase
• Confirm that the production cloudRun environment variables sets a new OS Variable DB_TYPE=FIREBASE
• Confirm the production cloudRun environment gets the credentials it needs loaded into the application, either through a file or through ENV variables.

The Lobby shows the current games in the database. However, it doesn't automatically update. You need to entirely refresh the page to get the new game data.

Either do one of the following solutions.

1. Build in a refresh button that calls getAllGames so that players can just click a button instead of refreshing the entire browser
2. Modify the mounted lifecycle to set up an interval to query getAllGames every 2-3 seconds instead of just calling it on page load.

WCAG 2.0 AA

Original list of guidelines compiled by: Kris Rivenburgh

Issues relevant to this project are marked in bold and moved to the top of their section.

Section 1: Alternatives

• Alt text (1.1.1): All images and non-text content needs alt text (there are exceptions) --Steph

• Video & Audio alternatives (1.2.1): All video-only and audio-only content has a text transcript. Transcripts are clearly labeled and linked below the media.

• Closed captioning (1.2.2): All video with sound contains accurate closed captioning.

• Audio description (1.2.3): For any video, add an alternative video that includes an audio description of information not presented in the original video’s soundtrack (exceptions) or include a text .

• Live captions (1.2.4): Any live video presentations must have closed captions.

• Audio description (1.2.5): An audio description is optional under 1.2.3 level A but not in 1.2.5 AA.

Section 2: Presentation

• Website structure (1.3.1): Use proper markup techniques to structure your website’s content (e.g. use correct heading tags and HTML for ordered and unordered lists)

• Meaningful order (1.3.2): Present content in a meaningful order and sequence so that it reads properly.

• Sensory characteristics (1.3.3): When providing detailed instructions, make it so they aren’t reliant on a single sensory ability. -- We believe the class is sufficient for this project but agree that we could improve on this if it wouldn't be such a long task.

• Use of color (1.4.1): Do not rely on color alone to convey information.

• Color contrast (1.4.3): There must be a color contrast ratio of at least 4.5:1 between all text and background. -- Steph One change to make, #33b0ff needs to be changed to #007BC7

• Text resize (1.4.4): Text must be able to be resized up to 200% without negatively affecting the ability to read content or use functions. -- Steph

• Images of text (1.4.5): Do not use images of text unless necessary (e.g. logo).

• Audio control (1.4.2): Any audio must be able to be paused, stopped, or muted.

Section 3: User Control

• Keyboard only (2.1.1): All content and functions on a website must be accessible by keyboard only (i.e. no mouse). -- Jon

• No keyboard trap (2.1.2): Keyboard-only users must never get stuck on any part of the website; they must be able to navigate forwards and backwards. -- Jon

• Adjustable time (2.2.1): If there any time limits on a website, users have the ability to turn it off, adjust it, extend it.

• Pause, stop, hide (2.2.2): If there is content that blinks, scrolls, moves, users must have the ability to pause, stop, or hide it.

• Three flashes or below (2.3.1): Web pages do not contain anything that flashes more than three times in any one second period.

• Skip navigation link (2.4.1): A “Skip to Content” or “Skip Navigation” link allows users to bypass the heading and go straight to the main content.

Section 4: Understandable

• Page titles (2.4.2): Each page of a website needs to have a unique and descriptive page title.

• Focus order (2.4.3): Users must be able to navigate through a website in a logical sequential order that preserves meaning. -- Jon

• Link anchor text (2.4.4): The purpose of each link should be clear based on its anchor text (e.g. don’t use “click here”) -- Steph

• Multiple ways (2.4.5): There are multiple ways to access different pages/information on a website (e.g. search bar, nav menus, sitemap, breadcrumbs, helpful links after content).

• Descriptive headings and labels (2.4.6): Headings and programmatic labels must be clear and descriptive. They do not need to be lengthy. -- Jon and Steph

• Focus indicator (2.4.7): Any “user interface control” that receives focus from a keyboard user should indicate that focus on the current selected element (e.g. add a visible border around a text link). -- Jon

• Website language (3.1.1): Set the language for your website. -- Steph

• Language changes (3.1.2): Indicate any language changes for an entire page or within the content.

Section 5: Predictability

• No focus change (3.2.1): Nothing changes merely because an item receives focus; a user must actively choose to activate an item (e.g. hit enter to submit) before a change takes place.

• No input change (3.2.2): Nothing changes just because information is inputted into a field (e.g. form doesn’t auto-submit once all fields are filled out).

• Consistent navigation (3.2.3): Keep navigation layout consistent throughout all pages of the website (e.g. same links in the same order).

• Consistent identification (3.2.4): Components that have the same function within a website are identified consistently (but not necessarily identically) (e.g. two checkmarks can indicate two different things as long as their function is different — one indicates “approved” on one page but “included” on another).

• Error identification (3.3.1): Make any form errors easy to identify, understand, and correct.

• Form labels and instructions (3.3.2): Programmatically label all form or input fields so that a user knows what input and what format is expected. -- Jon

• Error suggestions (3.3.3): If an input error is automatically detected, then suggestions for correcting the error should be provided.

• Parsing (4.1.1): Make sure HTML code is clean and free of errors, particularly missing bracket closes. Also, make sure all HTML elements are properly nested. -- Steph

• Name, role, value (4.1.2): For all user interface components (including forms, links, components generated by scripts), the name, role, and value should all be able to be programmatically determined; make sure components are compatible with assistive technology.

• Error prevention on important forms (3.3.4): For pages that create legal commitments or financial transactions or any other important data submissions, one of the following is true: 1) submissions are reversible, 2) the user has an opportunity to correct errors, and 3) confirmation is available that allows an opportunity to review and correct before submission.

currently, in the Create Game Modal, you have to actually click the Join or Create and Join Button with your mouse.

It would be ideal if the modal could also accept the ENTER button as an input to automatically submit the input.

(I'm not as certain if this is possible with how we have built the modal, so you would need to research if it is possible) It however would be a nice feature to have.

uno.go has a method by the name of playCard. This particular method does not have any unit tests created for it.

Write a unit test that sets up the data in the database for an entire game.

1. Create the game
2. Add a player to the game
3. Start the game.

Grab one card from the player's hand, and submit it to playCard
Confirm that on calling playCard the player's hand is now missing that card.
Confirm the card is in the top of the discard pile in the game

When getting the application off the ground, we ran into the problem of getting Your User's information. In a last ditch, late night change, we implemented the data from the player (as decided by the token) into the gameState.

Realistically, the gameState should only return game data, and not your player's data.

Acceptance Criteria

• augment /players/token/:token to bring the entire player data back from the token provided
• Remove the player data entries off of the gameState object on games/:id

uno.CreatePlayer current does not have a unit test created for it. Create a unit test to confirm that it does indeed create a player, and the data provided to the function is properly stored in the database.

Needs to be possible on both you down to a single card, or you calling uno on another player.

Show all running games on server and allow others to join a game.

Maybe even password protect games to prevent random players from joining.

Join by ID, to allow private games.

The front end needs to pop up some mechanism to select the color. The backend is designed to have the wild submit its color like a normal card, the front will then render the wild card to the selected color so everyone knows what color was selected.

FYI, the draw 2 already does this... so shouldn't be too hard

uno.go has a method by the name of joinGame. This particular method does not have any unit tests created for it.

Write a unit test that sets up the data in the database for a player to join a game.
Confirm that on calling joinGame, the player joins the game.

Make sure it is safe and appropriate

If they player closes their browser and doesn't do a getGameState poll for several seconds we can note in the UI that the player is no longer present

/join_game?id={game_id}
====returns====
{'valid': true/false, 'user_id': 12234/-1 }

/new_game?host={username}
====returns====
{'new_id': id, 'host_id': 12234/-1 }

/start_game?game={game_id}&=host={player_id}
===description===
If player_id==host_id: start game. Return the first turn player
====returns====
{'game_started': true/false, 'turn_id': 12234/-1}

/deal_cards?id={player_id}
====returns====
{'cards' : [ { 'num' : 9, 'clr' : 'red' } , ...] }

/draw?player={player_id}
====returns====
{'cards': [ { 'num': 7, 'clr': 'blue' ] }

The game frontend (About.vue) should keep track of which game it's referring to, and make calls to the API with that information.

Running "docker build ." on the top level results in docker failing mid-way through. It seems that the production build is dependent upon many development environment packages including the build-watch and linters.

I've been working on a github action to deploy to ECS but I've been stuck trying to figure out this dependency issue for hours now.

We should add more unit tests to the route handling code in the server. A file already exists for this purpose. We should only need to add test for each of the routes

Make sure it does turns correctly

Write a unit test to confirm the data brought back from uno.getGameUpdate matches the data that should be in the database.

We recently implemented a vue-navigation-drawer to show all of the players.

It currently is set to expand on hover. Which allows players to have it collapse when it's not being viewed.

However, Some players may want to have it always open.

We can build in a vue-switch - See documentation HERE to toggle it always to be open

You can also see an example of how to integrate the switch HERE

Uno logic should live in its own file.

Otherwise we don't know when to call uno

Button to sort/unsort, use drag and drop

Currently the game id is hard coded. This needs to generate new games and add them to database to make them joinable.

The current mechanism for showing the players gets odd when there are lots of players in the game. Let's move it to a navigation drawer on the side, so it is a little cleaner