- Develop your skills in writing:
- semantic HTML
- clean & organized CSS styles
- Manipulate the page after it has loaded adding, removing, and updating elements on the DOM
- Understand event bubbling and use event delegation on dynamic elements
- Build a game where two users can guess a number between 1 and 100, with the ability for the user to add custom ranges for increased difficulty of play
- Display the current guess of both players
- Display the final results of each match in card UI
- each card should display the name of the winner
- each card should display both player’s names
- each card should show how many guesses it took to guess the correct number
- each card should have a delete button that removes the card from the page
- EXTENSION: each card should display how long the match took
- Game should be fully responsive and usable down to screens/viewport width of 320px
- Project should be pushed to Github with a live site on Github Pages
- Care and attention to detail should be clearly demonstrated in execution of the comp
- Include a
README.mdin your project that summarizes the project (this does not mean paste this project spec into your README)
Phase One: Basic Requirements
The application should have the following user interface components:
- Two inputs to set a custom range for the random number to fall within
- A button to update the custom range
- for each player:
- An input field for guessing the number which can only accept numeric values
- An input field for their name that can accept any alpha-numeric character
- One button that submits both players guesses
- A button for clearing the input field, which does not reset the random number
- One button that resets the game and generates a new random number
- The clear button should be disabled if there is nothing to clear.
- The reset button should be disabled if there is nothing to reset.
Players Guess State:
- Display both player’s most recent guesses
- Display results and feedback for each players guess:
- If their guess is too high, it should display the error message: “That’s too high”
- If their guess is too low, it should display the error message: “That’s too low”
- If the guess is correct, it should display the success message: “BOOM!” and create a new card to display results (card details are outlined in Phase Three)
Some things to consider:
- Input fields, regardless of their “type” attribute, store their values in strings. You’ll need to use
parseInt()to turn it back into a number.
- You’ll need a strategy for generating random numbers.
Phase Two: More Better
- Range and guess input fields should only accept numerical entries
Guessfields should only accept values that fall within the defined min and max range.
- The application should display an error message if the value entered in the
Max Rangeinput is less than the value in the
- The application should display an error message if the value entered in the
Min Rangeinput is greater than the value in the
- The application should display an error message if either guess is not a number (e.g.
- The application should display an error if either guess is outside of the range of possible answers.
- The application should display an error if the
Submit Guessbuttons are clicked when their associated input fields do not have a value entered
Phase Three: Level Up
Upon successful win, user’s range is updated:
- Every time the user wins a round increase the maximum number by 10.
- Every time the user wins a round decrease the minimum number by 10.
Display final result of each match in card UI:
- Both player name 1 and player name 2 should be displayed
- Winning player is indicated
- Total combined guess count of both players is displayed
- Delete button removes the card from page
Phase Four: Level Up extensions (if you complete all of these, reach out to instructors for more goodies)
Work through these in order:
- Display how quickly user guesses correct number
- Include at least 3 different animations. Example: one for when a card gets created/deleted. Check out this link of great examples for inspiration
- Easter Egg: use a Konami Code to display some secret surprise for users – have fun, get weird, be creative!!
- Have a Clear All button that removes all of the cards from the page.
- Have a sort button that organizes the game cards by the least amount of guesses to the greatest.
- Incorporate in the UI which game has the High Score!
- Have all of Phase 1 completed and start Phase 2
- Finished UI on desktop views
- Logic for showing last guess
- Should append a card when a user wins the game
Being in the place noted above would put you on track for functionality completion. This does not mean that if you don’t meet this benchmark, you can’t do it; and it also doesn’t mean that you are guaranteed to have a passing project if you do have this much functionality. Keep in mind that the rubric weighs the quality of your code much more than your functionality.
- In your final PR, tag your assigned instructor. Also, make sure that the link to you GitHub Pages site is in the body of that PR.
Color and font spec:
Error Icon: Error Icon
- Exceptional: Application adds three or more of the extensions from phase four.
- Proficient: Application meets all of the expectations of phase three.
- Advanced Beginner: Application meets all of the expectations of phase two.
- Novice: Application meets all of the expectations of phase one.
- Exceptional: Application implements all major comp details accurately and correctly on desktop and mobile (colors, fonts, icons, spacing, alignment, etc.) with smooth transitions between screen sizes. Additional elements that have been added match the visuals established in the comps.
- Proficient: Application implements all major comp details accurately and correctly on desktop and mobile (colors, fonts, icons, spacing, alignment, etc.) with smooth transitions between screen sizes. Additional elements added generally match the visuals established in the comps, but may be slightly awkward.
- Advanced Beginner: Application implements all major comp details accurately and correctly on desktop and mobile (colors, fonts, icons, spacing, alignment, etc.). Transitions between screen sizes may not be smooth.
- Novice: Application implements all major comp details accurately and correctly on desktop only (colors, fonts, icons, spacing, alignment, etc.)
HTML - Style and Implementation
- Exceptional: Application fully implements HTML that is accessible for folks with visual disabilities. Reference this lesson plan
- Proficient: Application adds to the above with markup that is easy to read and follows across naming conventions
- Advanced Beginner: Application adds to the above with HTML that incorporates semantic HTML elements and has a simple, clean HTML structure.
- Novice: Crafts markup according to the Turing HTML style guide
CSS - Style and Implementation
- Exceptional: Application adds to the requirements of the Proficient category by using BEM, SMACCS, or another set of naming conventions for classes
- Proficient: Applications adds to the above by removing repetitive rules and blocks of code according to the DRY principle and has 3 or less media queries for responsiveness
- Advanced Beginner: Application adds organization for the whole stylesheet and within rules and has 5 or less media queries for responsiveness
- Novice: Crafts CSS according to the Turing CSS style guide
- Functions and code are well-refactored and show developer empathy
- There are no global variables aside from query selectors,
number of guesses, and
- All functions are less than 10 lines
- Uses logical operators instead of if/else statements where applicable
- Advanced Beginner:
- All parameters are used in their respective functions
- Uses function declarations over anonymous functions in event listeners
- Uses if/else statements to handle multiple paths of logic/error handling
- Novice: Crafts JS according to the Turing JS style guide