Interface Implementation

In sprint 4, the implementation of shop was migrated from having individual screens separated from the main game screen, to becoming popups in the main game. The main reason behind the shift in implementation is due to the obvious delay occurring when exiting and entering the shop. The cause of delays and other side issues is by the use of serviceLocators inside the screen constructors, to constantly reregister existing entities as well as registering new ones.

To solve these issues, the team has came to a conclusion to stop the use of screens. This doesn't mean removing the shop feature from the game, but rather change the method of delivering the shop; we have decided that following the representation of inventory, the shop should also become popups. This can fundamentally remove the main reason for delays, the use of serviceLocator methods, but it can also allow us to maintain the interface that was previously designed. Below is the result of the final product:

Page 1: Category Selection Page

Page 2: Item Selection Page

After the implementation of the shop popups, another cause of delays which came up is the shop preloading, when changing from MainMenuScreen to MainGameScreen, it was noticed that to load images for the shops, the program has the read multiple json files which caused a bit of delay in the loading, to counter this, we have decided the instantiate the neccessary Images with the blank shop category button first, and when the shop is clicked on, it will then read the json files to read the images. The effect of this change can prevent the program from loading data before it is actually needed and hence save memory space and enhance performance.

resizing:

For the new implementation of the shop popup, we have also decided to solve the issue of changing resolutions. Based on previous sprints, we have noticed that the orientation of the shop page can become disarranged when the resolution has been changed, this can cause game play to become unpleasant or almost impossible. To tackle such issue, we have decided to set up sizes and positions of the shop images by scaling to the monitor resolution. This idea is implemented at the beginning of the instantiating the shop interfaces, when the addActors are called. However, since popups are only instantiated once at the beginning, to tackle sudden resolution change, a check is also implemented, where if the player suddenly changes the game resolution, by reopening shop, the resolution of the shop can also be readjusted. This is demonstrated below:

Before resolution change (3440x1440):

Page 1: Category Selection Page

Page 2: Item Selection Page

After resolution change (1024x768):

Page 1: Category Selection Page

Page 2: Item Selection Page

Classes

CareTaker: The caretaker class records and stores the player state into the internal memory for the engine to retrieve in the future. The main purpose of this class in sprint 1 is to ensure that the player state is consistent before and after entering the shop thus making the purchasing effect permanent and prevents player state (e.g. gold) from resetting after switching back to main game screen.

CareTaker has also been implemented with the characteristics of a singleton class, the singleton class has allowed caretaker to be accessed anywhere in the game. This design pattern has also prevented more than one caretaker from being created, thus allowing all mementoes to be stored in the same caretaker and allows better management.

Memento: Store the player states and prevents any further change to be done on it, this is so there are no possibility of it changing when the caretaker stores it, any changes done to the player state will cause new memento to be made and stored

Originator: Records the player state before storing it as a memento, store the status of the player's inventory, gold, attack, health, etc. Originator can be edited to follow any further changes before saving it as a memento

UML Diagram

A UML showing the the more significant aspects of the shop screen interface (Note: not all variables and methods are illustrated).

Iterations

Sprint 1 & 2

In line with creating a minimum viable product for the purpose of sprint 1, it can be noted that some aspects of the high-fidelity prototypes were not able to be implemented, such as the alignment of assets on the screen ( as seen below). Since this does not affect the functionality of the feature, these will be adjusted in future iterations of the design.

For sprint 2, new purchase constraints have been created for players in line with user testing & functionality issues explored in sprint 1 - this includes:

1. Items cannot be purchased when there are insufficient resources available
2. Specific items cannot be repeated purchased (e.g. equipments)

When any of the constraints are violated, the buttons will turn red as to notify the player and an error sound will be played (courtesy to team 11).

The implementation as of sprint 2 of the designs from sprint 1 & 2 can be seen below.

Main Shop Screen

Building Shop Screen

Artefact Shop Screen

Equipment Shop Screen