Inventory

Introduction

The player's inventory system lies at the heart of our game, a dynamic feature heavily inspired by the likes of Stardew Valley and Minecraft. Serving as a central hub for managing a diverse array of items, the inventory offers players a seamless and immersive experience. Its significance cannot be overstated, as it empowers players to navigate the challenges of an alien world, where farming and defense against extraterrestrial threats intertwine. By orchestrating the inventory to accommodate various functionalities and fostering an intuitive user experience, we aim to elevate the gameplay to new heights.

Inspirations and User Interface

Inspirations

The design of my game's user inventory draws inspiration from two iconic titles, Minecraft and Stardew Valley, incorporating elements that contribute to a seamless and engaging user experience. From Minecraft, the inventory system takes cues in terms of its grid-based layout and the concept of managing a diverse array of items. Just like in Minecraft, players can efficiently organize and access their collected items within a grid, providing a sense of order and control. Stardew Valley, on the other hand, influences the more intricate aspects of inventory management, including the ability to interact with items and detailed tooltips. Much like Stardew Valley, my game's inventory system prioritizes user-friendliness, allowing players to hover over items for essential information and interact with them effortlessly. By blending these inspirations, my game's inventory design aims to strike a balance between accessibility and depth, ensuring that players can easily navigate their inventories while still enjoying the complexity and richness of item management found in these beloved titles.

User Interface Design

The following designs are inspired by both the Minecraft and Stardew valley inventory interface designs. It draws upon some of the best elements of both and was created in accordance to our games design guidelines.

Toolbar UI Design

The toolbar has a sleek brown colouring with the hotkey labels nicely faded into the design in order to not draw attention away from the items in the toolbar or obstruct the players view of said items. It is a pretty standard design but still complements the rest of the games aesthetic.

Inventory UI Design

The design of the full inventory follows suit from the tool bar. It is broken up into three distinct rows of 10 which was found to be the most logical and easy to navigate through our in team testing. It again follows the same clean colouring that matches with the games aesthetic.

Sprint One Implementation

Features Implemented

• Basic UI: A fundamental user interface was created to represent the players inventory and toolbar which are implemented through the ToolbarDisplay and InventoryDisplay components. These extend the games base UI Component and utilise lidGDX's built in Window, TableandStack` classes in order to create the user interface.
• Inventory Backend: Through the use of the Inventory Component class which is an extension of the base Component class, the inventory was implemented as a java ArrayList that contains objects of the Entity class. Basic methods such as getInventory, addItem, removeItem etc have been implemented
• Backend Tests: A test suite that covers the basic functionality of the inventory has been implemented so that the basic backend functionalities can be tested. These were implemented through the use of basic Junit tests.

User Interface

Below shows the user interface as of the end of sprint one for the toolbar and for the inventory. This interface will be the basis used to make srue functionality is working correctly and subject to refinement during the last sprint to sharpen up the user interface to more closely align to the design show above.

Sprint 1 Toolbar User Interface

As can be seen below the sprint one toolbar user interface only includes the slots for the items t be held in. Furthermore, it does not have any labels for the hotkeys to shows the player which item slot each key corresponds to.

Sprint 1 Inventory User Interface

The inventory follows the same conventions as the toolbar, not being able to house any item images in the sprint one version.

Missing Functionality

There is a lot of inventory functionality that was missing during the first sprint version of the player inventory. The reason for this was due to a number of factors, the biggest of which being: Difficulty in understanding how to create the user interface and reduction of the team size due to members dropping the course. Therefore, it is vital that within sprint two that the remaining functionality of the inventory is implemented this includes but is not limited to:

