代写Pokedex，也就是Pokemon的图鉴，用户可查询Pokemon信息。
Background
This assignment is about using AJAX to fetch data in JSON format and process
it using DOM manipulation.
Overview
In this assignment, you will implement views for a Pokedex and two Pokemon
cards. (Note: You will not need to know anything about the Pokemon game
throughout this assignment, although we hope you enjoy having a more fun twist
to your homework!) A Pokedex is an encyclopedia (or album) of different
Pokemon species, representing each Pokemon as a small “sprite” image. In this
assignment, a Pokedex entry (referenced by the sprite image) will link
directly to a Pokemon card, which is a card of information for a single
Pokemon species, containing a larger image of the Pokemon, its type and
weakness information, its set of moves, health point data, and a short
description.
Each Pokemon has one of 18 types (fire, water, grass, normal, electric,
fighting, psychic, fairy, dark, bug, steel, ice, ghost, poison, flying, rock,
ground, and dragon) and one weakness type (also from this set of 18 types).
Again, you don’t need to know about the strength/weakness of different types -
this information will be provided to you as needed.
In this assignment, we will simplify things by assuming that each Pokemon has
no more than 4 moves (some have fewer, but all Pokemon have at least one
move). In addition, we assume that the complete Pokedex has 151 Pokemon (more
have been added over the game’s history, but these comprise the original set
of Pokemon species).
You will create and turn in a JS file called pokedex.js. This JS file will use
the provided pokedex.html and pokedex.css. These HTML and css files are
provided with image files in a zipped folder.
- pokedex.html: The HTML page for displaying a user’s Pokedex and two game cards
- pokedex.css: The style sheet for pokedex.html
- icons/: .jpg icons for types, weaknesses, .png icons for buffs, and .gif icon for loading animation
- images/: .jpg card images for 151 the Pokemon
- sprites/: .png sprite images for 151 the Pokemon
Data
You will use JavaScript and AJAX requests to update pokedex.html as needed.
Your program will read data from the following two web services we have
provided for the assignment.
We have provided documentation for each of these APIs in hw5-apidoc.pdf. You
will need to read through this documentation in order to use the APIs properly
for this assignment. You may assume that the data returned from both of these
web services is valid and follows the formats given.
Appearance and Behavior
Part I: Main View
The provided HTML and CSS files display the main view by default when the page
is loaded. Below is an example of this template.
For the first part of this assignment, you will populate the right container
(#pokedex-view) with all 151 Pokemon sprite icons by making an AJAX “GET”
request to pokedex.php?pokedex=all. You should also initialize your current
“found” Pokemon in your JS file (you may use a module-global array to do so)
with the three starter Pokemon: Bulbasaur, Charmander, and Squirtle.
Throughout the game, you will have the chance to collect Pokemon to add to
your collection. Below is an image of the expected output (just displaying the
#pokedexview) when the Pokedex has been populated.
All 151 imgs added to the #pokedex-view should have a class of .sprite and
have their src attribute set to the image path returned in the plain text
response. These image paths will be in the format pokemonname.png. You will
need to prepend sprites/ to the src to correctly link the corresponding sprite
image (if you are using the images locally, remember to make sure that your
unzipped image folders are in the same directory as your HTML, CSS, and JS
files). Initially, the unfound Pokemon should have the additional class
.unfound. These Pokemon sprites will show up as black shadows with this class
as opposed to the colored versions without.
For each “found” sprite added to the #pokedex-view, you will need to add an
event handler so that when the sprite is clicked, the card on the left is
populated with that Pokemon’s data. You will retrieve this data using the
pokedex.php?pokemon=parameter request, passing the clicked Pokemon’s name as
the parameter (you may find it helpful to give each sprite an id with the
Pokemon’s name). If a Pokemon with the class .unfound is clicked, nothing
should happen.
Card View
Once a found Pokemon is clicked, the card data for that Pokemon populates the
card on the left side of the page. This card has the id of #my-card. You
should use the returned JSON object from the pokedex?pokemon=parameter request
to populate the card with the Pokemon’s information, as explained below:
- The “name” value should populate the #my-card .name heading with the name of the Pokemon.
- The “images” value is a collection of three folder paths, the first being “photo” to link to the Pokemon’s photo (referenced by #mycard .pokepic), the second being “typeIcon” to link to the type icon of the Pokemon in the top-left corner (#my-card .type), and the third being the “weaknessIcon” to link to the weakness type icon of the Pokemon in the bottom-left corner (#my-card .weakness).
- The “hp”, or health point value should populate the #my-card .hp span positioned at the top-right corner of the card. You will need to append “HP” to the provided hp value, as shown in the example card image to the right.
- The “description” attribute should be used to populate the card with the Pokemon’s description. The description should be placed in the provided #my-card .info div.
- The “moves” attribute includes data about the Pokemon’s moves (between 1 and 4 moves, depending on the Pokemon). You should populate only enough move buttons in #my-card .moves for the Pokemon’s move count. If there are fewer than four moves for a Pokemon, you should set the extra buttons to have the class of .hidden so that they do not display visible on the card for that Pokemon. Any hidden moves should be below the visible moves in the .moves div. Each move button should have its innerText set to the provided move name, and its corresponding img icon set to have a src attribute of that move’s type (similar to how you did the type and weakness for the Pokemon). These type images will show to the left of the move’s name. The order of moves appended to a card does not matter, but you may find it easiest to populate them based on the order they are returned in the moves array.
Finally, you should make visible the #start-btn once a user has clicked any of
their discovered Pokemon. In other words, the button should not be visible
until the card is populated with a Pokemon’s information.
Part II: Game View
Clicking the “Choose This Pokemon” button under the Pokemon card view should
hide the #pokedex-view and show the second player’s card, #their-card,
resulting in the view similar to that below (where “your” Pokemon is chosen as
Bulbasaur, and the opponent’s Pokemon is Ditto). You should also make the
#results-container div visible at this point, which will populate the center
of the page with turn results for each move made.
To initialize the game, you will need to make a POST request to game.php with
the POST parameters of startgame=true and mypokemon=yourpokemonsname. This
request will return the initial game state, including data for your card and
data for the opponent’s card. This request will also return unique guid (game
ID) and pid (player ID) values that you should store as module-global
variables in your file. These values will be necessary to play moves during
the game. You will use this data to populate each card with image, stats, and
move data for each Pokemon. Note that you already should have the necessary
data populated in your card, so won’t necessarily need to re-populate at this
point. You will need to display your cards hidden .buffs div though for
visibility during the game, and make sure that your opponent’s card also has
their .buffs div visible (both will initially start with no buffs). Your
opponent’s card will be given as a random Pokemon (in the example output image
above, the random Pokemon is called Ditto), and should be populated with the
data similar to how you populated your card on the previous step. Note that
there is quite a bit of redundancy here, so you should factor out redundant
DOM manipulation code as much as possible.
Game Play: Each move that you make has an effect on the game state which is
handled by the server. All you need to do to keep track of the game state is
update the game with the data returned by the game.php play move POST request.
You should make this request whenever a user clicks on their Pokemon’s moves,
and remove the .hidden class from the #loading image to display a loading
animation while the request is being processed. Once the request responds with
the data successfully, this animation should become hidden again. The returned
game data includes a results array that provides the results of both Pokemon’s
moves (which moves were played and whether they were a hit or miss) and you
should display these in the #p1-turn-results and #p2-turn-results divs in the
#turn-results div in the center of the page, as shown in the above example.
There are a few changes that may result from the updated game state, each of
which you need to handle:
- Damage is dealt to your Pokemon and/or the opponent’s Pokemon: The returned game state provides data about the current health of both Pokemon. You should update the health bar (the .healthbar div on each card) to make its width a percentage of the max width, where the percentage is calculated as current-hp / hp using these values from the returned JSON. If the percentage is less than 20%, the health-bar should have a class of .low-health added to make it red (see image above for an example). When the health is greater than or equal to 20% of the total health, it should never have a .low-health class (Pokemon may have healing moves, so you should remove this class if they’re health rises above 20% after having low health).
- Buffs: Some Pokemon have moves that apply “buffs” or “debuffs” to themselves or the opponent Pokemon. In this case, you will need to add or remove divs to each card’s .buffs div. There are three stats that may have buffs applied: attack, defense, and accuracy. Attack buffs .attack are represented as red arrows, defense buffs .defense are represented as blue arrows, and accuracy buffs .accuracy are represented as green arrows. Helpful buffs are arrows pointed upwards (with the .buff class) and harmful buffs are arrows pointed downwards (with the .debuff class). The returned game state for each Pokemon has a buffs and debuffs array with the number of stats for each listed as string values (see the API documentation).
Winning/Losing: The game ends when one of the Pokemon has 0 hp points. You
should append a message in the #title as “You won!” or “You lost!” depending
on the results of the game and then remove the .hidden class to #endgame.
Below is an example output after you have won the game: The #endgame button
will appear in the center of the page when visible, just under the #title. You
should display #p1-turn-results with the data populated in #p1-move and
#p1-result, but if you were the last one to make a move (e.g., your move
causes P2’s HP to go to 0 before they make a move), #p2-result and #p2-move
will be returned as empty strings. If this is the case, you should not display
any message for P2’s move for this final turn in this case.
When clicked, the #endgame button should switch back to the Pokedex View and
then become hidden again. Whatever Pokemon you chose most-recently should
populate #my-card, in case the user wants to use that Pokemon again for a
subsequent game. #start-btn should also be re-displayed after switching to the
Pokedex view at this point, and the #results-container should also be hidden.
If you win the game and the opponent has a Pokemon that you have not found,
you may add it to your Pokedex by adding it to your collection of found
Pokemon (e.g., a module-global array of Pokemon, which started with Bulbasaur,
Charmander, and Squirtle). You should then remove the .unfound class from the
associated Pokemon and add an onclick handler to allow it to be chosen for
another game (similar to how you did with the three starter Pokemon).
Fleeing: There is a button under your card during the game labeled “Flee the
Battle”. If clicked, this should make a POST request to game.php with
parameters move=flee, guid=yourguid, and pid=yourpid, where the guid and pid
are your unique game and player id values. This request will terminate your
game and declare your opponent as the winner by automatically setting your HP
to 0. You should display a message as described in the “lose case” above when
your receive the response to playing this move. Note that your Pokemon will
flee immediately before the second player makes a move, so they will not have
any move results returned (you should not display any results for Player 2,
just your flee move results).
Implementation and Grading
Separate content (HTML), presentation (CSS), and behavior (JavaScript). Your
JavaScript code should use styles and classes from the CSS provided rather
than manually setting each style property in the JavaScript. The provided CSS
file should have all of the classes required to achieve the desired output.
Your JavaScript code should pass our JSLint tool with no errors. Your .js file
must run in strict mode by putting “use strict”; within your module. Capture
common operations as functions to keep code size and complexity from growing.
You can reduce your code size by using the this keyword in your event
handlers.
No global variables or functions are allowed. To avoid globals, use the module
pattern as taught in lecture, wrapping your code in an anonymous function
invocation. Even if you use the module pattern, limit the amount of “module-
global” variables to those that are truly necessary (we have given suggestions
about those that you will need); values should be local as much as possible.
If a particular literal value is used frequently, declare it as a module-
global “constant” variable IN_UPPER_CASE and use the constant in your code.
Do not store DOM element objects, such as those returned by
document.getElementById or document.querySelectorAll, as module-global
variables.
Your JavaScript code should follow the style guide and should have adequate
commenting. The top of your JavaScript file should have a descriptive comment
header describing the assignment, and each function and complex section of
code should be documented. Format your code similarly to the examples from
class. Properly use whitespace and indentation. Use good variable and method
names. Avoid lines of code more than 100 characters wide. For reference, our
.js file has roughly 180 lines (120 “substantive”).
