Several changes were made to sounds in order to make the player experience easier to understand. Several sounds were either too quiet to hear over everything else happening at once or too similar to other sounds to tell the difference. For example the identifying sound of trees was the rustling of leaves, but this sound was too similar to the sound for bush which was crushing leaves, too long compared to other sounds, and too quiet to hear over footsteps. So the identifier for trees was changed to woodpeckers. Another change was the sound played when a resource was harvested. The original sound was created by picking a bag up off the floor. This is similar to other pick up sounds used in other video games. However in video games the sound is accompanied by a visual indicator that something was just picked up. With only audio cues the sound for pickup was too similar to the sound for footsteps. The sound was thus changed to coins clinking together, this sound is used often in games to signify picking up money. This fixes the original problem with sounds but it brings up some new ones. The pickup sound is now very different then the other sounds being used and seems to not be in the same theme as the others.
Primarily this week’s development pertained to integrating systems that have been developed thus far, particularly the 3D Game World with the Inventory Menu interface. In order to architect the integration in a manner that would scale well and permit molecularity and flexibility, certain functionality had to be extracted from the Inventory Menu scene and applied to a new scene called Inventory. As has been discussed briefly in previous blogs, we have determined the best way to manage configurations for so called “game world objects” (artifacts, obstacles, resources and way-points, each of these serving different purposes in the game) was through a single JSON configuration file. This file stores key value pairs representing each category of game world objects and information specific to each sub-type, including names for associated soundfx files and other values related to game functionality. This decision drastically simplified concerns about storing information for game objects, but left to be solved the question of where within the architecture would be the most appropriate place to deserialize the data, and moreover how to handle that data once deserialized. Decisions on this matter were made by analyzing the intended flow of data in the context of integrating all the separate systems. “Obstacles” represent structures the user can encounter in the active game state. They exist in the 3D environment and can be interacted with there, but nowhere else.
Thus configuration data for these objects, and the methods for applying that data, only needed to exist in the GameWorld scene which encapsulates and manages this part of the software. “Way-points” will exist both in the GameWorld and will also be relevant in the Map Menu (functionality for generating and manipulating these objects has actually already been implemented, as addressed previously on the blog). Similarly, “resources” pertain to things that initially exist in the game world but which, through the so-called “harvesting” mechanic, can be converted to a different type of object represented by the “InventoryItem” scene. In this latter form, they can be utilized by the player to perform various tasks, including special interactions with the 3D GameWorld, or through the Inventory Menu interface they can be crafted into new items or consumed to increase the energy level value associated with the player (this mechanic was discussed in a previous blog). Thus this represented another case where an object was utilized not only in the GameWorld scene, but also in a loaded menu interface. However, with the Map Menu and waypoint objects, all configuration data need only be loaded once, and from there data is merely passed around. With the Inventory Menu, objects are actually created and destroyed dynamically depending on user activity. So for now, it was determined configuration data will be deserialized and stored via the GameWorld scene. The Inventory scene is configured as a child node of the GameWorld scene, and receives a reference to the deserialized configuration data via a method invoked from the parent. A similar implementation was employed to provide Inventory Menu with craft-mapping data, the data utilized by the crafting mechanic to turn a selected combination of items into new items. This design came with some remorse, as if this method to pass configuration data is not invoked by the parent, the child scenes cannot ultimately behave correctly. A singleton design patter would allow all configuration data access to occur from a single source with no need to remember to invoke configuration methods. However, there are some concerns this single-source approach could potentially be at least as great a weakness as a convenience.
Finally, as a small note, a major refactoring of the directory structure was carried out so as to be much cleaner, structurally intuitive and far more pleasant to navigate.
Numerous challenges were encountered during this integration of functionality, certain aspects of which have been resolved and certain aspects which will be a primary focus of development going forward. Bugs exist which currently are not understood, and it is hoped the Godot Engine documentation will shed some light on these.
A demo release was built in which the user can navigate the Game World using current implementations of echo mechanics previously described. Resource objects can be harvested from obstacles and inspected in the Inventory Menu interface. The Map Menu is not fully integrated and thus not available in this privately distributed demo release. The three primary focuses of development going forward will be:
- To complete integration of all the sub-sytems developed thus far
- To eliminate persisting bugs
- To improve user experience as much as possible (soundfx quality, navigational factors, etc)
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 . . .