As assets began to make their way into the engine and become ready for use in the game, work on the initial core mechanics gradually came to a close. At this point I began working on the miscellaneous subtle tasks that would be required for the release-ready build of the game - namely sound, a menu with a variety of obvious graphical and audio options and a pause menu with scene travesal and quit functionality. I also continued my work on creating a variety of modular scripts that would serve as modifiers for existing assets to enhance the depth of gameplay.
My initial work on the main menu used a combination of the early first level scene assets as a backdrop, while using Unity’s tmeplate assets for the actual UI whilst waiting for art assets. I also created simplistic animated transitions for the menu panels & buttons to add clear visual feedback on selected and pressed buttons. Once the main menu assets were in place, I used coroutines to fade in/out a variety of elements and create the splash screen intro
Options and settings in the main menu are serialised and saved to a single JSON string to reduce the complexity of both extending the system and storing the settings -
//Serialisable class simplified for blog post!
[System.Serializable]
public class SettingsJson
{
#region Graphics
public bool m_fullscreen;
public int m_graphicsQual;
public int m_resolutionWidth;
public int m_resolutionHeight;
#endregion
#region Audio
public float m_masterVol, m_sfxVol, m_musicVol;
#endregion
#region Gameplay
#endregion
}
//Functions to save and load
bool LoadOptions()
{
string jsonData = PlayerPrefs.GetString("SavedSettings");
if (jsonData == "")
return false;
else
{
SettingsJson convertedData = JsonUtility.FromJson<SettingsJson>(jsonData);
m_currentSettings = convertedData;
ApplyOptions();
return true;
}
}
void SaveOptions()
{
if (m_currentSettings != null)
{
string convertedData = JsonUtility.ToJson(m_currentSettings);
PlayerPrefs.SetString("SavedSettings", convertedData);
}
}
While working in the options menu I also created an audio mixer group, with a ‘Master’ parent audio mixer and two sub mixers; SFX and Music. These mixer groups are applied to all sounds in the game and allow for easy manipulation of the various elements of audio with relatively little scene editor involvement needed.
I’ve also spent some time doing a mixture of both sourcing and recording (yes, that armadillo is me!) audio to add immersion and a more consequential sense of feedback in the game -
During this time I also created two scripts that would feature in several portions of the game world - a ‘killbox’ for ensuring that the player cannot reach intentionally inaccessible areas as well as creating deadly bodies of water that would kill the player, and a ‘force volume’ which we intend to use to create waterfalls, rivers and streams that the player can (and in some cases must) slide along to access other sections of the level, or that falling in may impede on the player’s progress by sending them back to an earlier area. Within these scripts I also created triggers for both the sliding and the drowning death state, to be utilised by the animators.
One problem we have faced is the reoccurring issue of indefinite choices of the jump mechanic, along with additional movement based mechanics. Because of thise, I have revisited the desing of my character movement and improved upon the elements that I found I was often reworking, in hopes to mitigate some of the loss of work. I’ve split the script into a base class containing the simple core character movement, while jump mechanics, slide mechanics and any additional states are in the new AdvancedCharacterMovement class, which inherits from and calls the MonoBehaviour functions from it’s base class. This interaction with a larger team and the people on the desing specialisation has helped me to look at the way I design my code with a much more incremental and modular perspective, helping to prevent larger losses of work should I choose to change something after initial implementation, so whilst poor definition and communication is a clear drawback to the team dynamic, I’ve personally found it to be a useful leanring experience.