# Design.md

# OOGA Design Final
### Names
Jackson McNabb (jdm109)
Thomas Quintanilla (tq11)
Daniela Bocanegra (dib4)
Erik Gregorio (eg158)
Kyra Chan (ktc22)

## Team Roles and Responsibilities

* Jackson: Handled all data/user management and XML file loading, parsing, and manipulation. Also worked with front end for hiding text/button imlpementation and backend for game parsing, level construction and controller design.
* Thomas: Constructed the Controller of the project, handling object generation and bindings. Created property files for game construction for the Controller to use. Also managed the git repository and led daily standups with the team.
* Kyra: In charge of all View-related classes, created View package structure and hierarchy (including ViewManager and all scenes), handled front-end components and UI, such as the Button package; created sample CSS files and properties files.
* Daniela: Worked on backend, specifically, implemented hitboxes and several game components, such as main player variations, enemies, and environemnt objects.
* Erik: Worked on backend, specifically, implemented most superclasses that defined the way environment objects and characters in the game as well as core movement.

## Design goals
The goal of our design was to create a logical workflow and separate the different types of work being done. Our main objective was to construct the project in a way that allowed for a theoretical abstract implementation of any scroller-type game.

#### What Features are Easy to Add
* View Package:
* Adding new color themes, e.g. "Dark Mode", with new CSS files
* Changing the language of the UI text, but using a different properties file with the same String keys
* Adding additional buttons on the front-end, if the specific format is followed for the XML file
* Creating new ViewScenes (since all scenes are separate from one another)
* Adding new text fields in the Log In/Sign Up form, in case future user profiles require more information

* Data Management:
* Reading and manipulating level/game design, componenents, and types is done abstractly, allowing for a lot of versatile changes and implementations including the construction of a lot of types of games
* Adding, deleting, manipulating, modding, transfering, data relevant for players, including preferences, passwords, highscores, etc.
* Load games, Social Centers, and Player Profiles are all easy to or already nearly implemented on the data management-side

* Engine:
* Creating new player/enemy variations
* Adding new power-ups, both player and non-player power-ups

* Controller:
* Generating new objects and classes that the Engine added.
* Attaching new sprites to engine objects.
* Changing images in real time.

## High-level Design

From a high view, we created an MVC design in which each part, Model, Visual and Controller, all have a specific function with helper classes and hierarchies to get their work done. Appropriate componenets provide an "API" to allow for expansions and scaling of interactions and features.

#### Core Classes
* View Package:
* A ViewManager that controlled the primaryStage and was in charge of switching between different scenes
* An abstract StyleView class that allowed subclasses to attach any Node to a CSS file
* An abstract ViewScene class that provided the basic structure for any Scene class and inherits StyleView
* Multiple ViewScene subclasses that handled each scene (except GameScene was split into GameScene and GameAreaView specifically for just the view containing the actual game).
* By using this structure, it would keep all of the scenes (other than GameScene and GameAreaView, which I group together) encapsulated from one another and if we were to remove one of the scenes from the path that the user would follow, we could easily do that without having to worry about it affecting the other classes.
* A Button package contains an abstract ViewButton that has an abstract method called enableButton and access to the same ResourceBundle to ensure that all subclasses use the same Resources file, and can all have their own implementation for enableButton.
* Controller Package:
* The GameControl class is the main star of the Controller package, which serves as the bridge between XML, View, and Model during game generation. It's abstract enough to work with any game passed (as long as the proper support of the Engine and XML parser is there) and one controller can even be used multiple times. It binds many properties from the backend to the frontend to allow for streamlined processes.
* The ViewObjects serves as the sprites of the game. The class extends ImageView and is necessary to allow for more properties to be accessible, which aids us in bindings and proper level scrolling.
* Data Management Package:
* The Data Management package got a little carried away... The package functions more of an API than a hard class structure to translate data from a lot of places: the Username-Password Database to the front end, game data to the controller, front end text data to button and visual construction, etc. In effect, it handles anything that can be potentially loaded or changed while trying to hide or encapsulate it. At a high level,
* The UsernamePasswordManager, well, manages the Username, Password combinations as well as anything pertinent for each user, like preferences or high scores.
* Super classes, Parser and Builder, were built with the intention that more functionality will be added later and can be easilly. Core methods for XML construction and translation are found here that are inherited by each appropriate implementation.
* Game Parser, well, it parses... games... It does this by returning indexes of unconstructed engine objects to the controller, instead of constructing them and throwing them to another class.

