Frogger’s Revenge - University of Southern California€¦ · Frogger’s Revenge Complete Documentation University of Southern California Viterbi School of Engineering ... the

Frogger’s Revenge

Complete Documentation

University of Southern California

Viterbi School of Engineering

CSCI-201: Software Development

Fall 2015

Team 27

Rena Chen

Clara Hong

Jessica Koe

Christina Liang

Jeffrey Vaudrin-McLean

Frogger’s Revenge | Team 27

Complete Documentation 1

Table of Contents

1 INTRODUCTION …………………………………………………………………….… 3

2 PROJECT PROPOSAL ………………………………………………………………… 3

3 HIGH-LEVEL REQUIREMENTS …………………………………………………….. 3

3.1 Login Procedure and Player Features ………………………………………………...

3.2 Game Play …………………………………………………………………………….

4 TECHNICAL SPECIFICATIONS …………………………………………………..… 4

4.1 Feed Back …………………………………….………………………………………

4.1.1 Server Structure ………………………………………………………………...

4.1.2 Number of Players Connecting …………………………………………………

4.1.3 Live Updating via Player Interaction …………………………………………...

4.1.4 Data Storage and Database Access ……………………………………………..

4.1.5 Screen Clarification ……………………………………………………………. 5

4.1.6 Scope and Size of Game World ………………………………………………...

4.1.7 High Scores and Live-Updating ………………………………………………..

4.1.8 Player Animation ……………………………………………………………….

4.1.9 Wait Times and Game Initiation ………………………………………………..

4.1.10 Approval of Game Challenges ………………………………………………….

4.1.11 Avatar and Enemy Diversity and Design ……………………………………….

4.2 Overall GUI Design …………………………………………………………………..

4.2.1 Title Screen …………………………………………………………………….. 6

4.2.2 Login Screen ……………………………………………………………………

4.2.3 Register Screen …………………………………………………………………

4.2.4 Lobby Screen …………………………………………………………………... 7

4.2.5 Game Screen …………………………………………………………………....

5 DETAILED DESIGN …………………………………………………………………… 8

5.1 Algorithms ……………………………………………………………………………

5.2 GUI …………………………………………………………………………………... 9

5.2.1 Title Screen …………………………………………………………………….

5.2.2 Login Screen …………………………………………………………………...

5.2.3 Register Screen ………………………………………………………………... 10

5.2.4 Lobby Screen ………………………………………………………………….. 11

5.2.5 Game Screen …………………………………………………………………... 12

5.3 Database Schema ……………………………………………………………………. 13

5.4 Hardware Requirements ……………………………………………………………... 14

5.5 Software Requirements ……………………………………………………………… 15

5.6 Class Diagrams and Inheritance Hierarchies ………………………………………...

6 TESTING DOCUMENT ……………………………………………………………….. 16

6.1 White Box Testing …………………………………………………………………...

6.1.1 Gameplay Modifications ……………………………………………………….



6.1.2 Game/Profile Data Modification ………………………………………………. 16

6.2 Black Box Testing ……………………………………………………………………

6.2.1 Game Engine (Gameplay on the Board) ……………………………………….

6.2.2 Game Updates and Chat Box ………………………………………………….. 18

6.2.3 GUI ……………………………………………………………………………. 19

6.2.3.1 Login/Registration Abilities ……………………………………………..

6.2.3.2 Flow

6.2.3.3 Menu Functionality ……………………………………………………….. 21

6.2.4 Account Management …………………………………………………………. 22

6.2.4.1 Logged-In Player ………………………………………………………...

6.2.4.2 Guest Player ……………………………………………………………...

7 DEPLOYMENT DOCUMENT ………………………………………………………... 22

7.1 Installation and Exportation of .zip File ……………………………………………..

7.1.1 Download and Install Eclipse ………………………………………………….

7.1.2 Import Project ………………………………………………………………….

7.1.3 Run Client ……………………………………………………………………... 23

7.1.4 MySQL ………………………………………………………………………...