• Displaying Items: Items should be displayed in the inventory and in the toolbar once they have been collected by the player
• Picking Up Items: When a player collides with an item on the map it should be added to their next available inventory slot
• Displaying Item Count: Items of the same type should stack and this number should be visible in the inventory and or toolbar
• Rearranging Items: Items should be able to be re arranged in the toolbar and within the inventory
• Toolbar Hotkey Labeling: The toolbar hotkey labels should be visible so that the player knows which hot keys correspond to which slots in the toolbar
• Hotkey Item Selection: When a item is selected using the hotkeys, they should see that slot in the toolbar be visually selected to that they know which item they are selecting
• Generic Inventory: The inventory itself should be generalised so that other entities besides the player are able to have an inventory, opening the door for shops and customisable animals and vehicles etc
• Drag and Drop Items: Items should be able to be dragged and dropped into the inventory as well as having the ability to rearrange via drag and drop within the inventory

The next sprint should be sued to add these additional functionalities to the inventory so that it can be completed and working effectively within the broader game.

Sprint Two Implementation

Features Implemented

Within the second sprint the inventory functionality and user interface was refined to its full functionality, the following features were effectively implemented:

• Displaying Items: Items within the inventory can now be seen displayed in the toolbar and inventory UI components specifically ToolbarDisplay and InventoryDisplay. This new display also comes with the addition of a new class used to hold information regarding item in the inventory that being ItemSlot, which is an extension of the Stack class. Meaning it is possible to stack multiple images and label into and onto an instance of ItemSlot.
• Picking Up Items: Now once a player collides with an item that is on the map, they item will disappear and appear in the next empty slot of the player's inventory. This was implemented through the addition of a new class itemPickupComponent created by the items teams that places the item inside the InventoryCompoennt via the addItem method.
• Displaying Item Count: Once items are within the inventory the player is able to stack them onto of each other automatically and the count for each item is displayed as a label to the bottom right of that item. This was implemented by modifying the ToolbarDisplay and InventoryDisplay components to add the count label to the ItemSlot object representing the item so that it appears on the user interface.
• Rearranging Items: Items can be rearranged within the player inventory through the use of drag and dropping with the TouchPlayerInputComponent so that the player is able to move items around between ItemSlots when needed.
• Toolbar Hotkey Labeling: The hotkey labeling is implemented similarly to the count labelling as in it is attached as a label object onto the ItemSlot object for each item in the toolbar, in order to allow the player to understand what they are selecting.
• Hotkey Item Selection: Now when the player presses one of the hotkeys the specific cell in the table corresponding to that hotkey will be highlighted. This is implemented through the ItemSlot and ToolbarDisplay components and the event is trigger in the PlayerActions component.

User Interface

The user interface for the second sprint refines that of the first in terms of the functionality and features added. The player is now able to see the items in their inventory as well as their toolbar when they pick them up by colliding with them. The player can see what items are selected within the toolbar, the item count as well as the hotkey numbering.

Sprint 2 Toolbar User Interface

The toolbar interface has been upgraded to show the hotkey numbering as well as the images of items within the first 10 slots of the players inventory. The player is able to also see the count of each item in the toolbar as well as select an item for use by using the hotkeys which then highlights the item in the toolbar

Sprint 2 Inventory User Interface

The inventory now is located closer to the bottom of the screen, making the toggle animation smoother, and more like the inventory is opening up and expanding as opposed to the toolbar and inventory UI being completely different tables on the screen. It has all of the same upgrades as the toolbar as well in terms of displaying items and their counts

Sprint Three Implementation

Features Implemented

Within the third sprint the inventory functionality and user interface was refined to improve the efficiency and implement functionality as requested by other teams. This included:

