Well a little later than planned, mostly down to some manipulation in the planning to better help the work of my day job, but this is the second dev log in the development of Draak & Draig. Even with the set backs of a very busy run in to Christmas within my work life we have still managed to stay relatively on track with the work and produce a build ready for testing. Thankfully I was able to use some time before the festivities to really hammer down the mechanics for the game and get everything into a playable state for testing.

Figure 1: Current state of the Jira roadmap for the project.

The Game

So the current state of the game is the the day loop is now in the game, the player can move around, interact with resource objects and NPC’s and is limited by the day time timer. All the required assets are in the game, including the user experience as well as some sound work. This has been completed by both Anouk and myself, with Anouk taking on a lot of the grunt work of laying out the levels and environments to allow me to concentrate on getting the mechanics working.

You can download the build from our itch.io page.

Player Controller

The Player Controller script has evolved at a good rate to fit with the different mechanics and aspects of the game. The major change is the introduction of the interaction mechanics and how the player controller handles this as the player needs to not move while interacting and have the mouse cursor returned so that they can actually perform the interaction. This was easily solved using an bool to place the player into an interacting state and then manipulating the movement code to stop them being able to move at this point. The interaction scripts then return the bool to false once they are completed.

There was also a need to add in a few new controls to fit with rhe new mechanics. A jump was added along with a mouse click listener to allow the player to click the interaction power bars. Thankfully with the new input system this is a simple task of adding in the button to the control scheme and then calling it through the Player Controls scripts. You can then just use a simple function to notify any scripts that the action was performed.

The finally major addition was to how the Player Controller works with the camera system. The camera moves with the mouse (as detailed in Dev Log 1) and it would always do this regardless if they player was actually allowed to move. What this meant was that the camera system would break when you entered and exited an interaction mechanic as the camera would continue to move with the mouse movements even though this was not reflected in the game (as you were actually in another camera the time). After some arguing with the code it was a simple solve by writing two new methods that switch a boolean that could be checked to allow the camera to move.

The current script is below.

The Game Flow

The next major part of the game to implement was the game flow and how the game manages the different objects and variables across levels. I wanted to make sure that both of us could develop content without having to wait for the release of files or scenes within Unity so adopted a prefab based approach to the development in order to make sure that this was possible.

First the day time environment was prefabs out which allowed Anouk to develop this completely independently of the scenes that it was in. As this environemnt will be used in most of the scenes this was a major change in the way we developed content for the game.

Figure 2: The day time environment prefab in Unity.

The next thing was to provide an object that would move between scenes that we could store all of the important game based information. This was done through a Game Manager script that does not destroy itself inbetween level loads, lives persistently in game and will only allow itself to be created once through the use of a Singleton.

A Singleton, as described by French (2021) is “…a globally accessible class that exists in the scene, but only once.” By using this on a script you can create a game object that will never create itself again if it finds an instance of itself in the game already. So I created the Game Manager script below and added it to an empty game object in the first scene that we use (the Main Menu scene). I added the DontDestroyOnLoad function to this script within the Singleton code so that it not only will not create itself again but will live persistently in the game even between level loads.

So with this implemented we were free to set up our level structure through various scenes and know we would be able to reference information from the different scenes by storing them in the Game Manager script.

Additionally we were able to add the UX Manager script to this object and store all of the Unity Canvas objects within it, meaning we are able to pull any aspect of the user interface up whenever we want.

User Experience

When it comes to the user experience there was a lot of work done across the game. All aspects of the daytime UX were added along with the script to control it. As previously stated this lives within the Game Manager object so that we can turn elements of the user experience on and off as we need them, and use them across different scenes. It is primarily run off several different canvas objects as this is considered best practice by Unity themselves. It also allows us to control elements a lot easier without the need to turn off large amounts of different elements.

Figure 3: ‘The UX manager scripts with its associated objects’

As you can see in the image above the UX script is quite detailed in what it is trying to achieve allowing for full customisation of different aspects of the user experience without the need for lots of different objects. It also heavily relies on text based elements to allow for localisation at a later date if required and can be called at anytime to manipulate UX elements as it is included within the singleton nature of the Game Manager.

The script itself is below.

The Interaction Mechanic

The final major part of the game that needed to be added was the interaction mechanics, of which there are two types, resources and NPC’s. The difference between the two interaction types are the mechanics that are loaded in once the player interacts with them however all interactables are driven through a single script.

This initial script is added to a prefab within the engine that can then be placed wherever we want an interactable to exist. We can then choose the type of interactable that we wil be using from the enum list, this then decides what other scripts are run subsequently when the player interacts. We can also set which interactable type prefab is loaded in and control the UX for when a player approaches it to give an instruction to interact with the object.

Figure 4: The basic interactable with instruction

If an NPC is chosen this launches the InteractableNPCManager script along with the NPC prefab. This script contains all of the dialogue driven aspects of the interaction along with showing these on screen with the canvas elements within the prefab. The prefab itself also contains all of the different NPC models so we can change the NPC at will if we require.

Figure 5: The NPC System

The resources interaction system works in a similar way it just launches a different script, the InterableGameManager, instead.

This script runs all of the different types of interaction games that are aligned ot the different resources. It also controls all of the animations and tools that are used by talking to scripts and animation controllers set up by Anouk. It is slowly becoming a sizable script but at this point it is complete so will not be growing anymore.

As you can see from the images it contains all of the different aspects required for the rock, tree and fishing mini games, it controls the user experience and reports back results to the Game Manager script.

Figure 6: The Interactable Resources system

Next Tasks

Our next tasks are to put the day time loop in front of a select few tested and record their feedback and how they interact with the game. Alongside this we are compiling a list of polish that we also want to perform to the game.

The next developmental stage is to move to the night loop. This will be a lot easier than the day time from a code point of view as most of the mechanics are extremely basic and do not need the complicated aspects of the camera system considering within them.

References

FRENCH, J (2021) Singletons in unity (done right), Game Dev Beginner. Available at: https://gamedevbeginner.com/singletons-in-unity-the-right-way/ (Accessed: December 29, 2022).

UNITY (no date) Object.dontdestroyonload, Unity. Available at: https://docs.unity3d.com/ScriptReference/Object.DontDestroyOnLoad.html (Accessed: December 29, 2022).

UNITY (no date) Unity UI optimization tips, Unity. Available at: https://unity.com/how-to/unity-ui-optimization-tips (Accessed: December 29, 2022).

Figures

Featured Image: Charlish, R (2022) ‘Draak & Draig’ Created on 12th October 2022

Figure 1: Charlish, R (2022) ‘Current state of the Jira roadmap for the project.’ Created on 29th December 2022

Figure 2: Charlish, R (2022) ‘The day time environment prefab in Unity.’ Created on 29th December 2022

Figure 3: Charlish, R (2022) ‘The UX manager scripts with its associated objects’ Created on 29th December 2022

Figure 4: Charlish, R (2022) ‘The basic interactable with instruction’ Created on 29th December 2022

Figure 5: Charlish, R (2022) ‘The NPC System’ Created on 29th December 2022

Figure 6: Charlish, R (2022) ‘The Interactable Resource system’ Created on 29th December 2022


0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *