One of my main contribution for this project is setting up the structure for the various items. Each item consists of two components, a DataAsset which holds all the contant values relevent to an item, and a WorldObject which is the visiualzed item that can be placed in the world, and interacted by the player. There are few considerations when coming with this structure:
- Reduce memory usage - Similar to flyweight pattern, each WorldObject obtain relevant data from the DataAsset instead of storage a copy on themselves
- Tool creation - DataAssets are easier to modify in custom tools than Actors
- Appearance modification - Since each item have their own actor blueprint, modifications to size, offsets, or even adding more visual parts can be done in the editor
In our game, we have a tetris style inventory system where each item takes up different number of tile in a grid inventory. While modifying the occupying tiles and the icons of items through numbers is possible, it is time consuming. With this in mind, I created an item editor with the following features:
- Tile selecting and icon editing - This is the main feature of the editor, when a item is selected for modification, its icon is visualized on a small grid where develops can resize and move the item, as well as selecting the tiles it will occupy.
- Item creation - Simply the creation of an item to a few button click. This also connects all the necessary references for the item to work in the game and the item editor.
- Detail panel - This is a minor feature, but developers can modify the properties of the items in the item editor as well.
The airship is an essential part of the game, it is the main means of transportation for the player to explore buildings in higher altitudes. A lot of emphasis is put into creating the airship in order to make the movement more smooth and floaty to mimic the feeling of controlling an airship:
- The movement of the ship is done with more physical calculation, all movement and rotation start with an acceleration that affects the underlying velocity, which then affect the displacement of the airship.
- The height limits are also implemented in similar fashion where the airship does not come to an immediate stop when hitting the height limit, but rather have a stronger downwards force pushing the ship as it gets closer to the height limit.
During the implementation of the airship, we also discussed the possibility to have more mountables in the game, such as a sandglider for mid-distance exploration, and a harpoon cannon to hunt the creatures in the game. With the current controlling scheme, implementing future mountables would require a lot of repeated work. For this reason, I also re-planned the control scheme:
- PlayerController receives the direct input from the input system - Instead of having the pawns directly receive the inputs, the PlayerController first receive the input, and then calls the input responses on each pawn.
- MountableInterface - For a pawn to be mountable, it simply needs to implement this interface, the PlayerController will check, and store the pawn on occupation, and pass down the input to the interface when an input is received.
Half way through the project, we had some difficulties working with the inventory system:
- Scattered logic - All the logic are separated in different UI elements which makes it very difficult to pinpoint where might be causing issues and bugs.
- The InventoryComponents stored a direct reference to the WorldObject, but when an item is picked up, the WorldObject is also destroying in the process. This caused some unpredictable behavior such as inventory wipe and crashes.
After identifying the issues with the current system, the programmers had a meeting on different improvements and propsed the following changes:
- When item is placed into an inventory, it stores a reference to the DataAsset rather then to the WorldObject.
- The WorldObject is destroyed when picked up - The main reasoning behind this is that items tend to stay in some inventory (player's, chest's, etc.) once it is picked up
- We decided to implement the mediator pattern for this system - InventoryManager which act as the mediator for the communication between the InventoryComponent, and the UI. All logic also takes place in the InventoryManager rather than in different UI elements.