• Displaying Item Count: Within Sprint Two, item count was implemented, but it was not entirely functional. Within Sprint Three we improved it so that it would always display when the count is above one and when an item is removed the display handles it correctly.
• Improving Performance and Render Logic: After Sprint Two's completion it was evident the logic for re-drawing the inventoryDisplay to display the itemSlots caused significant performance issues. Initially we, used an approach which when the inventoryComponent triggered an event of an item being added or removed it would create new itemSlots and re-add them into a new table, window, and stage. This was inefficient, within this Sprint we simplified it to create an array of itemSlot called slots which would update each individual slot and thus, cause the display to update. This removed the need to create many new itemSlots each time and rather only updated the created classes. Further simplifications to the render stage is possible, however, will be implemented within Sprint Four.
• Multi-Inventory Display: In Sprint Three, functionality was added to enable the display of multiple inventoryDisplay at once. This was achieved through the inventoryDisplayManager class which tracks all inventoryDisplay which is created within the GameAreaDisplay and tracks all inventoryDisplay instances. This class was added as it allowed us to progress to the point where we could handle chests and other entities with inventories and display their inventory. Within Sprint Four, transferring via drag and drop will be added.
• Inventory Component Improvements: To further iterate on work completed in Sprint Two, inventoryComponent was targeted to be reworked with upgraded needs as the needed functionality had significantly changed since Sprint One. Thus, many improvements and simplifications were made to inventoryComponent to ensure that it would meet upgraded specifications as the scope of the game has increased. One such example of this is pershable items.

Sprint Three Multi-Inventory Display

When only a single inventory is displayed, it will be centered in the middle of the screen and the name now includes the entity type as a way to ensure that the user always knows what inventory they are looking at.

When multiple inventory are displayed, it will display the inventory opened first above the inventory opened second. inventoryDisplayManagersimplifies it so that one displays that are open are counted into this factoring and this allows us to neatly show the user both inventory.

UML Diagram

This diagram outlines all of the major relationship between the objects that make up the inventory system as a whole, showing how they interact and extend each other. It covers the following classes: InventoryComponent, Entity, KeyboardPlayerInputComponent, TouchPlayerInputComponent, Player, PlayerActions, ItemSlot, ItemFrame, InventoryDisplay, InventoryDisplayManager, InstantTooltipManager, ItemPickupComponent, ToolbarDisplay, PlayerFactory, ItemPickupComponent, PlayerActions.

Inventory System Testing Plan

Objective

The primary aim of this testing strategy is to ensure the robustness, functionality, and user-friendliness of the inventory system within the game.

Testing Methods

1. Unit Testing (Backend)

• Employ the JUnit testing framework for comprehensive unit tests on the inventory system's backend.
• Validate the accuracy of item storage and retrieval in the inventory data model.
• Verify calculations concerning item quantities, weights, and values.
• Thoroughly test item management functions (addition, removal, updates).
• Assess interactions with other backend game systems, such as character attributes and quests.

2. Integration Testing (Backend)

• Execute integration tests to validate the seamless interaction between the inventory system and other integral game components.
• Confirm that adding an item to the inventory results in accurate updates to the player's statistics and resources.
• Test how the inventory system handles interactions with quests, achievements, and other game subsystems.

3. UI Testing (Frontend)

• Leverage relevant UI testing libraries like Selenium or libGDX's built-in tools to assess the frontend of the inventory system.
• Validate the responsiveness of UI elements within the inventory (e.g., buttons, lists, tooltips).
• Ensure that the inventory's UI functions correctly and consistently across varying screen resolutions and orientations.
• Verify that UI elements react appropriately to item additions, removals, or modifications.

4. Regression Testing

• Implement a rigorous regimen of regression testing after each code modification to safeguard existing functionality.
• Automate test scripts to streamline the regression testing process.
• Reiterate all preceding tests to detect any unforeseen regressions.

Future Development

In the case that future development of this system was able to be done in later sprints, the features that would be implemented in order to enhance the inventory system in the game would be the following:

• Generic Inventory Class: Allowing every entity type to have its own inventory, allowing other entities or mobs to pickup items and use them, as well as opening the door for other entities such as machines to have their own inventory for upgrades. This could also extend to things such as shops as well.
• Refine UI: Refining the user interface to match that of the concept designs provided above in order to match the overall aesthetic of the game as a whole. This would be easy to implement by updating the JSON files governing the games design.