jonaskaad/semesterproject-4

GitHub page for the 4th semester project on SDU

semesterproject-4's Issues

Set GitHub action to use Java 8

Currently it is set to Java 16. Currently it seems like only Java 8 will work, but that might change in the future

Refactor monsters to have URL's instead of images

Make the monster class contain two URL's/paths that lead to their front and back sprite. This needs to be implemented in all relevant places: JSON parser, the monster class and interface, and where the monsters are drawn.

Find a name for the game

Figure out a brilliant name for the game

Test card

Converting card to issue

Import and setup Tilemaps into LibGDX

We should be able to import .tmx files into libgdx and show them. Ideally this includes collision, as Tiled has support for assigning collision in the editor.

MapView implements IGameViewService
Hav metoderne.
Sprite til map. tilemap

This issue blocks #52

Sequence diagram for Map

Create the battle-scene simulation

Should simulate the battle between two IBatttleParticipant each using an amount IMonster.
The battle should be turn-based.

This should only be a simulation, and not focus on actually drawing the battle, as that should be handled by #17.

Discuss that method should be used in order to send information to the battle-scene of what to draw. Either the battle-scene view will inject an interface when creating the battle-simulation that will allow the battle-simulation to command the battle-simulation of what to show. Or use a publish-subscribe pattern so the battle-simulation will "publish" all battle events, which the battle-scene then subscribes to in order to display the battle accordingly.
There are pros and cons to each method. Just injecting an interface is simpler, and make it easier to actually synchronize the battle-simulation and battle-view. But on the other hand, the publish-subscribe pattern would allow other packages or modules/components to follow along with what happens inside the battle which could be beneficial.

Remember to create unit tests for the simulation

Sketch UI for the battle scene

Convert requirements to github issues

Requirements: https://docs.google.com/document/d/1d72AygkjAxSYcAiVU0iAnNw-SblDmAzLdRKLmULfqk8/edit

Detailed use cases for Map

https://docs.google.com/document/d/1gUozvYvIXJp1_HrzB_usStWaMTmhBHzKqREfICQwfHY/edit#

Unit tests for BattleView/BattleScene

Create unit tests

Prioritization draft

MoSCoW of all requirements until now.
Decide requirements to complete in first iteration.

Update design for Battle

Update the interface document to reflect the changes that have been discussed (transfer responsibility from Battle to Monster, split Battle up, etc.)

Update analysis for Battle

Look at domain diagram and use cases, maybe add more analysis?

Create Monster component

Create the Monster component:

Monster class implementing relevant interfaces.

• Create relevant variables
• Implement the relevant methods

Monster Plugin

• Create an instance of a Monster (Create a Charmander)
• Create some moves?

Refactor Battle component into BattleView and BattleSimulation components

Refactor the NPCController/AI into a separate module

Setup Github Actions to automatically run tests on new PR's

Non-Functional Requirements

Convert requirements to components & interfaces v3

Create bundles for the project

• Player
• Map
• NPC
• BattleSimulation
• BattleAI
• MonsterRegistry

Implement IBattleView interface

Refer to the interfaces document on google drive.

Create Player bundle for Map

This bundle should represent the player.
The bundle should include:

• A player class that extends the entity class
• A Player plugin. This should instantiate the player with certain parts.
• A player control system class

This issue blocks #52

Create a battle-scene view

In order for the game to have a turn-based battle gameplay, we need to create the actual visual scene shown to the player.

This issue should only create the view itself. - not the actual simulation or handling of battles.. The idea being that we don't want to tie the visuals (presentation-layer) together with the code that does the actual simulation together (domain layer). I'm not saying that we should componentize each part (although that could potentially be possible I guess). But even though the parts are in the same component, I still think we should try and use best practises from OOP/VOP and keep the different parts as loosely coupled as possible.

Create an interface that contains all methods the battle-simulation would have to call in order to visualize the battle that it would be simulating. These methods could be, but this is just an example:

