USE_CASES.md

Use Cases:

1. The user wants to change the sprite from unmovable to a flyer: Change the instance variable of the attribute that the user designated by instantiating a new instance of that object that implements the intended interface.
2. The user wants to change one of the tiles: The tile that is clicked on will then produce a palette of other possible tiles that could be changed to. Once one of these new tiles are selected, the setTile() method in the Tile class will be used to change the image.
3. The user can reset the game: There is a reset button that we will put on the front-end. When this button is clicked, the current level that the user is on at that moment will be set back to the initial configuration that was set in the beginning. Thus, the initial configuration needs to be saved somewhere.
4. The user can skip to the next level: There will be a button that says "Skip to the next level". When this is pressed, regardless of the status of the level they are currently on, the initial configuration of the next level will be brought up and set up.
5. The user wants to check his/her current points: There will be a menu button on a panel next to the screen with the map. This menu button will bring up a screen wtih a lot of information, such as points, time remaining, and lives remaining.
6. The user wants to change the sprite's method of attacking: Change the sprite's attacker object to the object that performs the specified functionality.
7. A sprite is attacked and makes a sound: Attacking a sprite triggers an AttackEvent that is then handed to the event bus, which then fires a SoundEvent in the sound system that makes the desired sound
8. The user selects a component to upgrade with points: Selecting the sprite and clicking the upgrade button (?) triggers an event that should then allow the user to select what he or she wants to upgrade to based on the upgrades available
9. Losing condition is triggered: When the losing condition is triggered, the animation and gameplay are stopped and the end of game display is put up on the screen
10. The user edits the map while the game is playing by clicking and dragging a tower and changing its position: The click and drag event triggers another event which notifies the back end representation of the map of the location change and updates it accordingly, which then updates the view through the bindings we set up
11. The user can load a game file and run it on the game player: Create a file choosing system to allow for user input files. After receiving the file, parse the information and create the specific game, set up initial attributes of game components, ask the game engine to run the game loop, and render the game view by getting front-end information from the game engine.
12. The user can select a sprite (needs visual effects): The game player emits a JavaFX mouseRightClickEvent to the event bus. The input processing module in the game engine can recognize the selected JavaFX node and emits a displaySelectViewEvent (which contains the location information of the selected node) to the event bus. The game player receives this event and draws a circle at the given location.
13. The user can select one ability of a sprite and use it: The game player emits a JavaFX mouseRightClickEvent to the event bus. The input processing module in the game engine takes this event and recognizes the selected JavaFX node. Then firstly the ability icon will have a circle around it to indicate it's selected as in the previous use case. Meanwhile the input processing module emits a useAbilityEvent to the event bus and another event manager deals with this event (details omitted here). Finally when a useAbilityDisplayEvent is sent to the bus and received by the game player, the game player can display the visual effects of using the ability.
14. A sprite is attacked by enemies and loses health (needs visual effects): The game engine emits an attackSpriteEvent to the event bus, and the game player receives this event and knows which sprite is attacked from the attackSpriteEvent, and emits an updateSpriteViewEvent to the event bus, and the corrsponding sprite receives this event and emits a sendSpriteAttributesEvent to the event bus, and finally the game player can get the udpated sprite attributes (eg, health) from the event and update the displayed value.
15. The user loses his game: The game engine emits a gameEndEvent to the event bus, and the game player receives this event. Change to a different view with information indicating the player's loss, and save the current game progress into files (losing at which level, current money, etc).
16. The user can change the color of some sprite: change the color from the javafx nodes or use script code to change the color.
17. The user can change the speed of some sprite: change the speed of some sprite by selecting the sprite and a popup window shill show some peroperties of the sprite, then the user can change the speed of the sprite.
18. The user can choose the number of sprites in the beginning of the game: choose the number of all sprites from the menu bar all other javafx nodes.
19. The user can pause one game for later playing: The user can click some button or click some shortcut on the keyboard to pause the game and store the current situation.
20. The user can zoom in or out some parts on the map: The user can click on the camera on the screen and inout some keycodes for zoom in or out.
21. The user selects a sprite and presses a key to move it forward: The sprite is selected by click on the screen (this is updated in the corresponding back-end and in the sprite) and then the interface handling different kinds of user input will translate the fact that the key pressed results in a up event and then a upwardMoveEvent (name could change) is called, setting the attributes of the selected sprites so that they will move upwards in the back-end and the binding moves them correspondingly forward on the front-end (the actual moving is done over the course of animation updates)
22. A sprite is attacked and loses health: The information that a sprite is attacked will be carried through an event through the event bus which will then lower the health of that sprite, an instance variable, by the amount contained in event. If the damage is greater than the current health left, the sprite will die (see below use case)
23. A sprite dies: If a sprite has run out of health, then a deadSprite event will have to be called which will call the model to remove the sprite. Then depending on user settings for the game, the dead body may remain on the screen or may be called to disappear after a certain amount of time.
24. Current game with current rules is won: Winning condition (kept in the model) is triggered, resulting in a winGameEvent/maybe series of events being called which will stop the updating of the game loop and also display to the user that the current game has been won.
25. Insufficient funds/points to buy upgrade/new unit/any item: an event will be called to the event bus which will result in displaying (either in a new window or on the game screen) telling the user that necessary information. Nothing will change in the back-end model because no state change.
26. The game developer creates a new Tower using a preset configuration: The developer selects the preset "Tower" configuration on the ObjectCreator, which produces the data for the Tower class that implements Sprite, Attacker and SpriteProducer. The Secondary SpriteHolder allows it to instantiate new Sprites, which are the Tower's projectiles. The user is able to modify the image attached to the Tower, as well as the Tower's projectile because the Tower implements Sprite and SpriteProducer respectively. This is done by selecting "set image" options, which open up file choosers for the user to select. Additional parameters such as reload time and firing speed are set by inputing strings into input boxes.
27. The game developer creates a new Tower using scripts and minimal preset configurations: The developer selects the "Design your own class" option on the ObjectCreator. He clicks the "new class" option, and under its "attributes pane", he selects Sprite, Actor, EntityDetector, and SpriteGenerator. Since the class implements Sprite, the developer is able to click on the "Sprite" attribute to select the series of images that the class displays. Since it implements SpriteGenerator, the developer must select the "Bullet" sprite for the class to generate. Then, he selects the EntityDetector attribute and clicks the "Script" option, which opens up a text input box. He can then overwrite the EntityDetector's DetectEntity function to return all Monsters in a certain range. Finally, he selects the Actor attribute, clicks the Script option, and writes a script so that every three times the actor's run() method is called, the class calls its detectEntity function. If the detectEntity function returns a nonempty list of monsters, the Actor then uses the SpriteGenerator's createSprite() method to create a new Bullet that is pointed at the Monster. The class is now complete. He saves the class with a name "Tower2", and from now on that class is displayed under "user defined classes" to allow easy access to the player for use and further extension.
28. The game developer saves the data of his game: When the developer selects the "Save game data" button, the GameCreator produces a folder in a superfolder named "GameData". GameData contains a "Classes" file folder, which contains the information needed for each class used in the game, it contains a "Resources" file folder, which contains the image and sound files used in the game, it contains a "Model" file, which represents the XML version of a Model class that stores all the initial data that is used for each screen of the game. This may then be played later on.
29. The game developer wishes to create a heads up display: The developer selects the preprovided "HUD" class amongst the preprovided classes. A pop up box appears that displays the variables that the Model tracks over the course of the game. He selects some variables, and clicks save. Now, a HUD class is created that is bound to those variables and displays a list of those variables.
30. The game developer sets the game to pause when the player hits space: The developer selects the "Design your own class" option. Under the class' attributes, he selects"InputListener". He selects the InputListener attribute, which pops up new screen. He clicks "Add Listener Event" and presses spacebar. He then clicks "Add script", and for his script, he types getEventBus().fireEvent(c->c.pause()). This essentially tells the eventBus to fire an event which tells the Model to reload itself based on the data files.
31. User wants to select how many levels it takes to beat the game: The user will either be able to send a command into the model programmer that uses scripting to interpret something like "numberLevels=20" and set this in the model or a small user input box will be available that will use the same setNumLevels method in the model
32. User is trying to create their own sprite that is indestructible and can fire bullets at a certain range: The user will go into the ObjectCreator and will click on the sprite object and several options will appear. One of these options is Health and he can set this to infinity and another option is Attacker and he will select this. now the sprite has the conditions he desires and he can set all other attributes like firing rate, etc. These inputs will correspond to a composition of attributes in the back end for a sprite and then the sprite created will have this specific behavior.
33. User wants to put a tower on the map before the level starts: Before a level starts, the update method for all sprites will not be triggered, so a mouse click event can select a tower type and then hover over the map and click the mouse again to trigger a setting of the tower within the grid element of the map overtop which the mouse currently was. This will update the sprites collection in the model to include the new tower.
34. User wants to pause the game while it is currently running: Press the play/pause button on the game play screen and this will trigger an action that is sent to the event bus so that all update functions are paused using a boolean value so that they only update when this boolean is true.
35. User wants to upgrade a tower: Click on the tower to upgrade and a pop up box will appear containing the specifications of the tower and the cost to upgrade it/what this will do to the tower. A button to purchase the update will be pressed and then an action is sent to the event bus that changes the state of the tower in the model but also has a check against amount of money the player has left before the purchase/change can be made.
36. When AI monster detects enemy in range: In the main loop range checking is done for all the sprites who enable range checking, then for each AI monster, a range is checked. The units within range will be wrapped inside the event to send to the monster AI for further processing, either attacking or ignoring.
37. When a subrequest/achievement is achieved: We would generally only allow limited types of achievement: some property reaching a certain value, or some unit dies. When a new subrequest is registered, it has to listen to that specific value or unit for testing.
38. Mouse icon change: When mouse hovers through some sprites, the event will be processed through selection manager, and calculated by team manager, then decides what kind of icon to display.
39. Monster move from one position to another: The monsters only goes by straight line and remembers a current line location and a final target. When the current line location is reached or current straight line movment is interrupted, it sends the event to the path finding AI to recompute its speed and temporary target.
40. After monster dies: Possibly sounds get played and something gets droped. Then it first becomes a "dead body", and then the dead body starts a counter and disappears after some time.