The last individual course at The Game Assembly makes it possible for the student to do a project related to an interesting subject of their choice.
Project and goals
The goal of my specialization was to write an editor for creating UI. I drew inspiration from UE4 and its UI editor UMG. My UI Editor was made in the group made game engine. The purpose of the project was to get more experience writing tools and building a new core system within an existing engine. I also wanted to have an MVP up and running as soon as possible.
Five weeks half time (20h/week)
Written in C++, with ImGui library
Compatible with game project engine
A tool that gives the user full control over creating menus and the flow between them
Moveable and resizable UI within the viewport
Quick iteration times, user can launch and test menus instantly
User can create splash screens
As my main goal was to create a tool for artists to make UI without any programmers involvement
I planned to implement a variety of features where the user could have a lot of freedom in making UI. What I planed to have in my editor was the features listed below, but also an interface made with ImGui that would be easy to understand for the user and to interact with.
Change of the interface
I wanted to have a similar viewport as the UMG editor in UE4, where the user could have the whole window size in a smaller area. This was deprioritized and I made some changes to the initial ImGui interface in the editor. Instead of having large windows on the screen that would only leave a small area for the user to interact with without moving the windows out of the way, I changed the windows to one small and two bigger ones that the user can toggle visible/not visible. All of the content is still there, but now the user can see all of the window areas they will be working on.
uI editor features
In the details window, the user can find buttons for creating a new default menu, save and launch. The launch button will show an actual menu state in-engine which gives the user opportunity to test buttons or events properly. The user can also choose to load a previously saved menu to edit or test via the launch button.
The hierarchy window show all of the active entities in the scene and each entity's individual components. The user can change the properties on components to customise the entities to their liking. By right-clicking on the entity the user has the options of deleting or copying an entity directly into the scene.
As a visible feature to help the user see which entity they are working on, the UI editor has a border on sprites and buttons to guide the user. This border also changes color when unselected, hovered or selected. In the future, I would like to add that the hierarchy also highlights the entity that the user hovers or selects.
Hover/selection on buttons and sprites
Launch of a menu
The user can easily add sprites from the assets in the details window. The sprite can be changed in numerous ways with help from the hierarchy. The user also has the opportunity to change the position and size with the cursor. The sprite gets a border in the UI editor to mark the sprites real size with the alpha included.
Border showing the
sprites real size
Resizing and moving buttons/sprites
The user can add a default button and in the button component, it's possible to do numerous different settings for the button. Like the sprites, it can be changed with the hierarchy and cursor. The user has full freedom of manipulating the position and size of the button but also the clickable area on the button. The buttons can also have a hover effect, where they change the sprite.
Adjustable click area on buttons
The buttons need events to work correctly, and the user can choose from many different events they want the button to do. The button can only have one event tied to it at the same time.
towards the MVP
One of my main goals was to have a minimum viable product early, giving the artist on the team time to give me feedback, so I could iterate on the UI Editor.
Early on I had some issues implementing the text rendering, so I had to kill that darling because I wanted to have time to create everything else. Halfway through the course, I realized I had to modify my game plan, not just only for the time-related issues but for taking the feedback from users into account. As sliders and checkboxes wouldn't have any purpose in the ongoing game project, I decided not to go forward with them and focused instead on making it possible for the user to have emitters for particles in UI scenes.
This project has allowed me to explore the process of implementing a core system for menus, in an already exciting game engine. I have learned that you some times have to correct your initial plan to fit both the time given and the feedback. I have learned a lot about creating something that will ease the work for the team and individuals. I have also learned the process of creating a tool that gives the user full control of creating the menus and the flow between those menus.