• void setPlayerMonster(IMonster monster)
• void setOpponentMonster(IMonster monster)
• void doPlayerAttack(IAnimation animation, int newOpponentHealth)
• void doOpponentAttack(IAnimation animation, int newOpponentHealth)
• void showText(String text)
• boolean isAnimating() (Skal signalere til Simuleringen at battle-scenen ikke er klar til at modtage nye kommandoer endnu, fordi en animation er igang).
• etc.

Make some code that draws the battle-scene itself, and make some way to allow the simulation to control the view using the interface.
Alternatively
Make the battle-simulation provide a publish-subscribe pattern which the battle-scene subscribes to, and use that to send messages from the simulation to the battle scene.

Discuss with the developers of #19.

Testing

This might be hard to unit test. Even more to describe how to without knowing how it is going to be implemented.
See if you can think of something. If you can't think of anything, then just make some tests that assert that exceptions will be thrown if you call setPlayerMonster(null) or something similar.

Functional Requirements

Create the required Parts

Create the required EntityParts for Player and NPC such as:

• SpritePart
• PositionPart
• MovingPart

This issue blocks #48 and #50

Set up JSON parser in OSGi

Convert requirements to components & interfaces v2

Update domain diagram with Map

https://app.diagrams.net/#G16yRi5RaK3R5EpBIF9X5aViWKVEw3EWUG

JSON parser for monsters

Load monsters into the game from a JSON file

Setup the project

Setup the project in a Java enviroment with Maven.

MonsterRegistry

Make monster registry - decide if it should be its own module or part of the monster module

Test Issue 1

BLablabla

Refactor IMonster to have a map of stats instead of individual getters

Backdrop in battlescene not scaleable

Look at this black bar shit:

Cancel in move selection screen should be the last option.

Move the "cancel" option from the "fight"-menu in the Battle scene to the bototm.

Test issue 2

balblabla

Use case first draft

Use cases documenting the gameplay

Put together Map, Player and NPC

Make the different bundles/modules work together such that:

• The player can move around the map
• The map has collision
• NPC's can be in static positions
• NPC's can move randomly around the map

Map
MapProcessing implements IEntityProcessingService
MapParticpants (Liste af entities)

Create NPC bundle for Map

This bundle should represent an NPC in the map view.
The bundle should include:

• An NPC class that extends the entity class
• An NPC plugin class that instantiates the neccesary parts
• An NPC control system class

This issue blocks #52

Create BattleScene related DTO interfaces

Blocks #17

Create DTO (Data Transfer Objects) interfaces that should be used for the BattleScene.

From the top of my mind, the following comes to mind:

• IMonster (Represents a monster. Has Name, HP, Stats, Sprites (Maybe even front and back-sprites), List etc.)
• IMonsterAction (Represents a "move" or "attack" that the monster has and can use. Should contain info like: Name, Desscription, Damage, Effect, Type, IAnimation, Sprite)
• IAnimation: En eller anden repræsentation af en animation. Læg hovedet i blød. Men bare lav nogle simpelt det kan udvides senere
• IBattleParticipant: Has list monsters of monsters along with properly other stuff (Maybe methods that can be probed for input? (Either from the player or the AI) I don't know.
• Probably a lot more when you get into it

Convert requirements to components & interfaces v1

Find bundles in file explorer and install them

Class diagram first draft

Requirements analysis

Connect the given project description and our ideas, to the requirements, with a description of our gameplay and perhaps a full use case diagram

Refactor some code from BattleSimulation into a MonsterProcessing class in the Monster module

Handle nullPointerExceptions if there is no BattleSimulation or BattleMonsterProcessor

Setup the project with OSGi or NetBeans

Setup the project with either:

• OSGi
• NetBeans Module System

Configure it such that it's possible to use either its whiteboard model or dependency injection. Through either the Lookup API or the BundleContext API

Use case diagram for Map

Window for dynamically unloading and reloading bundles with checkbox