World Traversal and Initial Events

World Traversal requires the following to implement:

• Nodes with connections
• Buttons
• Visual representation of the player (Sprite)
• Maintaining the state of the world after changing scenes and returning
• Maintaining the effects on the player between scenes
• Event management

Initially this was quite daunting as I was unsure on how I would go about maintaining the state of the scenes and the player. We had covered early on in the tutorials the use of setting and getting player prefs, I had considered this and thought a better approach would be to use singletons with both the player and the game manager persisting across scenes. This would allow for any effects on the player to be maintained on scene changes as well as storing node information within the game manager. For the nodes I had considered a few approaches where I would have an array of integers that would represent the positions in the world and the player's position. I decided the nodes should be their own class as they'd require information about what events would be triggered or effects on the player. I was reminded by the AI movement tutorial about connecting nodes and utilised simiilar methods for the player to move between nodes. 

Nodes with connections and Buttons

The node class holds a number variables that influence the event when the player traverses it. The have a list of different event and while at the moment they are static, in the future there will be randomisation added to them. 

They hold their own list of nodes that are the connected node. In conjunction with the player and an overworld manager. Only the connected nodes of the node where the player currently is will display their buttons for traversal, the buttons will only appear after the event has been completed to prevent any clicking of buttons when events should be taking place. I plan to replace the buttons with sprites that represent the event rather than a button with the event type written in future. In the example below you can see there is currently no event set up for the "Boss" so the next options appear. When the player moves to a battle, the scene transition commences and the next options will only appear once the player returns to the overworld scene.

Figure 1 - Navigation

Visual representation of the player

As mentioned earlier, the player is a singleton and the same sprite is used across the scenes. I had considered not having the player visible in the overworld scene and simply having the node selection but thought seeing the player moving through the world gave a better feeling of progression. As shown in Figure 1 the player moves towards the position of the selected node.

Maintaining the state of the overworld

What I mean by this is having the game "remember" the players position in the overworld when an event is triggered that takes them to another scene (i.e a battle or shop).  To do this I made a GameManager class as a singleton. This stores both the player's node position and the list of nodes. When changing scenes then returning to the overworld, the GameManager returns the player to the previous position.

Figure 2 - Scene Change

Maintaining effects on the player

Each event will likely have some form of effect on the player so the player details needs to persist throughout the game where there are scene changes as well. I followed a similar approach by making the player object a singleton. This way, any details of the player can be accessed in any scene. For example, in Figure 3 the player enters a battle and you can visually see the some of the player's health had been already been missing prior to being attacked in the battle.

Figure 3 - Player Persistence

Event Management

When the player traverses through the overworld, there needs to be some form of event that is triggered at each node. While the individual node will store the details of what type of event it is and other influencing variables, a separate event manager will handle what happens when triggering these events. In Figure 3 you can see when a battle is clicked on, the scene manager receives the information about the battle from the node, triggers the scene transition of the skull fading in and sets up the next battle scene. A similar approach will be implemented for further events. At the point in time the battle and a rest location have been implemented - at the rest location the player is healed for a percentage of their max health.

After some feedback from players, issues with aspect ratios in the build were identified. This has been remedied with a set aspect ratio in the current build.