# Plan Presentation ## Side Scrolling Platformer ## Implementation ### Differences * Inputs and their effects * Enemy (if any) interactions * Event triggers * Camera types ### Similarities * Gravity (or some equivalent of how things move naturally) * Win Conditions ### Features * General interface where any game object and its behavior can be defined. * Presets that can define objects on a global scope, but can be overriden at the level scope * Components that define the general behavior of a type of object ### Team Roles * Joshua: I'm doing the frontend mostly, I'm using different libraries to make the components look nice and creating some utility classes to * Robert: I will be working primarily on the back end of the project by managing game object updates. I will also work on passing the updated game object state to the view via listeners in an ObserveableModel interface. * Oliver: I will be working on configuration. Writing the files and using reflection to create the objects and their actions. I will be using the Moshi Library to parse the json and build the components and their actions. * Liam: I will be working alongside Jiyang on the model. We will be implementing an Entity-Component System to represent all game objects. ### Sprint 1 (Test) - April 8 - Have Entity-Component System that creates game objects from configuration files - Being able to conduct basic collision detection between game objects - Parse configuration files. - Handle user input and add event handlers to specified entities. ### Sprint 2 (Basic) - April 15 - Power ups for player - Cheat codes ### Sprint 3 (Complete) - April 25 - GUI level maker (if possible) - Saving and loading levels ## Design Plan ### Goals We want our design tob e as flexible as possible. We plan on using factories and reflection to control what actions are taken. We will define basic building blocks that can do actions (using an actions package) as well as collision events that will affect the game. Each collision event will use an interface to change the implementation, but do the same behavior: handle collisions between two objects. ### Entity-Component System (ECS) The entity is a general purpose object. A component holds raw data for one aspect of an entity, and how it interacts with the world. An entity can be comprised of multiple components defining its behavior (minimum one component). An example of a component ould be health data. Systems execute global actions on all entities with components related to the specified system. An example system could be collision detection. It would iterate through all entities that have a physical component. The benefit of using ECS over regular object hierarchies is that hierarchies in games get very compicated. ECS allows simple abstraction and encapsualtion without having to deal with complex inheritance trees. ### Model The model's basic role is to detect collisions between game objects. When a collision occurs it will notify each of the objects that collided with one another and pass a reference of those objects to each other. It also takes in and handles information passed in by the controller and updates game objects based on these inputs. Likewise the model also utilizes an ObservableModel interface to pass updates to the View.