Musspelheim

When designing the item system, I aimed to make the items as modular as possible. To achieve this, I implemented a hierarchical structure that supports reusability. This resulted in a parent script shared by all items, where most of the item logic is handled. 

Item statistics and behavior were separated into a Scriptable Object-based solution, with each item having a corresponding Scriptable Object. The process of creating these Scriptable Objects is described in the chapter covering the Item creation Tool.

With the item creation process, I wanted to implement it as a separate tool within Unity that functions as its own window, similar to the Inspector. To achieve this, I researched Unity Editor windows and identified two primary approaches for creating them from scratch: OnGUI and CreateGUI.

I experimented with both approaches but ultimately chose to use OnGUI instead of CreateGUI, mostly because there was more available documentation but I also found it easier to work with.

Once the tool had its core functionality in place and both the designer and I had worked with it for some time, I requested feedback. The primary feedback was that the tool was difficult to navigate and that finding specific items was challenging.

Based on this feedback, I analyzed existing systems within Unity that use similar layouts most notably the Hierarchy and examined why they did not suffer from the same usability issues. I found that sorting, both manual and automatic, played a significant role in improving navigation, which led me to implement similar systems.

This culminated in a folder based system where developers can organize items according to their needs. Items can be placed in multiple folders, and a basic sorting system was also implemented, allowing items to be sorted by name or by their assigned tier within the game.

The inventory needed to present all the information a player might require when deciding between items, while remaining easy to read and not occupying excessive screen space. With these constraints in mind, we designed a folding inventory system where the most essential information is always visible, specifically the item icon and its tier which is represented by the number of stars. More detailed information is only displayed when the inventory is expanded.

The different colors of the inventory segments indicate their effects: purple represents damage, green indicates healing, blue represents lore or combat-related movement, and brown signifies empty or non-usable slots.

The inventory played a central role in combat, as it was the interface through which the player selected which items to use and whether to activate their effects or movement ability. During combat, the player was always presented with three items to choose from and was required to select two of them. Each item could be selected once per turn, either for movement or for its effect.

To improve visual clarity regarding what was available, selected, or unavailable, I created several shaders. These shaders add an outline to the selected inventory slot, highlight and enlarge the currently selected item segment, and gray out inventory slots that are not available.

In order to make the world feel more alive and provide the player with additional activities, we decided to create interactive objects within the game world. How the player interacts with these objects varies depending on the object type, and by the end of the project we had implemented three distinct interaction types.

These interaction types are blunt damage, fire damage and key, each of which is tied to specific type items. 

When exploring and interacting with interactable objects, we wanted the player experience to involve more than simply interacting and moving on. To support this, I implemented additional mechanics tied to these interactions. One example is a minigame mechanic associated with the well, which rewards the player with an item upon success.