# DESIGN_PLAN

## Names
Daniela Bocanegra ([e-mail])
Kyra Chan ([e-mail])
Erik Gregorio ([e-mail])
Jackson McNabb ([e-mail])
Thomas Quintanilla ([e-mail])

## Design

<insert creatively image here></insert>

### Introduction:

Being a large, dynamic project that should contain many versions of different games, we are prioritizing our design around the overlying axiom of being as generic as possible. Generic player and object interfaces will be able to implement any creative structures, sprites, players, or environments to expand imaginable play and scale up to any game or version. This is complemented by generic data managment and engine classes that allow for the manipulation, saving, and loading of any of these objects which work in tandem with streamlined frontend and backend API's that can interact with any implemenation of the above classes. Above, an illustration depicts this process through these classes, interfaces, and methods.

### Overview:

//TODO: describe specific modules you intend to create, their purpose, and how they collaborate with one another, including a description of the interaction with the API's.

View Package:
* ViewManager: only class to know the primaryStage, will be in charge of switching between different scenes
* StyleView: abstract class that handles CSS styling; will have a method that sets the default CSS file used from XML preferences file and another method called attachCSS() that allows any component to be linked to a CSS file
* ViewScene: abstract class for all scenes within the View package; inherits StyleView to allow all components in scenes to be attached to CSS files
* HomeScene: main home screen that appears when program is launched (will be hard coded to allow for users to log in or play as guest); inherits ViewScene
* Logging in will link to the LogInScene
* Playing as a guest will link to the GameCenterScene for a default Guest user
* LogInScene: main log in screen for users to input username and password; will need to read from an XML file to check is username and password is a valid user; inherits ViewScene
* This will link to the GameCenterScene if user is valid
* This will throw an ErrorBox if user is invalid
* EditProfileScene: screen for users to edit their profile, including changing username, password, profile image, and age; this will update and edit the XML file(s) that keep track of all users; inherits ViewScene
* After saving changes to profile, will return back to GameCenterScene
* GameCenterScene: screen for users to either log out, change profile, or pick any game from available games in center; inherits ViewScene
* Will need to read from an XML file to list out available games
* Use reflection to create grid of games
* For playing as a guest, the GameCenterScene will be logged in as Guest user, but it will not allow the user to "Edit Profile"
* GameScene: screen for main game area; inherits ViewScene
* Use reflection for majority of the scene
* Contains game actions such as pause, resume, save game, load game, save preferences, load preferences
* Displays game status such as lives, score, kills, powerups, etc.
* Allows for user customization such as setting animation speed, changing background image, player character, powerups (and weapons) available, etc.
* Allows user to upgrade to premium
* Displays game rules / keys
* Displays high scores for that game specifically
* PlayerFrontend
* Hold

Controller Package
* Frontend API:
* Interface of methods used by frontend
* Used to update front end objects based on rules defined by game engine and states from XML saver/loader
* Backend API:
* Interface of methods used by backend
* Used to send parameters and other information to backend so that the information can be updated.
* Controller:
* Constructs the two interfaces and serves as the "bridge" between frontend and backend.

Engine Package:
* Engine Object: abstract engine object defining basic physics of linear movement
* Character: abstract object that defines non-linear movement for characters (i.e. jumping, running)
* EnvironmentObject:
* Can't be controlled by user input
* This would be extended to implement powerups
* Player:
* Extends Character
* To be controlled by user input so provide basic movement methods
* Enemy
* Extends Character
* Moves without any user input
* Path only affected by player interacting with object
Data management package:

* XMLWriter: handles the translation of inputted data to a readable XML file to be loaded using XMLParser (below). This will handle **both** the handling of user accounts and passwords as well as user preferences and game-specific information, like high scores or the current level.
* XMLParser: reads XML file in the data folder or inputted and translates to load player preferences, high scores, game status, etc. Also, methods in this class handle the reading of the username-password maps.
* ParsingExceptions (many); throw UI alert boxes when manually inputted XML files don’t have correct tags or thrown default options when data inputted is not correct.

### Design Details:

//TODO: Describe how each module's API handles specific features given in the assignment specification, what resources it might use, how it collaborates with other modules, and how each could be extended to include additional requirements (from the assignment specification). Last, Justify the decision to create each module with respect to the design's key goals, principles, and abstractions.

* High Scores:
* A high score for each game will be linked to a user profile with a corresponding ID number. This will be displayed in the GameScene class.
* This high score will be read from an XML file, and will be updated after every game (if necessary).
* Due to the ID number being encapsulated within the back end, even if the user changes its username, the same user profile will still be kept, and high scores should not be deleted.
* Every time the game is launched, high scores should be kept in the XML file if tied to a specific user, so it is not deleted after the program is closed. If the user chooses to play as guest, then high scores need to be cleared after every run.
* Backend will keep track of a temporary score throughout the game and will pas score as an unmodifiable value to be written into the XML file.
* When XMLWriter called, it will translate to parsed int in documentBuilder to be read later. It will be in the same document that contains player usernames-passwords, because it is linked to username.
* Dark Mode:
* This will involve the use of at least three different CSS files: one that manages all non-color related data, one that manages light-mode color data, and one that manages dark-mode color data.
* An initial preference of light/dark-mode will be provided in the starting XML file; there will be a method in StyleView that can set the default CSS file being used.
* To change between both modes in the actual GameScene, there will be a method that switches the mode, which just changes the CSS styling file in use.
* Save Games:
* The GameScene class will handle the front end aspect of saving a game, such that users can click on a button to save its current status within the game.
* This is linked to an XML writer that then takes in all of the input data and saves it as an XML file.
* Backend will pass unmodifiable data strucutures to provide the necessary information defining the game at the specified point, including player position, player powerups, scores, and environment objects. If appropriate, checkpoints within the game to facilitate this process.
* XMLWriter will deconstruct these structures to ints and strings to be directly written inline on a constructed XML file. Default values will be supplied in case of failure.

