Iteration 2 User Stories

For iteration 2, you must implement the following user stories (features). Point values indicated in [square brackets].

As a user I want to...

Game Played Difficulty

  • [15] Each time I play a game, I want to be able to select a difficulty level for that specific game play.
    • If I select "normal" I want the scores required to earn an achievement level be 100% of the usual amount.
    • If I select "easy" I want the scores required to earn an achievement level be 75% of the usual amount.
    • If I select "hard" I want the scores required to earn an achievement level be 125% of the usual amount.
    • When viewing an achievement screen, I want to see the difficulty level listed on the screen.
    • When viewing the list of games played, I want to see the difficulty level listed for each game play.

Achievement Improvements

  • [5] When a game is played and an achievement level is earned, I want an image, some animation effect, and a sound to be played to make it feel like a reward and a celebration.
  • [15] I want to select a theme for the achievements. I want at least 3 different themes to choose between.
    • It's up to you what themes to support, but possible ones might be: cute fantasy creatures, powerful fantasy creatures, dinosaurs, a movie, or (kids) TV show.
    • I don't want the theme to be specific to any given game configuration, or to a specific game played, but rather be used when I'm viewing the achievements (such as viewing achievement levels, or recording a game play).

Edit Game Played

  • [5] When viewing a previous game play, I'd like to be able to edit it to correct any errors, such as changing scores or difficulty so that I can correct any errors from previous game plays.

Friendly UI

  • [15] Make the UI friendly and good looking so that it is more appealing to use.
    • Perhaps adding background images, or customizing the font or buttons.

Score Calculator

  • [15] When recording a game play, change the screen to allow the user to enter each player's score individually so that I don't have to add it up in my head when I'm playing with multiple players.
    • The app must ask how many players there are and then allow me to enter each player's score individually.
    • The app should know the individual scores in the future, so that I can later go back and see or edit the individual scores.
    • The computation for the achievement level is still based on the sum of all player scores.
    • There is no need to identify which players are which; I just want to enter and view the scores of each player.

Development Process

  • [5] Team must implement JUnit unit tests for at least one class in the model.
  • [5] Team must estimate the work required for 5-6 user stores. In a text file in the docs/ folder, state on one line per user store state:
    • Brief description of the user story
    • The estimated amount of work for that story
    • Include a mention of what your team used as a unit of 1 work.
  • Team must take notes in meetings; rotate who takes notes. No need to submit proof of this.

General Requirements

  • [10] Overall
    • App must have a min SDK version of 27 (or lower)
    • App must have a target SDK version of 30 (or higher)
    • Add a back button on the tool-bar (app-bar) at top when appropriate.
    • From any screen, the Android back button must do the "reasonable" thing.
    • Application flows smoothly.
    • Nice UI layouts; resizes to different size screens reasonably well (ex: 5", 6", 10")
    • Every group must have a coding style guide checked into your repo (RM suggest it; team discusses it; team has final approval)
  • [10] Correct use of Git and GitLab
    • Using GitLab Issues to track features to work on.
    • Use Git/GitLab branches and GitLab merge requests
    • Correctly builds when cloned from GitLab.
    • Each team member must do 2 code reviews of merge requests (MRs)
  • [0] Must have good quality code (Up to 20 point deduction)
    • Good class, method, variable names.
    • Perfectly formatted code.
    • Comments on all classes (not needed inside classes, just on the class level)
    • All strings which end user may see on UI (not LogCat) are in strings.xml
    • Model classes must be in a separate package from the UI (activities)

Constraints (for all iterations of project)

  • All development must be in the GitLab repository creating for your group.
  • Use the GitLab workflow, as discussed in class:
    • Start feature with a GitLab issue
    • Create a feature branch
    • Commit code to feature branch often
    • Merge Master to feature branch once feature completed.
    • Submit Merge Request
    • Code review, fix, and merge.
  • Good commit comments on (almost) all commits and merge requests.
  • Well built UI, including:
    • Well laid-out usable screens.
    • Works on different sized screens. Example tests on 4", 6", 10".
    • Use of icons and images where possible.
  • Simple OOD supporting not much more (if anything) than the current set of requirements.