What’s This Button Do?
Lessons from an engineer’s adventures in UI
UI is a cornerstone of the development of any game. It is the first layer presented to the player, and as much as us engineers might wish we could just leave it all to UI artists to deal with, more often than not our support will be needed at some point in the process.
Working with UI is a subtly different experience than most other forms of collaboration open to a software engineer. While I worked on many student projects during my time at university, developing without a dedicated artist meant UI tended to be left by the wayside as everyone rushed to finish features and fix bugs, applying at best a small polish pass as products neared completion.
Because of this, being able work closely with UI in Mighty Bear Games as an Engineering intern has been a unique and invaluable learning opportunity. In this article, I hope to share some of the insights I’ve come away with after working with UI as an engineer.
Polish is king!
Unlike other engineering tasks, UI is about polish: the entire point is to ensure things look as good as possible while delivering exactly as much information as the player needs. It won’t do to implement something that is 90% correct, or in a way that risks “small” side effects. Tasks need to be done exactly to specification: you’re working on the very foremost layer of the game, so even tiny imperfections or mistakes that seem minor can seriously impact the player’s experience.
Of course, as an engineer, our eyes will never be as sharp and trained as those of a UI artist when it comes to these little lapses — though this also means that working with UI will help you develop a better sense of when something isn’t right. Before that happens, there are some steps you can take to avoid a neglected issue coming back to bite you or, worse, having to redo a whole feature.
Firstly, make sure you are extremely clear on the specifications. When your UI artist tells you what needs to be done, make sure to press for clarifications which address any assumptions you might have. Ask whatever questions you need, even those that might seem obvious. While things might look like they should be done a certain way to you, there might be specific requirements that make that approach less than appropriate.
Naturally, not everything you need to know will be apparent when you first start on a task — even after getting all the specifications straight. During the implementation stage itself, something might leap out at you: text might appear off centre, or there might be an ambiguity you didn’t think to cover before seeing the feature in practice. Take a screenshot or share your screen in a follow-up call: the UI element in question could just as easily be a mistake as intentional! Ongoing dialogue with your UI artist is key.
“Complexity” means something different to everyone
When your UI artists plan for tasks, they of course try to estimate how complicated they are for engineers to implement. However, since they don’t have any knowledge of the codebase and little to no technical training, they mainly use their experience of previous tasks and their own intuition to determine this. Unfortunately, many tasks can seem simple at a glance but, due to the way the data or other cogs and wheels interact, end up surprisingly complex. Moreover, a new task may appear to be similar in scope and effort to a previously implemented task, but due to an extra requirement or a difference in setup may be another story altogether.
Because of this, it’s important that you, or another engineer with deep knowledge of the codebase, sit in when these UI tasks are first being planned and scoped. This way, they can be refactored and time-boxed appropriately from the start. If along the way you discover the task is more complex than expected, escalate any issues as soon as possible. The longer it takes for them to be brought to attention, the less time producers have to reprioritise and decide if the task is even feasible for the milestone.
Once again, dialogue is crucial — don’t just sit on an issue and try to power through on your own. Tasks are planned and factored into a project’s roadmap assuming a certain level of complexity, and entire swathes of work may need to be adjusted if that assumption turns out to be off.
It’s not always the code
When bugs come back from your playtests, there’s a tendency to assume it’s a code issue, however in my experience there’s often a decent chance the problem is down to something wrong with the prefab or timeline. When investigating a new bug whose cause isn’t instantly obvious, do a few basic sanity tests before digging too deep into the code.
For example, if a UI object isn’t showing up in your game, check the prefab. Is everything that’s meant to be active set to active? How about the scale of the objects? Or even the opacity? When editing prefabs it’s possible a few accidental changes may be left in and allowed to slip through pull-request reviews, especially since prefab changes are so hard to read on GitHub.
You can also consult with your UI artist on how they implemented a feature: knowing which parts interact on the timeline and prefab side of things can help shed light on what’s going wrong. When I first started, there were times I’d spend hours tirelessly debugging code and checking each and every function and line before finally realising a component was disabled by mistake!
Communication, communication, communication
Keen-eyed readers will have noticed that every single point I raised in this article shares a common solution: constant communication with your UI artist. There are tons of small lessons you’ll pick up in the course of your work with UI, but almost all problems you encounter can be resolved — or indeed prevented — by communicating well and frequently. Thankfully, at Mighty Bear communication is held up as a core principle: my time here has trained me well in this area and been a crash course in its many benefits.
I hope this article has helped shed some light on what is often an under-examined area of working as an engineer. Hopefully with this info you too can survive UI Land!
What’s This Button Do? was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
