The forest map has been redesigned with different patterns of objects to serve as landmarks as the first step toward making navigation easier. The patterns are created with numbers of objects in close proximity as well as objects placed at extreme angles that are far enough apart to get a sense of direction from binaural audio. For example several trees close together, a spot with exactly 2 rocks and 2 trees clustered together, or a rock and 2 trees forming a straight line.
The start of gathering functionality has been added to tree objects. When the player enters within interactable distance of an object a sound will play indicating what the object is. If the object is interactable the sound will be different then if the object is an obstacle. If the player then inputs the interact key while within range of an interactable object that made the sound, another sound is played to indicate that an object has been picked up, then a counter is increased. This counter is for testing purposes and will be removed once the inventory system is integrated. Currently interactable distance is the same as distance for walking echo which indicates objects that the player is about to collide with.
The Inventory Menu and its feedback systems received a major overhaul. The codebase was refactored significantly and a new scene was created to handle audio processing in a more intelligent way. This scene was named “WhisperAudioQueue” and essentially its role was to permit sound effects and speech to be queued and played sequentially, while also allowing for the ‘left-right-whisper’ post feedback described in a previous blog post. This effort took a fair amount of design work and a few different implementations before it really materialized. However, the Inventory Menu interface is much better for it’s existence, and in fact other systems will benefit from this object as well.
Without going into the minutia, this object now allows audio feedback for menu interfaces to be issued in a way that permits for more complex combinations of sounds without the risk of unwanted clutter, overlap, clipping and a variety of other problems encountered previously. Thus, several aspects of this menu were improved significantly, including the crafting system which now alerts the user to which item is selected when it is marked. Additionally, unique audio feedback is issued when items are marked vs unmarked, and the name of an item which is the product of a successful craft is spoken upon being added to the player inventory menu. These are all small details but in aggregate they improve the user experience of this menu substantially.
A summary mechanic for the Inventory Menu was implemented which communicates three things: the number of occupied spaces in the menu, the number of unoccupied spaces, and a list of items marked to be crafted. While all of this information is useful, the third of these seems to be the most helpful and so if it comes to be recognized the other information creates frustration, this mechanic might be reduced to simply reading the names of marked items.
At this time, primarily what remains to be done with the Inventory Menu scene derives from the need to extract certain functionality to a separate Inventory scene which will allow smoother and more modular architecture in terms of controlling the way game-world resources are processed by different subsystems. There is also the consumption mechanic to be implemented, and a non-linear “help” feature is still to be finished. All of these things will be the domain of the remainder of the development interval.
Since the range of walking echo and interacting with an object are the same, within touching distance of the object, the sounds can become jumbled when the player gets within distance of the object. If too many triggers for sounds happen at the same time the resulting mess is undecipherable, but if delays are attached to sound players so that only 1 sound is played at a time then they may seem disjointed and the player may not connect the sound with the correct trigger.
One key mechanic is the “energy level” interface which communicates information about how many game-world resources have been consumed by the player avatar (which will increase the energy value) and how much damage has been incurred by the player avatar (which will decrease the energy value). This energy value was conceived in the form of a progress meter type widget. Designing any sort of ‘progress meter’ without visual representation has been one of the more challenging feats to tackle with the interface types available to implement. With a progress-meter widget, it was deduced the information being conveyed in essence is, the magnitude of some value is being presented relative to some total capacity. The exact manner in which to translate this to audio was not clear, but a few designs were drafted and the first of these to have complete form was implemented. In this implementation, a unique alert is played in the left audio channel and traverses to the right audio channel over a duration determined by the magnitude of the energy value. Thus, the more game-world resources the player has consumed (and let it be noted that different combinations of these objects via the crafting system will achieve different magnitudes of gain), the longer it will take this signal to traverse from one audio channel to the other.
This has a few advantages and a few disadvantages. The advantage lies in the spatial articulation inherent in this form of communication. The user can articulate something gradually increasing, analogous to visually scanning a progress bar from left to right. Of course, the downfall of this implementation is that it lacks any relative measurement. Because this magnitude-feedback is issued upon request by the user, and reflects the immediate state of the so-called energy level value, no mechanism exists to give an immediate comparison of progress. The player must be expected to remember the duration of the feedback for previous iterations, whether it took a greater or lesser duration to complete. There is also a bit of frustration involved with this type of feedback, as currently the more successful the player is in raising the energy level value, the longer the feedback must be endured if it is to be checked.
Some of the latter frustration seems to be mitigated by the ‘marginal’ feedback mechanic for the energy level. While the ‘magnitude feedback’ is issued only upon request by the user, marginal feedback is given every time the player experiences some interaction which alters the energy level value. That is, a certain sound effect is associated with an increase in the value, and a different sound effect is associated with a decrease. In this way, vital information is communicated to the player without crowding out their senses. Of course, the real stress test of feedback systems for all mechanics and game systems will be realized when all of these things are integrated, which is pending and in fact is expected to be complete by the end of the interval.
It may be the case after further integration of different systems and user testing that an alternative design for this mechanic will replace the current implementation. If that is what happens, details of the selected design will be given in a corresponding blog post. For now, let it be sufficient to say that some of the alternative designs included mechanisms to communicate a relative measurement. In essence telling the player what a single unit of progress sounds like, and then following up with the actual magnitude articulated by a pause lasting the duration of that initial unit multiplied by the value of the energy level.
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 . . .