# API_Changes
Thomas Quintanilla (tq11)
Jackson McNabb (jdm109)
Kyra Chan (ktc22)
Daniela Bocanegra (dib4)
Erik Gregorio (eg158)

# OOGA API FINAL

## Internal
The internal API looks a lot like how we described in our outline file done before starting the project.

For the View, most of the internal API methods were within the three classes at the top of the hierarchy, which were ViewManager, ViewScene and StyledView. Due to the other classes inheriting these methods from the abstract classes, placing these internal methods in ViewScene and StyledView allowed me to eliminate a lot of code duplication. Examples of methods that were added include changeScene(), attachCSS(), setScene(), and all the generic methods that were used through all ViewScene subclasses to build UI components. Another class that was changed was the Button package, which was used for reflection on the front-end. I had to add another abstract ViewButton class with the abstract method enableButton(), which was overridden in all sub-classes. I did not anticipate having this in the original plan, but this ended up being really useful in the actual project.

For data management, it works as intended and designed. Each extension of XMLParser and XMLBuilder is an "API" in facility, that handles a specific feature. The superclasses allow for changes internally to these classes, including the construction of documents, tagging and formatting, and extraction etc. Getters for current player and setters are also made available for this API.

For the Controller, the API ended up being expanded upon to handle more specific interactions between frontend and backend, such as handling game overs. At the same time, some of the planned API was scrapped, since bindings made communication much easier than originally planned.

For the Engine, we added more functionality to our classes. We did this for readability as well as functionality. For our hitbox class, we implemented an instersects method that simply let us know that we intersected with another object and did not specify where. We also added a method to retrieve how deep an intersection was. We also defined 5 core classes for all interactions: Character, Structure, PowerUps, CheckPoints and GameOver. These were not implemented in the original internal API because we believed that we would be able to encapsulate all of these into character and Environment Object. We were able to achieve the encapsulation we desired for Character but realized we were too general for the others. We thought that expanding our core classes was able to achieve the same level of encapsulation while (because everything was still and EngineObject), but allow for more specific interactions within classes.

## External

Both external API's work exactly as intended and are clearly labeled in .slogo....

There are some interesting implementations on the data management side. Namely, there is an XML function that parses information for the front end to use for button and screen text. There are two other external API's (of sorts). First, the Username Password Manager, which axiomatically manages all username-specific data, including preferences and highscores. These are public methods that can change and read current data pertintent to each player, even including what the current user is. Similarly, there is a GameParser class which provides public interaction with parsed game data. This is used by Controller.

The View front-end API was integrated into the back-end API and the data management API, since we realized that a lot of the methods that were supposed to be in our front-end API were going to be passed from back-end or data management to front-end instead of the other way around. Thus, methods that were in our original plan for the front-end API were mostly moved to other external APIs. Some of the methods were also converted into internal methods instead. For the View, most of the classes, such as the ViewScenes, did not have to interact much with back-end. Pretty much all of the interactions between front-end and the back-end/controller were done in GameAreaView, which did not inherit ViewScene, and was its own separate class that contained just the Group for the objects and sprites in the game area view. Thus, this class served as the main class communicating between View and the Controller.

The Controller API took some of the components from the originailly planned frontEndAPI interface that allowed outsiders to manipulate key inputs and sprites within the game. It is constructed within a way so that only the most necessary methods and information are accessible. The ViewObject class allows access to the x, y, and image properties within the game, and handleKeyInput allowed the front end access to controlling the hitboxes (since handling key inputs must originate from the scene). The only other main public method within the controller is startGame(), which allows the front end package to, unsurprsingly, start the game, whenever the game is selected by the user.

The backend external API consists of SimpleScroller and our EngineObject classes which were used to communicate with the controller. Everything in the original external API was implemented as was defined. There were minor changes to the methods we had defined, specifically getXPosition and getYPosition were changed from returning Integer's to returning doubles. This API was added to in order to encapsulate the hitboxes. Public methods added to the EngineObject class for this purpose include intersectsLeft, intersectsRight, intersectsTop, intersectsBottom, getBounds, getIntersectionDepth, and intersects. Additionally, there were methods added to give the controller access to certain attributes of an EngineObject, such as getID and getFacing. The SimpleScroller class implemented our GameEngine API. Several additions were made to this API, to provide the controller access to several game components and EngineObject's to consumers. The API now gives access to lives, score, and game over/won detection for the controller. Lastly, we added methods to allow EngineObjects to spawn/despawn, add power-ups, define checkpoints, and declare the game as over/won.