* Load Games:
* The GameScene class will handle the front end aspect of loading a game, which opens a FileChooser for the user to select an XML file. This then updates the game status to allow the user to start where they last left off.
* This is linked to an XML reader that parses through the input data.
* Backend will provide multiple constructors to be able to intialiaze game object with various conditions
* Using the same tag syntax from load games, XMLParser will parse and reconstruct information from written XML file to extract current stage information. This will be returned directly to the Backend to be used during game construction. Will also indicate if incorrect XML files/data are loaded and defaults are thrown instead of inputted.

* Preferences:
* There will be a default preference that is set to be associated with each user, given from an XML file.
* An XML reader will parse through preferences.
* The GameScene class will then update accordingly. If the user would like to update preferences while in the GameScene, they can also reupload a new preferences file by clicking on a button and selecting another XML file from the FileChooser, which would call the XML reader class again to parse through the new data.
* Similarly, if preferences are changed in-game, once the user saves preferences, it overrides the old XML file to update new preferences. These files are user-specific in a one-to-one map.

* Multiple Games At Once:

* Dynamic Game Rules:
* If the user wants to change game rules, such as the powerups available, the user can interact with GUI components in GameScene. Depending on the game rule, this can either update the current game being played in real time or may force the user to restart the game (e.g. if the user changed initial configuration).
* This would then update or write a new XML file using XML writer. If the game is restarted, the XML reader may also need to be called to parse through the updated XML file again.
* On backend, objects will have disable/enable methods to be able to dynamically change features.
* Specific tags will be added as development accelerates that allow for the integration of different types of game data. This will eventually be divided per game / version as new rules become available to be customized per game.

* Player Profiles:
* The user can choose to log in or play as guest on the HomeScene, which will then lead the user to the LogInScene to enter their username and password, or directly to the GameCenterScene with a "log in" of a Guest user profile.
* When the user types in their username and password, the XML reader will have to check an XML file that contains all users, and see if any corresponding ID number is mapped to both of the username and password. If so, then the user is considered valid, and the player can enter the GameCenterScene. If not, an error should be thrown.
* Player profiles will be organized in some sort of map with an ID as the key. The ID should have a corresponding username, password, and list of game high scores, where the index of the high score indicates which game the high score was played in. If a game was not yet played, the default high score should be 0.
* A single XML file exits per user entity. If username inputted is not recognized in the file name, UI alert box is thrown, as discussed above. If found, we are able to parse through any of the player profile data, including ID and password to check if correct. A return method is used in button function to see if the password is correct or not from XMLparser.
* Game Data Producer and Viewer:
* Every run of the game can be "recorded" if the order of actions is kept in some sort of data structure. To reduce the amount of data that needs to be saved, the XML file may only want to save the run, if a new high score had been created. These actions can then be replayed as the user plays a new game for the user to compare itself to its previous highscore.
* This suggests the following assumption: that the game being played has the same configuration, otherwise the old run may not match the current run's game configuration.
* Backend needs to implement an "autopilot" player that can be given an order of actions and execute it. Additionally, it must run in the background of an actual user playing the game.
* A large XML file will reduce game time and status to “checkpoints.” Which will be coded by XMLWriter and will reduce runs down to a series of interpretable Strings and integers to then be loaded up by XMLParser to reconstruct an indexed run.

* Dynamic Game Content:
* In the GameScene class, there will be a button option that allows users to "Upgrade to Premium," which will unlock certain features, such as power ups, levels, etc. The button should reference a method from the back-end side that then updates the game settings and configuration.
* Backend must have the premium feautres implemented but not enabled. The backend external API must include a method for frontend to easily enable these features, such as when a button is pressed.
* Simply, XMLWriter will record a simple status in the form of a string or int if premium features are accessible for a certain user. This is user-specific.

### Example games:

We discussed exploring the implementation of the following games: Jetpack Joyride, Super Mario Bros, Cuphead, Mega Man, and Doodle Jump. Each of these games offer the user a "battle" against three different environments/enemies. Super Mario Bros, Cuphead, and Mega Man are scalable battles against enemies which will try to defeat you, Jetpack Joyride is a battle against the environment, as objects come hurdling at you over time, while Doodle Jump is truly a battle of skill, where the environment becomes harder to navigate over time. Note here that these games can be further separated depending on if the

Other games ton consider for implementation:
Flappy Bird
Ninja Jump

### Design Considerations:

We discussed wanting to implement these games using a step function because of the need to animate the screen for a set number of frames per second. This is advantageous because of the need to scan for intersections constantly for enviroment-changing games like Jetpack Joyride.

We also discussed the need for a strong FrontEndAPI that contains all imageview properties, so that Javafx can be compartamentalized into one class.

Lastly, we discussed the need to have an XMLWriter and Parser that is to be extended in multiple ways depending on what information is passed. Each class that contains savable information, we will import these super classes, then in the XML packages, extensions on the base will implement these writers to specific XML documents.

## User Interface Wireframe

Link to InVision Prototype: https://kyrachan343459.invisionapp.com/overview/COVID-CS308-Final-ck8gmcgsl055b017ha61w0g72/screens?v=A2Raxp9fADdCyAcSFbh0RA%3D%3D&linkshare=urlcopied

Instructions:
* Start at the Home Screen, then navigate through the other screens from there.
* The player can either log in as a user, or choose to play as a guest.
* Once the player reaches the game center screen, the player can either choose to edit profile (if logged in), log out, or pick any game they want to play.
* Within the game scene, the player can return back to the game center to either play a new game again or log out.