The UI Programmer

First off, the role is very iterative! Lots of your work will be redone or thrown out. This is a normal part of the process, as the UI is one of the most player-tested elements of the game, and getting it right can make or break the game feel.

Game engines don’t solve all of the UI framework problems for you. Even with all the tools out of the box, there’s still a lot of foundational work you’ll need to do to set up and maintain your UI and input (Oh yes did I mention, you’re going to be doing a lot of input management too!).

There are a lot of considerations that you have to keep an eye on and ensure are covered by any designs sent your way. Many problems can be solved early if caught and fixed before implementation:

Does the design support all intended resolutions? Are we shipping on Mobile? Switch?
What is our smallest allowed font size? For Chinese characters?
Does the design support expected accessibility features? (all information covered by shape + color + sound..etc)
Does the design support all localizations? (Check if the text fits in German!)
Does the design support required screen buffer?
Does the UI work for gamepad, or is it built around mouse and keyboard? (i.e. Drag-dropping elements)
Do we need an alternate approach for gamepad (i.e. Balder’s Gate 3 style)
Check on expected accessibility features.
- Are we supporting colorblind mode?
- Dark/Light mode?
- UI scaling?

All of these form constraints on UI implementation. Not a bad thing, but something that as the programmer you need to watch out for.

You’re responsible for the visibility of a huge portion of the game mechanics, and as such many bugs mistakenly get assigned to you when in reality you’re just showing the result of something else broken. Don’t worry about this, just get used to forwarding bugs to relevant teams.

I know some juniors (and I did this myself) will often just go ahead and try and fix bugs because they’re assigned to them, but its a better use of time to pass them on and keep the focus on your own work.

I’m going to pass it over to Vlad Rakhmanin now, former UI Programmer at Romero Games for his insight into the role.

Pros
#

Why might a student want to pursue this role?

Your work is extremely visible in the game, which can be really exciting. Often times it’s the first thing that the player sees.
You also learn a lot about every other system in the game, as your UI generally needs to interact with code from lots of other developers in your team.
It’s also good if you are artistically minded, you get the chance to collaborate heavily with artists and designers on the UX and art, which can be really fun and satisfying.

Cons
#

Why might a student want to avoid this role?

UI is not a concrete science and designs change very quickly depending on user feedback.
You should be prepared to iterate very heavily, possibly more so than in other disciplines.
There are a huge number of edge cases depending on the hardware the user is using (i.e., monitor size / resolution, input method, etc.), which means that there can be very intense testing for even the smallest of changes to make sure that all players get the equivalent experience.

Example
#

Something you did in this role as an example of the kind of work you get to do?

I was particularly proud of the activity selection flow that I put together for the game that I worked on, which included a dynamically populated map system. It was extremely satisfying during our playtest sessions seeing players interact with my system from booting up the game all the way to starting a level, both in single player and multiplayer.

Student Projects
#

What kind of student projects would you recommend doing to prepare for this role?

Any UI heavy game, like a turn-based RPG, would be really helpful to learn the ropes. Specifically, what would really help is if you make sure that your UI is usable both with controller and mouse and keyboard, scales to different monitor sizes and is snappy / easy to use. If you really want to stand out, try creating a menu system for joining an online game using the Unreal Online Subsystem. This will help you to learn how to handle errors, develop asynchronous UI code and set timeouts for unresponsive networks.

Another project option: recreate an existing UI from scratch or revamp a UI that bugs you.

Resources
#

Specifically for Unreal, Ben’s Unreal Garden is invaluable. Their Discord community is really friendly and has people that actually worked on Unreal’s UI systems at Epic, they are usually quite good at replying to specific questions.

Aside from that, get comfortable with using design patterns like MVVM. There are many resources online for this, it doesn’t really matter which you choose as long as you are aware of how broadly your code should be structured.

The Lyra sample project is very helpful for seeing how Epic themselves structure this code.

The Game UI Database is a great resource for examples of UI across hundreds of games. For inspiration or quickly checking how similar games approached their UI, this website is invaluable.