7.2 Start Game …………………………………………………………………………...

7.2.1 Create an Account to Play ……………………………………………………..

7.2.2 Play as Guest …………………………………………………………………..

8 FINAL ALTERATIONS ……………………………………………………………….. 23

8.1 Removed ……………………………………………………………………………..

8.2 Modified ……………………………………………………………………………... 24

8.3 Added ………………………………………………………………………………...



1 INTRODUCTION

This document is a compilation of all documentation associated with Frogger’s Revenge. It

chronicles the design and implementation phases of the game as well as any changes made to

either throughout the development process.

2 PROJECT PROPOSAL

We created a competitive creature evolution game with custom-designed creatures. This is a

multiplayer game where users compete to evolve their frog creatures the fastest. Movement of

the frog is grid-based. Each player has their own screen and is able to see the other player’s

evolution progress on the side of their screen. Evolution is based on enemy attack/consumption,

so the player’s creature will attack randomly-generated enemies to gain points for evolution.

There is an area on the screen that shows player statistics such as evolutions achieved, enemies

absorbed, food consumed, etc.

3 HIGH-LEVEL REQUIREMENTS

3.1 Login Procedure and Player Features

There will be an option to login and an option to play as a guest. Guests will not be able to

challenge other players or have their game statistics saved. There will be a high scores table

viewable by all. If a user does not have an account, they can register with a username and

password that is not already taken.

3.2 Game Play

Each game has exactly two players; there will be a screen to see which other players are

available from which you can select an opponent to challenge. Users have separate screens that

do not interact with each other directly, but actions in one player’s game will indirectly impact

the other’s game.

The player starts as a small avatar in the screen and moves around the grid via arrow keys.

Enemies of different speeds and levels (fly, dragonfly, bee, hand, and airplane) fly across the

screen from all directions, and the player can attempt to “consume” an enemy by touching it. If

the player tries to consume an asteroid that is larger than itself, the player decreases in score and

avatar size. If the player consumes an asteroid that is smaller than itself, the player’s points

increase, and the player’s avatar expands in size proportionate to the size of the consumed

asteroid.



There will be powerups that either benefit the player, or detriment the opponent. All powerups,

regardless of effect, will add points. Powerups will include features such as increased speed,

sending highest level enemy to the opponent’s screen, temporary shield/invincibility, projectile

attack ability, teleportation portals, reversed screens, and a screen reset.

Players win either by reaching the maximum evolution first or having the opponent quit. A timer

keeps track of how long the players take to win a game. Note that a player winning by evolution

does not necessarily mean that the player has the higher score.

4 TECHNICAL SPECIFICATIONS

4.1 Feedback

In response to concerns regarding the scope of the game, we have addressed a number of topics

to ensure our technical specifications are feasible.

4.1.1 Server Structure

Every client will connect to one central server. All players will be able to see one another

in a lobby.

4.1.2 Number of Players Connecting

To the overall application, yes, to one another to play, no. Each game session will be 1 v

1. See description of lobby below.

4.1.3 Live Updating via Player Interaction

While each player’s characters will remain on their own screen, each character will be

represented by an icon on the other’s player screen that will be updated dependent upon

evolution level and buff/debuff status. Also, players will be able to interact with items on

their own screen that will have an impact on their opponents’ characters and gameboard

(described in the Game Screen description below).

4.1.4 Data Storage and Database Access

When a player logs in, their info will be uploaded by the server. After every game a

player’s info will be updated in the database by the server. If a player wishes to view a

profile of another player, the server will provide the information directly.



4.1.5 Screen Clarification

There will be four main screens for starting, login, lobby, and game play. There will also

be popups/separate frames for user info, registering, rules, and end game.

4.1.6 Scope and Size of Game World

The world is a finite size. Specifically, player characters will move around an 8x8 grid

filled with lily pads (the player is restricted to this grid).

4.1.7 High Scores and Live-Updating

High scores will live update every time a game is finished playing. Accessing the top

