Shop Implementation
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. 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, this includes:
- Items cannot be purchased when there are insufficient resources available
- 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 (curtesy to team 11)
Main Shop Screen
Building Shop Screen
Artefact Shop Screen
Equipment Shop Screen
For sprint 3, the design needed to be looked into rather than just the functionality and overall viable product. The user experience and recognition.
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:
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
A UML showing the the more significant aspects of the shop screen interface (Note: not all variables and methods are illustrated).
