Create Player Selection Menu

[jChicote]

Description

Before the player opens the main menu, they are to select which player save to access

Acceptance Criteria

• Player or Game Save screen exists
• Domain entities exist to construct the unique save state for each player
• Models exist to hold data throughout gameplay

Implementation

• [x] Create screen for Game Save
• [x] Create controller and view models for Game Save screen
• [x] Create use case for Create, Update, Delete and Get 'GameSave'

  • [x] Add data context implementaiton to include this entity

• [x] Create domain entities and game models for game save

  • [x] Add GameSave model and entity
  • [x] Include last access as part of the entity

• [x] Add new UI State for 'Game Save selection'
• [x] [If necessary] Add new GameState for 'Game Save selection'

Notes

[jChicote]

Scope Change

A new button group is added which contains minor navigation and control actions for the GameSave screen.

The buttons included are:

• Clear = Clears the currently selected level
• New = If slot is empty, this will create a new game save
• Quit = Exits the game

Important:

• These buttons will have validation on them to prevent the users from introducing unintended actions
• Confirmation popups will be used to confirm the user's input

[jChicote]

Scope Change

Since we can now set the details for the game slot, we need to create a modal popup which allows us to set these details

• Buttons will have an input field for the name
• Buttons will allow the profile image to be togglable presenting different profile picture options

Criteria

• [x] A modal popup exists for editing game slot
• [x] An Edit button exists to toggle the edit option
• [x] A sub popup exists to select the profile icon

[jChicote]

Scope Change

The slot buttons need behavior to modify the image to the slot. Modify the slot so that we can change the color highlight of selected populated slots and empty slot

• [ ] Add modifier for GameSlotView to modify the selected color of the displayed view.

[jChicote]

Idea 1

The current state of the view is complex dependencies on view models which is violating the seperation of concerns between views. The idea is to use the conmtroller as the mediator between the view models. However this violates MVVM as the controller mediates the View Models more tightly. Removing presentation logic from the VMs to the controller, like in MVC.

Main intention for this implementation

• Refactor the model from the controller and tie them to the view model
• Mediate the communication between view models to seperate their knowledge of eachother

[jChicote]

Idea 2

To maintain MVVM we would need to change the design of the view models and the intention of the controller.

• Now as a tradeoff, we will reserve the controller for initialisation and for key operatios not concerned with the state of the view.
• The view models will be independant but will rely on subviewmodels to communicate data between related views

  • Subviewmodels will not be initialised by the parent vview model but instead provided from the controller and injected into the view model.

Problem

• This approach is way too complex for me and for the screen. It means that view models know of the view model witihin.

[jChicote]

Scope change

The View and View models will be implementing some form of data binding so that the Views actually interact with the view models instead of the view models handling the view interaction to it.

A command will be implemented so that the some logic is executed from it being binded to the View

[jChicote]

Scope Change + Problems:

The view and methods to set the sprite image relies on the sprite alone as the dto sends out the sprite image. However this is being done directly on the edit modal rather than through the modal. Additionally, there is no concrete way of identifying the selected profile without using comparisons of the sprite image directly

What is needed to fix this

• Have the GameSlotDto instead use the ProfileImage class containing both int identifier and sprite image
• Make it so that the presentation handles the conversion to the profile image
• Create a provider to output the correct image and provide default if in fault
• Remove use of dictionary and rely on list of ProfileImage.

• Ensure no conversion is occuring throughout the viewmodel and views

  New Problems

• The Viewmodel to view construction is almost hard to read
• The naming use throughout these vm and views are not ideal and clean
• Comments need more meaningful direction
• Naming of views and repetative naming is not ideal
• The mediator's event names are almost hard to distinguish its use. Needs to be more defined and specific to concrete descriptions of the GUI's behavior rather than a functional one

[jChicote]

Next Work Checklist: (Sunday 1st September)

Things to Fix

• [x] When editing the game slot, there are events from the game save slot notifying the edit modal causing the input to be overriden.
• [x] The events are being invoked multiple times. Lock the inputs based on which screen is active.
• [ ] The screen needs to save the input after creation

Additional 1:

• [x] Modify mediator events to be more description of event types.
• [x] Add invocations to enable interaction from 'Canvas Group' component

[jChicote]

Resulting Design (MVVM):

[jChicote]

New Problems:

The state of each menu is ambigiously designed.

• [x] Define the concrete, Start, End or Update/Refresh (Possibly by a base abstract class)
• [x] Make them implemented on all screens
• [x] Reorganise the event types used by the enum to be defined by both state and action and seperated with a comment header of the screen its related to.

[jChicote]

New Problem:

Button visibility and enabled state is reverse as it should be.

[jChicote]

Scope Change

• [ ] Add facade method and outputport for Deletion UseCase for GameSave
• [ ] Add usecase for DeleteGameSave
• [ ] Add Repository and DataContext methods for entity deletion