Create Player Weapon Systems

[jChicote]

Description

Acceptance Criteria

• Can shoot
• Can reload
• Can aim
• Can shoot inidividual bullets

Implementation

[jChicote]

Next steps

• [x] Add an opening action event for the event timer

• [x] On event start, add a method that runs the first round on start and disables the the first round shot until the interval fired round is shot.

  • [ ] Add new method which simply fires gun
  • [ ] Add new method which fires the first round
  • [ ] Modify the existing fire method to handle held fire.

• [x] Modify the toggle method to make first round available after if firing is released / cancelled.

• SO if the weapon is first clicked, a fire is immediantely shot but if unclicked and then reclicked immediately. The next shot would not be fired until the timer ticks to the next round. ( This means that the tick should not be guarded by if statements and just run continously ).

• Reloading should not be affected by this

• If held, the first shot will be made and successful shots will then follow.

[jChicote]

Suggestion on complication with first fire and held fire.

Add a new timer or reuse the FirstFireTimer to become 'FirstShort' or 'FireStartTimer'. After the first shot fire is made, the boolean 'HasFiredFirstShot' should prevent any other shot being made by the trigger. The timer will run until it completes and renable the first shot capability.

Meanwhile for held fire. If the first shot is fired, the timer is reset for the held fire so that the held fire does not retrigger until some timer after the first shot

Currently Definable states:

• First Fire
• Held FIre
• Reloading

[jChicote]

Next Steps

• [x] Manually set the prefabbed weapons to the weapon bay
• [x] Have the Player system hadle the initialisation of the weapon bays and weapons
• [x] Give each weapon bay its own indentifier
• [x] Give the weapon its own assigned weapon bay

[jChicote]

Next Steps

• [x] Create use cases (get, create and update)
• [x] Invoke get use case during loading player weapon systems

When will create be used

• [x] When getting your ship which comes with the default set of weapons (Likely invoked with a ship specific use case)
• [ ] When getting a weapon from your inventory. (Creates the weapon along with its inventory entity.

When will update be used

• [ ] When upgrading your item in the inventory

[jChicote]

Next Steps:

Creating Player

• [x] Add Create Player Usecase
• [x] Create Mappers
• [x] Hook create player logic on existing game save and to spawn one in game setup handler
• [x] Ensure that a ship is already provided

Add Creating ship

• [x] Add CreateShipUseCase
• [x] Create mappers
• [x] Hook to be used before Creating player
• [x] Register in Game Setup

Add Create Weapon:

• [x] Add CreateWeapon use case
• [x] Create mappers
• [x] Hook to be used before creating ship (only if a starter)
• [x] Register in Game Setup

[jChicote]

Problem

The design of the usecases makes it reliable but is not suitable for execution in an environment that relies on a pipeline. The fact it needs to execute a seperate methods will lead to it becoming seperate to the coroutine thread.

Suggested changes:

• A command can be created as part of the pipeline and with other locations to load all the required data for the action it is performing. This way a seperate object can be responsible for resolving the different dependencies, values and data that needs to be constructed. Following this, the command will then query the data step by step and a seperate method will exist that will validate that all the required data has been loaded. This will be in the form of a flag that will be used during coroutine execution (A timeout value will need to exist).
• A dataloader service will need to exist to execute these commands. These will exist to only load command objects until its completion. These can be used in different locations requiring data loading and is not limited to the setup pipelines.

[jChicote]

Future tickets:

• A seperate screen needs to exist for selecting ships
• A new modal popup for messages with 'OK' buttons

[jChicote]

Next steps for the player weapon system:

Features / improvements:

• Creation of a default debug player record in the data context. So that when debugging the user used in development can access a game save with all the features.

Issues in development:

• The game and scene startup are not in the same location requiring back and forth navigation
• The facade names should not be controllers as that can be ambiguious to the component controllers
• The use of providers to should specify whether they are a gameobject provider or data provider.
• The handling of the facades must be always done asynchronously, these should always be grouped in actions. This could be resolved by instead of the facades existing as facades but having IEnumerator action Data / Model controllers that handle directly through IEnumerator. This will help reducing the bloat in methods containing a lot of setup logic. This also ensures dependencies can be handled from the constructor instead. This also means that these instances of the controllers would exist as persistent services. In this case, the UI will rely on the interface adapters for updating the UI, and GameLogic relying on the IEnumerator actions to limit race conditions.