.png?etag=W%2F%2226aa-679b4d21%22&sourceContentType=image%2Fpng&ignoreAspectRatio&resize=114%2B114)
Project info
Table of contents
Introduction
Zenithar is a first-person sci-fi game. For this project, I wanted to focus primarily on UI design. I built the entire game in Unreal Engine 5, relying solely on C++, no Blueprint scripting at all. Throughout development, I learned a lot and sharpened my existing skills, making this a valuable experience.
I used 3D assets from the UE5 Marketplace, while all 2D assets were created from scratch in the editor. The helmet in the HUD was a collaboration between me and a family member.
The core gameplay revolves around completing objectives by following the compass and carrying out the tasks given. As of now, the only challenge is figuring out how to unlock a sealed door.
In the future, I plan to expand the game by adding more objectives, providing players with additional challenges and tasks to complete.
WIP
For my graduation project at Futuregames I am creating an inventory system similar to games like Resident Evil and Diablo.
Game mode, Player character & Player Controller
The first thing I did in this project was set up the game mode, player character and player controller. I designed the game mode to use different game states, such as the title screen, main menu, and in-game state.
- Enum class with all game states
These states also handle the UI, when I for example press the "press to start" button on the title screen, it switches the game state to the main menu, hides the title screen UI, and add the menu UI to the viewport. The same logic applies while in the in-game state which is applied after the player presses "Play" in the main menu. If the player presses the ESC key while in the in-game state, the state changes to the pause menu, which pauses the game and brings up the pause menu UI.
For the player character, I implemented basic movement mechanics, including walking, running, jumping, and looking around. Later, I added inputs for viewing the current objective, interacting and for canceling interactions, such as closing a log or backing out of a keypad interface. The player character also has two components for health and stamina, which I created as separate scripts and communicate both with the player chracter and the player hud.
In the player controller script, I set up the ESC key to pause the game by changing the game state, but only if the player is currently in the in-game state. I also added public functions for enabling and disabling the mouse pointer when needed.
Menus
After setting up the game mode, player character, and controller, I started working on the menus. The first menu I tackled was the title screen. To keep things organized, I created a UUserWidget-inherited script called GUIBase, which serves as the foundation for all my UI scripts. The idea behind GUIBase was to have a central place for reusable UI code, avoiding unnecessary duplication across different scripts.
Titlescreen
With GUIBase in place, I then created the title screen script, which inherits from it. In this script, I added UPROPERTY members to bind UI elements like buttons directly in the editor. Since I wanted a consistent button style across multiple menus, including the title screen and main menu, I built a custom button widget. This custom button allowed me to change both the button’s background color and the color of the text inside it without duplicating a lot of code.
Once I had the title screen UI set up—including buttons, background elements, and other components—I bound them to their respective components inside the widget blueprint. Finally, I added functionality to the button. Its only job is to get a reference to the game mode and change the current game state to MainMenu, after which the game mode handles the rest.
Main menu
With the title screen complete, I moved on to the next menu: the main menu. The main menu is quite similar to the title screen, as it also inherits from the GUIBase script and utilizes the custom button widget I created.
This menu features three buttons:
- Play Button – Starts the game by switching the current scene to the Level 1 scene, which in turn updates the game state to InGame.
- Settings Button – Opens the settings menu by changing the current state to Settings, prompting the game mode to add the settings widget to the viewport.
- Quit Button – Simply exits the game.
Settings
The settings menu required more work compared to the previous menus. When the menu is added to the viewport, the first window displays a set of buttons that allow the player to navigate between different settings categories. The menu includes five buttons:
- Display – Opens the display settings window, which currently includes options for display mode, resolution, and VSync.
- Audio – Opens the audio settings window, featuring sliders for master volume and music volume.
- Controls – Opens an empty window that will later allow players to rebind controls.
- Accessibility – Opens an empty window where features like colorblind settings will be added in the future.
- Back – Closes the settings menu and returns to the previous menu.
- UPROPERTY member that is bound to the custom button widget
- Titlescreen UI
Since I had already set up GUIBase and the custom button widget, implementing the main menu was straightforward and efficient.
- Main menu UI
Since this menu contains multiple submenus, it required more structure than the previous ones, but it follows the same UI framework for consistency.
- Main menu UI + Settings UI
Settings - Display
When the Display Settings button is pressed, the display settings window is shown. However, before that happens, several initialization processes run in the code.
The first step is to initialize the settings:
- Display Mode – A TArray is created to store the available display modes. During initialization, the array is populated, and the current display mode is retrieved and set as the active selection.
- Resolution – Similar to the display mode, a TArray is initialized to hold all supported resolutions. The current resolution is also retrieved and set as the default selection in the UI.
- VSync – This is a simple check where the game settings determine whether VSync is enabled. The checkbox is then set to true or false accordingly.
Each of these settings includes an on-change function, which monitors user input and updates the corresponding settings in real time. However, changes are only applied when the Apply button is pressed, ensuring that adjustments aren’t immediately committed without confirmation.
Settings - Audio
Similar to the display settings, when the Audio Settings button is pressed, the audio settings window is displayed. However, before that happens, a few initialization processes run in the background.
Before setting up the slider initialization functions, I created a SoundManager subsystem, which is derived from the Game Instance. This subsystem stores the current volume levels and provides functions for getting and setting these values.
During initialization in the widget code, each slider retrieves its respective volume value from the SoundManager and updates its position accordingly.
Each slider also has an on-change function that detects adjustments. If a change is made, the new value is sent to the SoundManager to update the corresponding audio setting.
Before implementing these audio settings, I had to configure a few things in the editor:
- Created a Sound Class Mix – This serves as the main sound mixer.
- Created two Sound Classes – One for Master Volume and another for Music Volume.
With these components in place, the audio settings function correctly, allowing players to adjust volume levels dynamically.
- Display settings
- Audio settings
Pause menu
The last menu I created was the pause menu. Similar to the main menu, it uses the same custom button widget and follows the same approach for binding UI elements. This menu is added to the viewport when the player presses the ESC key while in the InGame state.
The pause menu includes four buttons:
- Resume Button – Closes the menu, unpauses the game, and disables the mouse cursor.
- Settings Button – Opens the settings menu, functioning the same way as in the main menu.
- Quit to Title Screen Button – Switches the level and sets the game state to TitleScreen.
- Quit Button – Exits the game.
By leveraging the existing UI framework, implementing the pause menu was efficient and consistent with the rest of the UI.
- Pause menu UI
Player HUD
After completing the menus, I moved on to designing the Player HUD, which includes several key features:
- Health Bar – Displays the player's current health.
- Stamina Bar – Represents the player's stamina levels.
- Compass – Guides the player by showing the direction of the objective point actor.
- Objective Box – Displays the current objective when a new one is assigned or when the player manually checks it. (Although not technically part of the Player HUD widget, it is added to the viewport alongside it.)
The Health Bar and Stamina Bar interact with the components attached to the player character using delegates, ensuring they update in real-time based on player status. The Compass provides directional guidance by tracking the location of the Objective Point Actor, while the Objective Box appears dynamically whenever a new objective is assigned or when the player presses the designated input to view their current objective.
Health & stamina bars
Both the Health Bar and Stamina Bar receive broadcasts from the respective Health and Stamina components attached to the player. These broadcasts provide the current health and stamina values, which are then converted into percentage values. The progress bars are then updated accordingly to reflect the player's current status in real-time.
- Player HUD
- Health & Stamina bars
Compass
The Compass is a single wide image with its center set as the zero point, representing the direction the player is facing. It rotates based on the player's camera rotation, ensuring it always aligns with the player's view.
To track objectives, I created a separate Objective Point Actor that the compass follows. The tracking works by calculating the objective’s position relative to the player using:
UKismetMathLibrary::FindLookAtRotation(PlayerCameraLocation, ObjectiveLocation);
This function determines the rotation needed to face the objective. The next step is to calculate the objective’s position on the compass by normalizing this rotation relative to the player’s current rotation.
The direction is then determined using the formula:
(CameraRightVector.DOT(RotationVector) / CameraForwardVector.DOT(RotationVector)
This value determines the Canvas Slot Position of the objective marker on the compass. To apply it, I cast the marker’s slot to a UCanvasPanelSlot and update its position dynamically.
This approach ensures that the objective marker smoothly moves along the compass, accurately reflecting the direction of the objective relative to the player's viewpoint.
- Compass with objective marker
To ensure the objective marker only appears when the objective is in front of the player, I calculated the angle between the objective and the player's forward direction using the arc cosine (acos) of the dot product between:
- The normalized location of the objective actor
- The normalized forward vector of the camera
If this angle indicates that the objective is behind the player, the marker is hidden from the compass.
This approach ensures that the objective marker smoothly moves along the compass while also preventing it from appearing when the objective is behind the player.
Objective
The objective box is a seperate UI widget that gets added by the game mode when called for. When the player overlaps a objective point the player gets a new objective by setting a game instance sub system that i called objective manager and then setting the current objective string to the new objective. Then after that it gets set in the objective box add the widget gets added to the viewport, which after a view seconds get set to hidden to hide the box. It can then be shown again if the player presses the input for showing the current objective. The objective can get changed everytime the player overlaps a objective point depening on if it has been set up like that. The objective point have been set up in a way so that it can give a new objective and what the new objective is supposed to be.
- Objective box
Log & Keypad
For the first objective in my game, I created a log and a keypad, both utilizing diegetic UI. Unlike traditional UI elements like menus or the first-person HUD, diegetic UI exists within the 3D world space, making it feel more immersive and integrated into the game environment.
The log serves as a clue for the player—it must be found and read to discover the code needed to unlock a door controlled by the keypad. The keypad allows the player to input a code, and if the correct sequence is entered, it triggers the door to open.
This approach not only keeps the objective engaging but also reinforces environmental storytelling by embedding the UI elements directly into the game world.
For the keypad system, I created a code generator script that generates a random 4-digit code each time the game is played. Both the keypad and the log reference this code:
- The keypad uses it to verify the player's input, unlocking the door if the correct code is entered.
- The log displays the code as a clue for the player to find and use.
This dynamic system ensures that the code changes with each playthrough, adding an extra layer of challenge and replayability.
Log
The log is a custom actor created in code, consisting of several key components:
- StaticMeshComponent – Represents the physical log object.
- PointLightComponent – Emits a green light to make the log easier to spot.
- WidgetComponent (Text Box) – Displays the log's text when interacted with.
- WidgetComponent (Input Prompt) – Shows a prompt when the log is interactable.
- BoxComponent – Detects when the player enters or leaves its interaction range.
Interaction Behavior
- When the player overlaps with the BoxComponent, the log becomes interactable, and the input prompt appears.
- Pressing the interact key displays the text box, while the input prompt is hidden.
- If the player moves away while the log is still open, it automatically closes.
- The cancel key can also be used to close the log manually.
- Once closed, the input prompt reappears, allowing the player to interact again or leave the area.
This system ensures a smooth and intuitive interaction flow while maintaining immersion in the game world.
- Log actor
Keypad
The keypad is a custom actor created in code, consisting of the following components:
- StaticMeshComponent – Represents the physical keypad object.
- BoxComponent – Detects when the player enters or leaves its interaction range.
- WidgetComponent (Keypad UI) – Displays the keypad interface, including buttons and the screen.
- WidgetComponent (Input Prompt) – Shows a prompt when the keypad is interactable.
- CameraComponent – Used to provide a focused view of the keypad during interaction.
Interaction Flow
-
When the player enters the interaction range (overlapping the BoxComponent), the keypad becomes interactable, and the input prompt appears.
-
Pressing the interact key triggers a camera switch using:
PlayerController->SetViewTargetWithBlend(Target, BlendTime);
This smoothly transitions the player's view to the keypad.
-
The keypad UI then appears, and the mouse cursor is enabled, allowing the player to interact with the buttons.
-
If the wrong code is entered, an error message is displayed, prompting the player to try again or search for the correct code.
-
If the correct code is entered, the controlled door unlocks, allowing the player to pass through.
This system ensures an immersive, interactive experience while maintaining smooth gameplay flow.
- Keypad actor
.png?etag=W%2F%2226aa-679b4d21%22&sourceContentType=image%2Fpng&ignoreAspectRatio&resize=90%2B90){kind=small}
Sean Schelvis