scores will provide the most current look at score standings.

4.1.8 Player Animation

The player’s characters and enemies will be animated. A player will opt to move, then

they will lose control of their character while it moves from one grid location to the next,

allowing for an appropriate movement animation to occur.

4.1.9 Wait Times and Game Initiation

Guests will wait for another player to challenge them. Registered players can challenge

other players or accept challenges. Once a player is challenged, there will be a thirty

second time limit for them to accept or decline.

4.1.10 Approval of Game Challenges

The person being challenged will have to accept before the game can begin, this is

detailed more explicitly below in our technical spec.

4.1.11 Avatar and Enemy Diversity and Design

The players’ creatures are all identical, but when they evolve, they gain certain perks, like

being able to eat larger enemies. Enemies all have the same functionality, but they can

only eat player characters that are lower than a certain level.

4.2 Overall GUI Design

The game will be comprised of several screens with varying purpose and functionality. A menu

will exist at the top of all screens and will contain 5 items: Rules, Top Scores, End Game,



Logout, and Quit. Some of these menu items will be disabled within certain screens (noted in

specific screen descriptions). Rules pops-up a non-modal window that describes the rules and

purpose of the game. Top Scores pops-up a non-modal table that displays the top scores of all

time. End Game ends the current game, causing the player who ended to lose the game

(crediting a win to their opponent automatically), and returns both players to the Lobby Screen.

Logout logs a player out (registered or guest) and returns them to the Login Screen.

4.2.1 Title Screen

When the user opens the program, they will see a title screen. The title screen will have

the title of the game, Frogger’s Revenge, fun graphics, a Start button, as well as the

Menu. Note: only Quit, Rules, and Top Scores will be selectable - End Game and

Logout will not. Clicking the Start button will reveal the login screen, replacing the Title

Screen.

4.2.2 Login Screen

On this screen, the user can either log in, to register, or to play as a guest. If registering,

the user will see a modal pop-up window that will allow them to register a name and

password (see Register Screen below). If logging in, there will be a space to input the

username and a space to input a password. The user will be verified via the server, which

will communicate with the database and retrieve the player’s information. If the user

enters a name that does has not been registered, the wrong password, or does not fill in

one of the fields, a pop-up will warn the user of their error. Once the user has chosen to

play as a guest or successfully logs in, the screen will be replaced by the Lobby Screen.

Note: the Login Screen has the menu, but only Quit, Rules, and Top Scores will be

selectable - End Game and Logout will not.

4.2.3 Register Screen

When the player attempts to register from the Login Screen, a modal dialog will pop up.

In this window, there will be a text field to input a username and a text field to input a

password, as well as a button to create their profile/register. If the user does not fill in all

fields or the name is taken, the user will be informed of their error and the fields will be

wiped. Once the Create button is pushed and confirms success, an option pane

notification will pop up to tell the user to log in. The Register Screen will close, and the

user will again be able to interact with the Login Screen.



4.2.4 Lobby Screen

This screen will display the user’s profile with their stats (like shortest time, evolutions

achieved, games played, highest score, etc.) as well as a list of available players (players

who have connected into the server - both registered and guests). The player will be able

to select one and only one other player at a time from a scrollable list. Each player will

either be considered available, challenged, or playing. A player will be removed from the

list if they are challenged or if they challenge another player. There will be two buttons:

View (to view the selected player’s profile) and Challenge (to challenge the selected

player). Guests will not be able to challenge other players; they can only be challenged. If

a player selects another player from the available list and chooses to view them, a non-

modal window will pop up displaying the specific user’s stats (similar to the fields

displayed by the current user about themselves in this window). If another player

challenges the user, both players will be removed from the Available Players list. A

modal window will pop up to say they have been challenged and ask if they want to

accept or reject the challenge. The challenged player will have thirty seconds to respond.

If the challenge is declined or if time is up, both players will reappear in the available

players list. If the challenge is accepted, both players will be taken to their individual

game screens to play one another (more on this in the Game Screen description). There

will be a chat window to type and communicate with all the players that are in the lobby.

Note: the Lobby Screen has the menu, and all the menu items (mentioned in Overall Gui

Description) except for End Game will be selectable.

4.2.5 Game Screen

The main portion, left/bottom aligned will be the actual game panel, which has a set size

and an 8x8 grid layout. Each player has a separate game screen, but they can indirectly

affect the other player’s screen (ex. if you eat something on your screen, it will make the

opponent’s character slower).

The player’s character will only be able to move square by square. Enemies will move in

a continuous motion from one side of the screen to another (left/right, top/bottom). When

an enemy that is lower level than the character is hit, it is consumed and contributes to the

character’s score and evolution. If the character is hit by a higher level enemy, they will

lose a life star. Every hit delays the character’s ability to move by one second and allows

a moment of invincibility. When all life stars are depleted, the player’s character will

devolve, or level down.

On top of the game panel will be stats (Score, Health, #Eaten, Evolution level), a timer,

and an End Game button for those who want to rage-quit. The player who ends a game

prematurely will automatically lose, but all stats will still be saved. To the right of the



game panel will be a label showing the player and the opponent, and then a chat box

below. Updates to the game will also appear in the chat box indicating player status

changes or evolution advances. When the game ends (a player completes the ultimate

evolution or a player exits the game), there will be a popup declaring the end of the game

along with both players’ scores. Once a player closes the dialog, they will be returned to

the lobby. If the player is registered, their stats will be saved. If the player is a guest, all

progress will be lost. Note: the Game Screen has the menu, and all the menu items

(mentioned in Overall Gui Description) will be selectable. Again, Quit, Logout, and End

Game all end the game and forfeit the win to the opposing player (as well as execute

their respective window change/close).

5 DETAILED DESIGN

5.1 Algorithms

Login

- password check

- creating new user

Lobby Logic

- user availability

- opponent selection

Game Physics

- enemy creation

- enemy movement

- player movements via key-bound input

- player orientation

Abilities of Enemies

- attack player

Effects of Items

- increase player speed

- generate new enemies for player

- increase points obtained by player



5.2 GUI

5.2.1 Title Screen

5.2.2 Login Screen



5.2.3 Register Screen



5.2.4 Lobby Screen



5.2.5 Game Screen



5.3 Database Schema

Account data:

- username

- high_score

- high_nums_eat

- number_games

- recent_opponent

- available

GameManager data:

- player1_username

- player1_score

- player1_avatar

- player1_health

- player1_evol

- player1_speed

- player1_dir

- player1_node

- player2_username

- player2_score

- player2_avatar

- player2_health



- player2_evol

- player2_speed

- player2_dir

- player2_node

- timer

- game_map_layout

Node data:

- item

- player

- boolean lilypad

- positionX

- positionY

- neighbor_up

- neighbor_down

- neighbor_left

- neighbor_right

Enemy data:

- node_on

- enemy_dir

- enemy_speed

- enemy_image

- enemy_level

Item data:

- item_image

GameBoard data:

- layout_type

- player1

- player2

Server data:

- vector of available players

5.4 Hardware Requirements

Windows:

● Windows 8 (Desktop)

● Windows 7

● Windows Vista SP2

● RAM: 128MB

● Disk Space: Recommended 512MB

● Processor: Minimum Pentium 2 266MHz processor

Mac OS X:

● Intel-based Mac running Mac OS X 10.8.3+, 10.9+



Linux:

● Oracle Linux 5.5+

● Oracle Linux 6.x (32-bit), 6.x (64-bit)

● Oracle Linux 7.x (64-bit)

● Red Hat Enterprise Linux 5.5+ (32-bit), 6.x (64-bit)

● Ubuntu Linux 12.04 LTS, 13.x

5.5 Software Requirements

● Java 8

● Eclipse IDE for Java EE Developers (Luna/Mars)

5.6 Class Diagrams and Inheritance Hierarchies



6 TESTING DOCUMENT

6.1 White Box Testing

6.1.1 Gameplay Modification

- TEST CASE: Try to send the effects of hitting an object to another player by typing a

string into the chat window. (The threads that update the chat are the same threads that

send signals to the main server to update the respective player game boards)

- EXPECTED RESULT: The effect is not seen in the other player’s screen

- TEST CASE: Try to slow speed of enemies on board by typing a string into the chat

window

- EXPECTED RESULT: No speed change

- TEST CASE: Use keystrokes (arrow keys) while focused in game

- EXPECTED RESULT: moves frog, chat window unaffected

- TEST CASE: Use keystrokes (arrow keys) while focused in chatbox

- EXPECTED RESULT: frog does not move, cursor moves along text (if text is

entered)

6.1.2 Game/Profile Data Modification

- TEST CASE: Top scores table is not mutable. Try to edit/erase top scores by selecting

them from the popup.

- EXPECTED RESULT: cannot edit - table is not mutable.

- TEST CASE: Player information in lobby is not mutable. Try to edit/erase information by

attempting to edit the lobby screen.

- EXPECTED RESULT: Cannot edit - player info is not mutable.

- TEST CASE: Player profile popup is not mutable. Try to edit/erase information by

attempting to edit the popup.

- EXPECTED RESULT: Cannot edit - player info is not mutable

- TEST CASE: Hard code specific board layout (lily pad positions) to load up (unit testing

- checking functions used to build board)

- EXPECTED RESULT: Lily pads show up in GUI as intended with specified

layout

6.2 Black Box Testing

6.2.1 Game Engine (Gameplay on the Board)

- TEST CASE: Enter the game screen



- EXPECTED RESULT: The timer should begin at 0 and increment every second;

player icons should begin at zeroeth evolution; health stars should be at five; #

enemies eaten should be at 0; score should be at 0.

- TEST CASE: Player’s frog should stay onscreen during the gameplay

- EXPECTED RESULT: Player’s frog cannot move offscreen in any direction

- TEST CASE: Move the frog in different directions by arrow keys

- EXPECTED RESULT: Frog’s image should face corresponding direction and be

animated with a jump.

- TEST CASE: Player’s frog can only move on lilypads during gameplay, can’t move onto

water section of game board

- EXPECTED RESULT: Player’s frog cannot move on areas without lilypads

- TEST CASE: If an enemy which is weaker than the player hits the player’s frog, the

enemy disappears from the board

- EXPECTED RESULT: Enemy is no longer seen after crossing paths with frog,

and player score increases

- TEST CASE: If an enemy does not cross paths with the player’s frog by the time it

reaches the edge of the board, the enemy will disappear in a poof

- EXPECTED RESULT: The enemy poofs offscreen and does not reappear (new

enemies will be newly-generated)

- TEST CASE: An enemy is stronger than a frog and hits a frog

- EXPECTED RESULT: enemy continues moving like normal, and player loses a

star point.

- TEST CASE: An item is spawned

- EXPECTED RESULT: The item will appear on a lilypad, not on water

- TEST CASE: A player gets an item

- EXPECTED RESULT: Item disappears when player hops onto lilypad with item

- TEST CASE: player gets a shield item

- EXPECTED RESULT: a player cannot be hurt by bugs larger than it for 7

seconds and a blue circle appears over the fr

- TEST CASE: player eats a miller beer can

- EXPECTED RESULT: highest level enemy bugs get sent to opponents screen.

- TEST CASE: player eats 5-hour energy can

- EXPECTED RESULT: players speed increases x2 for 7 seconds.

- TEST CASE: player eats bomb

- EXPECTED RESULT: all enemies on screen disappear

- TEST CASE: player eats rainbow star

- EXPECTED RESULT: player can eat any bug for 7 seconds

- TEST CASE: If a dragonfly enemy crosses over a tile containing an item

- EXPECTED RESULT: item will disappear from the screen



- TEST CASE: If a player of the zeroeth evolution eats enough enemies (accumulates 20+

evo points from consuming enemies), the image of the player will change to first

evolution state

- EXPECTED RESULT: image of player updates on their game board, in their

upper right screen, and on their opponent’s screen, life stars reset to 5

- TEST CASE: If a player of the first evolution eats enough enemies (accumulates 40+ evo

points from consuming enemies), the image of the player will change to second evolution

state



- TEST CASE: If a player of the second evolution eats enough enemies (accumulates 60+

evo points from consuming enemies), the image of the player will change to third

evolution state



- TEST CASE: If a player of the third evolution eats enough enemies (accumulates 80+

evo points from consuming enemies), the image of the player will change to fourth

evolution state and end the game


upper right screen, and on their opponent’s screen, player gets win message and

opponent gets lose message. Both players confirm and return to lobby

- TEST CASE: A player gets hit by an enemy.

- EXPECTED RESULT: has one second of invincibility when it can’t get hurt, or

move.

- TEST CASE: A player loses all their stars from being hit by enemies

- EXPECTED RESULT: the player graphic will change to previous evolved state

graphic.

- TEST CASE: A player ends the game and the high scores gets updated accordingly

- EXPECTED RESULT: The high scores table automatically updates and sorts.

The player’s username is automatically inserted into the table along with their

score without prompting the player.

- TEST CASE: A player is in zeroeth state and they lose all their stars

- EXPECTED RESULT: the player stays the same

- TEST CASE: An enemy is spawned

- If the enemy is spawned on the left, it will go right; if spawned on right, will go

left; if spawned on top of the screen, will go down, if spawned at the bottom, will

go up.

6.2.2 Game Updates and Chat Box

- TEST CASE: Player eats an item



- EXPECTED RESULT: A message will appear in chat box corresponding to what

item is eaten and/or its effects.

- TEST CASE: Player levels down

- EXPECTED RESULT: A message will appear in chat box saying that player has

devolved.

- TEST CASE: Player types in message box

- EXPECTED RESULT: A message will appear in chat box along with username

in front.

6.2.3 GUI

6.2.3.1 Login/Registration Abilities

- TEST CASE: Attempt to login with username that does not exist in database.

- EXPECTED RESULT: User cannot log in, popup informs user of mistake.

- TEST CASE: Attempt to login without entering a password.

- EXPECTED RESULT: Cannot login, popup informs user of lack of password.

- TEST CASE: Attempt to login with wrong password.

- EXPECTED RESULT: Cannot login, popup informs user of incorrect password.

- TEST CASE: Attempt to login with non-existing username

- EXPECTED RESULT: cannot login, popup informs user of non-existent

username

- TEST CASE: Attempt to register with username already existing in database.

- EXPECTED RESULT: Cannot register, popup informs user that name is already

taken.

- TEST CASE: Attempt to register but confirm password input does not match with

password input.

- EXPECTED RESULT: Cannot register, popup informs user that passwords do

not match

- TEST CASE: login as guest

- EXPECTED RESULT: username is “username” + final 8 digits of current system

time in milliseconds.

6.2.3.2 Flow

- TEST CASE: Clicking the “Start” button on the Start screen should take player to the

Login screen.

- EXPECTED RESULT: Start screen should only go to Login screen.

- TEST CASE: Clicking the “Start” to play as a guest should take player to the Lobby

screen.



- EXPECTED RESULT: Player should directly go to Lobby screen without

entering any other information.

- TEST CASE: Clicking the “Register” button should take the player to a new screen to

create an account.

- EXPECTED RESULT: Player should be taken to account creation screen.

- TEST CASE: Clicking “Login” button with valid username and password should take

player to the Lobby screen.

- EXPECTED RESULT: Player should be taken to Lobby screen.

- TEST CASE: If a player has selected a player in the available player list, and that player

suddenly disappears from the list,

- EXPECTED RESULT: nothing will be selected.

- TEST CASE: A player chats from the lobby

- EXPECTED RESULT: username appears and chat shows message to everyone in

lobby

- TEST CASE: A player chats in a game

- EXPECTED RESULT: player’s username and text shows up in chat box for only

play and their opponent

- TEST CASE: If a player is viewing someone else’s profile and that person becomes

unavailable because they have entered a game

- EXPECTED RESULT: Profile popup stays, nothing happens

- TEST CASE: Clicking on View Profile after selecting a player in the Lobby screen.

- EXPECTED RESULT: Open a new window with player profile information

inside. If a window is already open, a second window will appear.

- TEST CASE: Clicking on Challenge after selecting a player.

- EXPECTED RESULT: the selected player and challenging player will disappear

from available players list for twenty seconds, or until selected player

accepts/declines challenge. The selected player will see a dialog box with the

challenging player’s name, an explanation of what is happening, and the option to

accept or decline.

- TEST CASE: A challenged player exits the dialog box without accepting challenge.

- EXPECTED RESULT: The challenge will be declined and both users will

reappear on available players list.

- TEST CASE: After a player has accepted a challenge from another player, both players

should be taken to their respective Game screens.

- EXPECTED RESULT: Both players should be taken to their game screens.

- TEST CASE: After both players finish a game and have been notified of their win/loss,

they are taken back to the Lobby screen.

- EXPECTED RESULT: Both players are taken to their Lobby screen.

- TEST CASE: A player presses end game button in game before the game is over.



- EXPECTED RESULT: The player who presses end game button first before the

game ends will lose the game automatically; the other player will be notified of

their win; both will be taken back to lobby.

- TEST CASE: A player quits the entire application during a game.

- EXPECTED RESULT: The player will be logged out; the second player will be

notified of the quit, win the game, and be returned to lobby.

- TEST CASE: A player returns to the lobby after a game ends.

- EXPECTED RESULT: Player name will reappear on available players list for all

users.

- TEST CASE: a player loses

- EXPECTED RESULT: at the end of the game a popup comes up with words “you

lose” on the losing player’s screen

- TEST CASE: a player wins

- EXPECTED RESULT: at the end of the game a popup comes up saying “ you

win” on the winning player’s screen

6.2.3.3 Menu Functionality

- TEST CASE: select ‘menu’ while on start screen

- EXPECTED RESULT: only rules, top scores and quit are clickable

- TEST CASE: select ‘menu’ while on login screen

- EXPECTED RESULT: only rules, top scores and quit are clickable

- TEST CASE: select ‘menu’ while on lobby screen

- EXPECTED RESULT: rules, top scores logout, and quit are clickable

- TEST CASE: select ‘menu’ while on game screen

- EXPECTED RESULT: only rules, top scores and endgame are clickable

- TEST CASE: click ‘Rules’ from ‘Menu’ item in menu bar

- EXPECTED RESULT: non-modal popup explaining the rules is shown

- TEST CASE: click ‘Top Scores’ from ‘Menu’ item in menu bar

- EXPECTED RESULT: non-modal popup displaying top scores is shown

- TEST CASE: click ‘End Game’ from ‘Menu’ item in menu bar

- EXPECTED RESULT: game ends and ‘this’ player loses, opponent player wins

automatically, both players returned to lobby

- TEST CASE: click ‘Log Out’ from ‘Menu’ item in menu bar

- EXPECTED RESULT: Player is logged out and returned to login screen, player

disappears from list in lobby

- TEST CASE: click ‘Exit’ from ‘Menu’ item in menu bar while on start or login screen

- EXPECTED RESULT: the program closes

- TEST CASE: click ‘Exit’ from ‘Menu’ item in menu bar while on the lobby screen

- EXPECTED RESULT: the player is logged out (removed from the list) and the

program closes



6.2.4 Account Management

6.2.4.1 Logged-In Player

- TEST CASE: Player enters lobby screen after the login screen.

- EXPECTED RESULT: Player stats (games won, games lost, total enemies

consumed, total number items consumed, highest score) will be displayed,

challenge button is enabled

- TEST CASE: Player returns to lobby after end of a game.

- EXPECTED RESULT: Player stats (games won, games lost, total enemies

consumed, total number items consumed, highest score) will have updated to

reflect the game results.

6.2.4.2 Guest Player

- TEST CASE: Player enters lobby screen after the login screen.

- EXPECTED RESULT: Player stats are blank because nothing is saved as a guest.

Challenge button is disabled (guests can’t challenge other players).

- TEST CASE: Player returns to lobby after end of a game.

- EXPECTED RESULT: Player stats are blank because nothing is saved as a guest.

Challenge button is disabled because guests can’t challenge other players.

7 DEPLOYMENT DOCUMENT

7.1 Installation and Exportation of .zip File

7.1.1 Download and Install Eclipse

Download and install Eclipse and the latest versions of jdk(Mars) and jre (1.8).

Download from: https://www.eclipse.org/downloads/

7.1.2 Import Project

To deploy this application within Eclipse, import the FroggersRevenge201Project.zip file

into Eclipse. This should generate a project called FroggersRevenge201Project with src

and assets directories. The src directory contains the game, gameclient, library, and

networking packages. The assets directory contains images, constants, and other various

resources associated with the game.

https://www.eclipse.org/downloads/



7.1.3 Run Client

To execute Frogger’s Revenge, run networking.FroggerClient.java through Eclipse

7.1.4 MySQL

To store user data and other such data we will be using MySQL, but this will be launched

and handled by the server.

NOTE: The presumption is that we will have an instance of the server running with the IP

address and port coded into the client. We will need to either work out ahead of time who will be

provided a computer for the server and code accordingly or find some other organizational

method to handle establishing this server-client relationship.

7.2 Start Game

7.2.1 Create an Account to Play

Users may create an account to play the game. With an account, a user can send and

accept/turn down challenges from other players. They can also contribute to lobby and

game chats.

To create an account, click “create account” in the login page, and enter password and

username, then go back to the previous window and sign in.

After that, click on a user in the lobby and send challenge or wait until someone

challenges you.

7.2.2 Play as Guest

Users may play without creating an account. While playing the game as a guest, the user

cannot challenge other players but can accept/turn down challenges from other players.

They can also contribute to lobby and game chats.

To start a game, wait for a challenge request once in the lobby.

8 FINAL ALTERATIONS

8.1 Removed

● Having the effects of enemies and items changing frog movement speed.



● Multiple gameboard GUI layout choices; there will only be one gameboard GUI layout.

● Some of the previously brainstormed effects on players (reversed screen, screen reset,

teleportation portals, projectile attack).

● Frog class, since while playing the game the player’s updates and info will happen/be

held in GameBoard.

8.2 Modified

● Fluid player movement is replaced by movement from grid space to grid space (to make

it easier to manage backend methods/data).

● The airplane is being replaced by a drone.

● 10x10 board is now 8x8.

● Enemy is only stun the frog, not eat it.

● Players can’t play by themselves, must challenge or be challenged by an opponent.

● Instead of decreasing player image size after being hit by an enemy, the player image will

change to indicate it has been hit before reverting to the regular image for that level

● GameItem doesn’t store image, only stores the string and the node it is on.

● GameBoard only stores the data for one player; the opponent’s data will be passed in

through a thread.

● Server has a vector of users available in the lobby, a vector of connections to the server, a

player information map, a thread to user information map, an opponent-tracking map.

● GameManager does not store player data; that is now happening in the GameBoard class.

GameManager handles general game functions while GameBoard handles player

logic/functions and data.

● Constants class in library package stores panel titles and image icons for the game. The

obstacle objects which will send commands to other players is a NEW communication

package.

● GameItem is an abstract class which is extended by specific classes (Candy, Cake,

FiveHourEnergy) because each item has a different effect on the player/game.

8.3 Added

● A website about the game

Documents

Frogger’s Revenge - University of Southern California€¦ · Frogger’s Revenge Complete Documentation University of Southern California Viterbi School of Engineering ... the