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 of the Inventory Menu interface integration achieved in the previous interval. With Map Menu, certain needs arose with respect to representing so called GameWorldWaypoint objects and GameWorldResource objects. While the already-in-place GameWorldObstacle class served as a good foundation for these things, ‘obstacles’ refer to objects allocated in a static manner as part of the defined structure of the 3D game world in the editor, via the Godot scene-tree mechanism. It is plausible ‘resources’ could be allocated in this same manner, however, necessarily based on functionality that has already been implemented, some subset of GameWorldResource objects are NOT statically defined. These are those that come to be as dynamically generated attributes of GameWorldObstacles, for those “obstacles” which in the language of the game mehcanics are “harvestable”. Harvetable obstacles are those which the player can interact with in a manner that extracts a “resource” and adds it to their inventory system (whereby it may be manipulated by all the facilities of the Inventory Menu described in previous posts). Meanwhile, GameWorldWaypoint is also a different case from GameWorldObstacle in that when the game is first initialized, NO such objects exist. It is only through the Map Menu interface that these are created, whereby they must be dynamically generated in a manner such that they have representation as 2D collision bodies on the Map Menu (as ‘markers’ that can be detected on that interface by the sliding map ‘crosshair’) and also representation as spatial bodies which elicit 3D positional audio feedback. This feedback will be the focus of the compass mechanic and is planned to be implemented in the next development interval. In any case, obviously neither GameWorldResource nor GameWorldWaypoint could be entirely modeled off of logic implemented for GameWorldObstacle.
Several designs were contemplated with regard to managing the data associated with these objects as it is communicated between different scenes. It was desirable to find a solution that did not produce tighly coupled code nor require vast amounts of processing every time the Map Menu was opened and closed. Here, the Godot node groups construct saved the day. Godot has a concept of groups associated with the aforementioned ‘scene-tree’ where by the nodes which compromise a given scene tree can be assigned to one or more groups in a manner determined by the developer. This can be done via the editor GUI or through scripting. Once such groups are determined, a method can be called in scripts to access all nodes belonging to a specified group. It may be worth noting in the context of this project, a single scene tree is being used to represent the entire active game state, with in-game menu interfaces added and removed to the scene tree as they are opened and closed. Thus groups were created to represent each of ‘obstacles’, ‘resources’ and ‘waypoints’ as well as to distinguish between GameWorldObstalce objects which are ‘harvestable’ vs those that are not. With this mechanism Map Menu is able to search its containing scene tree for all nodes in the ‘resources’ and ‘waypoints’ groups, create markers for these objects, and add references to the objects as attributes of the markers. In this way, updating a waypoint marker on the Map Menu can be used to update the actual 3D spatial position of the waypoint. Of course, this same attribute is utilized in the logic to determine 2D marker positions corresponding to 3D spatial positions (x coordinate is mapped to x, z coordinate is mapped to y, and as of yet no 3D gameworld object has a significant non-zero y coordinate but this would not be relevant to the Map Menu in any case). While this chosen solution still has some draw backs (markers have to be created every time the Map Menu is opened, though they could be cached in theory), it allows the Map Menu to be somewhat independent from the parent GameWorld scene and eliminates the need for the parent scene to call certain methods of the child before the child can function as desired.
Map Menu integration cannot be complete until some mechanism exists to extrapolate the area of the 3D plane representing the game world terrain to a 2D representation for the Map Menu, such that markers representing various objects in the 3D environment can be positioned accordingly in the 2D interface. The logic to achieve this result is already in place, but after discussion and investigation, it was realized the Godot “Gridmap” node structure used to represent the game world terrain did not possess any method or attribute by which to receive the desired information, at least not in any trivial manner. Rather than attempting to implement complex logic to extract the size of the 3D map, it was determined replacing the Gridmap node with an alternative which has sufficient attributes for getting the previously described desired result, would not result in any loss of functionality, potential future functionality, increased difficulty of development or generally any negative consequences. Likewise, it is planned to have this node in place early in the next development interval, thus enabling Map Menu integration to be complete soon there after. Of course, in order for this interface to be completely integrated, the compass feature and waypoint manipulation between the 3D gameworld and 2D Map Menu interface must be fully realized as well.
It would also be good to note, feedback from a demo session has been processed and it is pleasing to note, generally users seem to have been able to make sense of the experience to the extent which was expected, and complaints about short comings and potential solutions were largely anticipated. It is hoped that concerns raised will soon be addressed and the next demo session will see a much more engaging experience for testers.
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 . . .
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 . . .