About
This project is meant to be a template for me to use as a base for future projects. The key features in this template are:
A working settings system with common settings you would expect in most games. As development progresses I will add more settings to the project.
A UI System that allows for easier, more manageable, implementation of UI for projects, allowing more focus to go towards the gameplay.
Main Menu, Pause Menu, and a functional Settings Menu to interact with the implemented settings, all demonstrating use and practicality of the UI System.
This project uses my own UI Navigation System meant to simplify the implementation of navigating game menus, resulting in more manageable code and blueprints whilst also handling both Mouse and Keyboard/Controller input navigation, reducing the overhead needed to manage navigating with different kinds of input. This system is still an early prototype, but I may keep building upon it in future releases. Many of the core concepts of the system are inspired by JavaScript EventPropogation.
Along with giving me a template to build future projects off of, I am using this project as a way to learn as much as possible about the Engine. Before this project, most of my experience was as a Unity Game Developer. Although this project isn't much of a "Game", I have learned far more than I expected and already feel just as confidant with UE5 as I did with Unity. In some cases I would even say I feel more confident mainly due to developing a preference for the engine as I learned how to use some of the features lacking in Unity. One of my favorite features being the ability to have code run outside the scope of a level using the GameInstance or a custom SubSystem. Along with that I found UE5s implementation of UI, Input, UserSettings, and other simple systems to be easier to use than that of Unity.
Media
Backlog
Fix Audio when paused.
Fix resolution changes not triggering confirmation window.
More settings:
FPS Limit
VSync
Basic Quality Settings
Key-Mappings
Language Settings
Add scroll to custom combo box widget.
Make custom combo box select current selection when opened (Instead of selecting first option every time).
Navigation Bookmarks, allow marking specific widgets as important so its easier to navigate to them from anywhere, instead of passing a reference down multiple children. (Not fully committed to this idea yet. Might look at alternative solutions)
UI Redesign + more animations.
Disable resolution selection depending on current window mode selected.
Rework NaviWidget Input. Create one event instead of an event for each input action. Create an OnInputRecievedEventObject to hold information such as TriggerType, InputActionType, and a StopPropagation() function (this would replace DoesBubbleUp()). This should make the system resemble JS event propagation even more than it already does, which is probably the best direction to take it.
Rework NaviWidget Navigation. Similar to Input Rework, but not as high priority. Make one event, create an event object with all info needed, and StopPropagation(). StopPropagation will allow us to halt navigation. We need this for important prompts, like if the user has unsaved changes and they try to navigate away.
Remove conditional behavior from Tab Button. We have 2 distinct behaviors, just make 2 separate widgets and remove the confusing logic.
Stop using content switcher. It isn’t really necessary in the main menu, but should be kept in the settings menu.
Simplify NaviButton to be 1 to 1 with a normal button. Remove Size overriding or move certain features to a subclass.
Remove usage of NaviTextBoxButton. It is an old widget and should be easy to remove.
Create a simple system specifically for spawning prompt pop ups. Perhaps moving the prompts out of the setting menu widgets in the process.
Create Struct for NaviButton Style that is more representative of NaviButton States than the default button states.
Make changing NaviComboBox style change the style of all buttons in the combo box. Right now it is only set up for setting the style once before populating the options.
Try to break up the widgets containing Accept, Default, and Back buttons for settings. I’d like the logic for these to be directly in the settings menu.
Make navigation system compatible with base Slate widgets then move base navigation widgets to slate instead of Blueprints.
Experiment with Common UI, make use of it in example menus, or take notes and try making a similar implementation later. (I tried doing something similar using Data Assets before learning about Common UI). If I create my own style structs this might be more of a research task to see what features I want to mimic from Common UI.
Documentation on how to use the navigation system. (Holding off until a few more things are finalized)
Navigation System Debug tools. Tree visualization, exec commands, etc.
Prevent creating navigation cycles. There is nothing currently preventing a developer from parenting navigation widgets in a way that creates an infinite bubble up cycle. There may be a use case for doing this on purpose, but for most cases I think its better to just disallow using the system that way.