Location System
Process
The design was formalized as a feature design document outlining the fundamental parts of the player experience, for example location markers being added to the map and the world design around where the location actor objects would be implemented.
A flow chart was created to show which steps the player would take for certain elements to trigger, as well as what the system would do in these situations.
The system concists of an Actor Component Location System, which is attached to the player character and logs the reached locations, an Location Actor Object, and a number of UI elements.
Location Actor
Each location is created as a child of a Location Actor Blueprint parent. The parent contains a number of variables, such as:
- Location name (text).
- XP rewarded for reaching the location (float).
- A condition registering whether the location had been reached (bool).
In the Location Parent Actor blueprint, the visual script was set up to control what happens when the player enters the collision sphere:
- First, the script checks if the location has been reached previously (as in: is the IsLogged bool true or false). If the player hasn’t reached the location before (the bool is false), the location is added to the Location System Actor Component and sets it to true, so that the UI and XP is not added repeatedly.
- The XP specified in the LocationXP float variable is then added in collaboration with a seperate Levelling System Actor Component.
- Lastly, a User Interface widget is created and added to the screen to feedback the user on what is happening in the system.
Since this script sets the bool to true, if the collision sphere is reentered, the script will simply trigger the false branch and do nothing.
Map UI
- The background “torn paper” image.
- The map, as an outline.
- A “Notes” section of post it notes.
The background and the notes are based on customized textures and elements, while the outline is drawn “by hand”.
In the graph section of the UI, the Event Construct event is utilized as well as one Custom Event for each location. The location related events gets the added locations from the Location Actor Component, adds the name to the Location Marker Text in the UI and if the IsLogged variable is true, the visibility of this Location Marker is set to Visible, thus adding the location to the map.
Since the game is paused and the player cannot move when the Map is displayed, there is no need to do this on tick, and only runs this section when the UI is displayed.
The system played out in the editor:
Strengths
- Using an Actor Component is a simple way to store the data on the Player Character, where other information such as XP, needs, or interacts are also stored. This seemed like a logical way to reach the data from one point.
- Implementing the Locations as children of a Location Parent Class allows for flexibility in edge cases, while still being able to control the main functionality (which is quite simple and straightforward) in one place.
Improvements
- The time the UI uses on discovery is currently displayed with the help of a “Delay” node in the Parent Location Blueprint. This means that anything added after the UI will only be executed after this delay, which will naturally cause issues should more scripting be added. This should be handled by a timer instead.
- In regards to the UI, a pass needs to be done on the structure to make sure that the hierarchy of the design is as clean and lightweight as possible. Future work also includes adding tooltips to the Location Markers and allowing the player to add the “Notes” to indicate places of interest on the map.
- Currently, the Location Markers are hardcoded, as in that a specific location has a specific box and will be set to visible manually. It should be investigated whether this can be generalized through variables and instances to streamline the process.
- Lastly, the Location Markers are checked if IsLogged and set to Visible every time the UI is constructed. Since it only has to be done once, there is no reason to run these on every construct. This should be rescripted. It is not a major issue when there are two locations, as in this example, but the solution will scale poorly.
Location System
Hobby Project
One of the player experience goals of this project was for “players to be curious about the world”. This location system is designed to encourage the player to explore, to navigate the game world and to give them a sense of spatial awareness in the game. The system contains a number of elements:
- Object actors with collisions to define locations in the world for the engine.
- UI elements to give feedback to the player for when a location is discovered.
- A map where locations to which location markers are added when a location is discovered.
The location system is also tied to an XP system which grants players XP on location discovery.