Echolocation was changed from a sphere around each object to a sphere around the player object. The sphere around the player detects when a body has entered. Each body has an audio player attached to it as a child node that will play the unique sound of the object. This audio player is added to a list when the body is within the player’s echo range and removed if the body exits the player’s echo range. These changes allow for new objects to be created without needing to add echo functionality to each new type of object. Echolocation was originally tied to objects in order to facilitate sound being positioned from the object rather than the player, but adding players as children to the bodies allows both echolocation functionality to be in one place rather than everywhere else and sound to be played in 3d space.
Prominently, this week the crafting system was implemented as a feature of the inventory menu interface. As discussed during the previous blog, this system represents the most complex sub-interface within the inventory menu system, as it entails manipulating multiple options from a linear list in such a way that the combinations of items selected are significant and must be absolutely intelligible and unambiguous as far as the user is concerned. The initial concept was to implement a progressive system of “layered” lists, in which selecting one menu item to be crafted resulted in that item being removed from the list. The user would then be presented with the remaining items, where they could either select an additional item and continue the pattern, or revert to the previous state. Several problems were identified when implementation for this version of the system began. First, there was no clean way to remind the player whether a specific item had been selected already (and thus removed from the list of items which could be iterated over). Additionally, once the user was satisfied with their selection of items, it was not clear how to map the input by which the selections would then be processed. The first option was to remap an input used for a different purpose in the previous sub-state when the craft system was invoked. However, it was determined this greatly increased the risk of confusing the user as they would now have to consciously register sub-context changes from within the same general context (namely the inventory menu interface). The alternative design would be to map the ‘confirm’ input to a source not previously employed for any state in the inventory menu interface. However, this raised questions about the justification for having sub-states in the first place. It was clear a redesign of the crafting subsystem was in order.
The product of this redesign effort was a menu interface stripped of all sub-states, such that all interactions possible within the menu interface would be possible to engage from the same state. Eliminating the ‘layered list’ system removed unnecessary complexity in the logical progression of the menu, and would allow for a uniform experience when iterating through menu items to perform all possible operations. The same way a user can iterate through the linear list of menu items and provide an input to request an item’s description, the user can toggle whether an item should be marked to ‘craft’. Initially the plan was to provide specific audio feedback to indicate which items had been marked, but after concerns about crowding out the interface’s ‘audio real-estate’, it was discovered using haptic feedback (the weaker vibration motor in the DualShock 4 device) was an effective way to communicate this information. Now that the crafting system is functionally implemented, effort will be allocated to cleaning up and improving the UI and UX of the system, with particular mind paid to both the contents and sequence of alerts issued in response to user interaction.
In order to accommodate what will certainly be a growing set of game-world objects with corresponding attributes (types, descriptions, and craft-mappings), a JSON file was created to manage this data. Presently this file is loaded and processed directly within the Inventory Menu system logic, but there are plans to extract this process to a separate Inventory System which will interface between the game-world functionality and other ‘in-game’ interfaces. The hope is by configuring audio files and other details associated with game-world objects within a text-based data file, design and use of these objects will continue to be quick and convenient at scale, and the pitfalls of manually configuring individual objects within the editor can be avoided.
The sound files being used for echolocation are of low quality and do not have uniform settings such as volume and length. This makes it more difficult to differentiate between different sounds being played and thus difficult to understand the echolocation. The current sounds will have to be changed and edited to accurately convey the world to the player but for now they only serve to test functionality.
Having echo functionality attached to objects rather than the player made creating new objects time consuming. Since multiple different object types will have to be detected by different types of echolocation this would have made creating new locations and new object types needlessly difficult. Originally the obstacles themselves had a collision sphere detecting when the player body entered the range. However, when the same was added to the player body it was not detecting the obstacles. Originally I thought that obstacles were not being detected because they were a part of a grid map rather than their own bodies, however they were not being detected because they were instead created as areas which were not being detected by a body_entered signal. After creating new objects and changing the area around the player to detect areas echolocation functionality was moved to the player. With this discovery it may be possible to change the way obstacles are detected in a grid map as well.
In order to make movement easier to understand camera functionality was added. The player can turn the camera to the left or right, but up . . .
A significant amount of work was achieved this interval with regard to integrating the Map Menu with the game world context, building on the foundations . . .