Building a UI For the First Time
The Lessons Learned From a First Time UI Developer
With the release of Double Cross on the horizon and with new projects starting I think it would be useful to share some of the lessons that I learned throughout the UI development of the game. My role on the team was to both help design and build the art of the UI and then cut it up and place it in engine while also writing the code and systems to make it work. This was my first time doing anything to this scale and also my first time working in this area, so maybe my lessons can help you on your journey to being a UI developer.
Creating a Custom Input system and Button System
Double Cross was created in Unity Engine, and while the systems that exist for UI in Unity are a great jumping off point, I personally found that there was not enough control. For example, we were not easily able to map the L and R buttons on the Nintendo Switch controller to any menu functionalities. If we wanted to have any buttons outside of Confirm and Back mapped we would have to individually write that functionality into the menu reading in directly from the controller. For a while I argued with myself that I didn’t need to write a custom system for this, but as time went on and the menu systems started to get more and more fleshed out, I finally caved and built it based on Unity’s premade systems.
This doesn’t scratch the surface of what MenuInput can do but it does show the debug areas at the bottom!
In the end I had to throw out a bunch of what I had already made for the menus as they each were reading their own inputs, but it made iterating on the menus so much faster. This is because I was able to quickly remap functionalities to different buttons with in-engine controls instead of having to track it down in code. It also helped down the line when we added in interacting with NPCs, as I could use the Menu Input controls to block off other interactions while it was happening.
Implementing my own input system also helped me get past a very frustrating UI engine bug in Unity. This bug would be caused by turning on a button on the same frame that Unity’s system set it as selected. This ended up leaving the player visually selecting nothing on the screen but in reality they were selecting exactly what they should have been. Since I had this custom system that I had full control over added a very very small 1 frame wait between selecting a button and enabling it I could breeze past a bug that caused me a lot of headaches in previous projects.
All in all if I had just caved and written the system from the get go I would have had more time for iterating on the actual menus and not on fighting with Unitys systems.
Skeletons are your friends!
Iteration is key in game development. Every article, blog post, and game developer you meet at events will tell you that. What they don’t tell you is that iteration is a lot easier said than done especially when you don’t plan around doing it!
At first when I was building up the menus the process was:
Have a meeting with the designers to understand what the menu needed to do
Have a short talk with the UI visual design lead on what direction we want to take the menu in
Sit down and start designing the menu in Illustrator
Check in with the UI visual design lead to get a sign off
Cut an export the art needed into the engine
Test the menus out while writing the code to go along with it.
The issue with this pipeline is that the entire design team is left out of the loop until the very end! This led to a lot of work being done before we had a solid skeleton to work off of and therefore a ton of work was thrown away several times before we landed on a layout that worked.
Look at this! Its beautiful, and was enough to go off of to have a good discussion about usability that ended up changing the menu a lot but it was okay because no work was lost.
Later on down the line we made a much better pipeline taking into account those issues and were able to make new menu systems twice as fast as before.
Meet more with your UX Designers
Over the course of development I got it into my head that I could do all of the jobs that are centered around UI by myself. This is a horrible mentality to get into and in the end it cost me a lot of time and in general made me stress out a lot more than I really needed to.
A good example of this is in the Case Log system in Double Cross. Over the course of the game the player will gather clues in levels and they will be added to this screen. They also have to use information from this screen to make correct deductions during NPC interactions to progress the story along. Since this menu had so many different interactions within it, I tried to shove them all into the same screen. This was created in the midst of the old, bad pipeline what I outlined in the previous section.
One of the many variations of the Case Log, the transparent areas were scrapped as it was really hard to read it in brighter levels
After several sprints of making art and functionality, I ended up with a so-so looking menu and in general a horrible user experience. It was after going through the menu with the UX Designer that I ended up with not only a much better menu from a flow standpoint but also a good framework for the art work AND a way to clean up all the scripts that were lodged into the overarching Case Log system.
The lesson I learned from this is simply to make sure that you move all of the UI designs through the UX designer. I know some smaller projects don’t have a person specific to UX but taking the time to either have yourself or someone else on the team really learn it is integral in making a UI system that flows nicely.
Reuse anything and everything you can!
Most of if not all game’s menu systems are very consistent in how you interact with them. Double Cross has a pretty uniform menu system if I do say so myself. It consists of a main controller, several “panes” or subsections and then individual objects within those subsections. This allowed us to section off and organize information within each of the subsections in an attempt to show players that they were collecting different types of information (whether it be a profile, clue, or case file update). The important lesson that I learned here came at the end of the entire process when I realized I had written the same basic code 5 times for very similar menus.
If I had planned out my system better from the start I would have realized that all of my menus needed a base pane script that could have been reused. This would have saved me time in building new menus, debugging old menus, and would have made usability problems a lot easier to correct because a change in the base level did not require a change in all of the other menus.
To give an example of how I learned this lesson the hard way, I present the Case Log. In previous iterations of the Case Log the player was able to select the tabs at the top of the menu. This ended up causing extremely strange navigation and in turn the player was constantly lost when trying to understand the menu. After several different meetings, discussions and playtesting we decided to remove the functionality which was great for the menu but horrible for the person (me) that had to go through not only the Case Log but also the Upgrade Menu. This ended up taking double the amount of time that it should have and could have been completely avoided if I had set things up to be reused.
The art of reusing work is not only limited to the coding world either. Once we had the visual layout for the Case Log making the layout for the Upgrade Menu and all of the follow menus became extremely easy. It also lowered the amount of assets that we needed to import into the game because of Unity’s 9-slice system. Overall this saved us a ton of time with building visuals and left me a lot more time to correct the issues noted in the previous paragraph.
As you can see here, both of these menus have incredibly similar looks and functionality, this would have been a great time to reuse code and assets.
Concluding Thoughts
All in all working on the UI systems and visuals for Double Cross was a big challenge, especially as someone who had never taken on a project this large before. There are a lot more things that I learned from the experience, especially while working on the Dialogue system, but I see the four things that I wrote here as the most important things that I can hopefully others can take away from my experience and try to implement in their projects going forward. Good luck out there, always keep your stick on the ice.
Michael Nicoletti worked on the UI Development team during Double Cross as well as part of the Xbox One Port team for Runbow.
He is also an avid Virtual Car racing driver and all around car guy.