Loading of Assets via Path

Introduction via Problem

During the first sprint, work on map generation from drm files was slowed due to issues found when loading said files. Within the team, some copies of the game would operate with a working directory of 'source', whereas others would operate within 'source/core/assets'. This difference had the effect of causing relative paths to no longer resolve, creating NullPointerExceptions.

As loading custom files are an integral part of map generation, considerable work was put into resolving this issue for Sprint 2.

Problem Exploration

Initial Efforts

The initial idea for resolving the issue focused on the use of System properties to control the directory that the application would use as its working directory. This was quickly disregarded, however, as most sources of information recommend against this method for several reasons of concern, namely security and portability.

Following this, a cursory exploration of the libGDX AssetManager class was undertaken, to search for ways that the existing game could load assets without this issue. The search was focused on finding code that may have set the the relative paths to be built based on the assets folder, but this was not found, and so the idea was discarded.

Finally, libGDX's FileHandler class was experimented with, to understand how the gdx.file.local path variable resolved, however, this, too, was not helpful.

Guided

After the failing of the final idea from above, tutor assistance was sought out, and this resulted in two additional avenues to follow. These were a more detailed look at the existing solution through the ResourceService class, and to ensure that the location that the game was running from did not affect the directory.

The first option resulted in a somewhat lengthy, however promising chain of alterations that likely would have resolved the issue. The solution involved a series of alterations following on from the ResourceService class. The first step of this, would be to implement an additional method in this class, loadDRM() which would allow for the loading of drm files in an accessible and controlled manner. To do this, an extended AssetManager class would be needed, to handle the additional filetype for the drm files. As such, an interface to define how the drm file can be interacted with for loading would also be required.

Exploring the second option led to finding that launching the game without the use of Gradle's build and run commands, led to a change in user directory. That is while looking into where the game was launched from, the issue was also resolved by running the game with gradle arguments build and run.

Conclusion

As there were two solutions that could fix the issue, the implementation surrounding ResourceService and the Gradle arguments, a decision for which to proceed with was required. This decision was to proceed with launching the game with the Gradle arguments, despite the use of the ResourceService allowing for more extensible and safe code. This is because the amount of work required, given the duration of sprint remaining, did not seem feasible. However, this issue may be brought up again for a later sprint.