* Engine Package:
* The main engine class is SimpleScroller which updates the position of all our elements. It also spawned and despawned elements while keeping track of all active powerups.
* In order to keep our design as flexible as possible we used polymorphism extensively. Every backend element extends EngineObject to keep a level of encapsulation in both our engine and any external APIs.
* Inside our engine, our classes are split into two groups, environment objects and characters to further specify interactions and movement.
* All EngineObject's have an encapsulated hitbox that allow the definition of interactions.
## Features Affected by Assumptions
* The engine was built with the idea that all games created will be one player games.
* All XML file functions assume that the user will be using the \data folder
* Scrolling assumes that a player exists.
* The creation of objects in the Controller assumes that there are two property files for said game, and throws an exception if the Controller can't find it.
* Generic methods for building UI components requires the String tags in the XML to follow a specific format.
## New Features HowTo

#### Easy to Add Features
* Color themes: simply just create a new XML file, named "gamearea___.css", where "___" is the name of the mode. Add this name as an option in the UI_Text.xml in the gameScenePreferenceNextScreen tag, which contains all possible modes separated by a semi-colon.
* Language: currently, there is no combobox that allows you to switch between languages in the actual program, but to change it externally, all that would need to be done is switch out the properties file being used (currently, it is "English.properties"). Write a new properties file with the language translations, and change this to be the default language in the ViewScene class. Once that one value is updated, all other subclasses will automatically be updated as well on the front-end.
* Adding new buttons/labels/comboboxes on the front-end: currently, for the menu bar, the ViewScene can handle these three specific types of UI components, and if any of these three components need to be added in the XML file, the generic method allows for these to be added automatically to the scene without extra coding, if the only functionality of the button is to change the ViewScene. For the vertical action toolbar, buttons can be added with more specific implementations, as reflection is being used specifically for the buttons. To add a button, simply add the name of the button in the XML file under the gameToolButtons tag, and then create a new Button class that extends ViewButton in the Button package with the specific implementation. This would then automatically display on the scene, if the correct format is used.
* To create a new ViewScene, just make a new class that extends ViewScene and a new enum state in the ViewManager class that allows any of the other classes to switch to this scene; this will not affect any of the other classes, since they are all encapsulated from each other.
* To add new text fields for the Log In/Sign Up form, just add a new String in the XML file under the tag profilePageText, and it will automatically create a corresponding label and text field in the Log In and Sign Up Scene.

* Load games. Loading a game is nearly implemented, all that is lacking is a little work on the controller side. Game type is hidden from the Parser, and all that is needed is a filename to access in the \data folder. Example games are actually in our repo now, but we didn't have enough time to augment the controller to handle the feature.
* Save games. The only things that are needed are getters from the backend for the current location of all sprites and their cooresponding id's. This can be directly implemented through XMLBuilder with a new document name and the same tags as in GameParser!

* Introducing, manipulating, changing, or modding player data is very easy to do. Just go into the Username-Password database and change the data with the cooresponding tag for preferences, high score, even name or password. The XML file loading will handle it without a problem. Even deleting the document won't result in error as the package knows when it needs to construct it or not regardless of how many users you have been playing with.
* Social Center and adding to Player Profiles. Data is easily parsed from the UsernamePasswordDatabase and fed to the cooresponding classes in the front end and backend for whatever is needed. Thus, it would be very easy to implement a button to see top player highscores or leave messages to be read for other players. The functionalities are limitless based on the abstract implementation of the class!
* To implement a new player a new subclass of SimplePlayer must be created. This subclass may directly extend SimplePlayer or may extend any of SimplePlayer's existing subclasses if they contain any functionality that is desired for the new class. The new player class may wish to inherit already defined movement or override movement. Additionally, a new player class may add or override any functionality that is mapped to certain keys (to be invoked via user input) using the addPlayerAction method. Similarly, to implement a new enemy variation a new subclass of SimpleEnemy (or any existing subclasses) must be created. This is the same process as creating a new player, however there is no user input functionality for an enemy.
* To add a new power-up a subclass of PowerUp must be implemented. Power-ups are divided into two different categories, player power-ups and non-player power-ups. Player power-ups add more functionality to the main player (such as shooting) and these are created by extending the PlayerPowerUp class. Non-player power-ups are those that do not directly affect the main player (such as adding more points or lives) and these are implemented by extending the NonPlayerPowerUp class.
* To have one level lead into the next, we would need a simple clear within the Controller to pretty much restart it (emptying out the hitboxes and clearing the sprites from the screen). Then when there's an indication to move on to the next level, simply call startGame with the same view and parser that has parsed the new file, and boom, the next level.
#### Other Features not yet Done
- Loading a game file from the game loader button.
- Saving a game and its states as a XML file.
- Displaying the updated profile pic of the current user in the EditProfile scene.
- Having one level lead into another.
- Dynamic game content building (infinite scrolling until player dies) rather than the player having to reach a final object that signifies game over.