LogInFalk Sonnabend kindly discussed with us the important field of the game dev that is often left uncovered: UI Design for the tools used in the production.
Falk Sonnabend kindly discussed with us the important field of the game development that is often left uncovered: UI Design for the tools used in the production.
Introduction
80lv: Falk, could you please introduce yourself to our audience: where do you come from, what do you do, what projects have you worked on? How did you get into UI design for video game production software?
Hi, my name is Falk Sonnabend. I’m a Senior User Experience Designer on the CRYENGINE Sandbox team at Crytek GmbH. Initially, I joined Crytek as part of the UI team working on titles like Robinson: The Journey and Hunt: Showdown. But since I always had a passion for tools and workflow optimization, I took the opportunity two years ago to move to the engine team to help improve the editor.
Prior to working at Crytek I studied Bioengineering and Game Art and Animation and worked for game companies focusing on multiplayer shooters and browser-based MMOs. First as a 3D and Texture Artist, but later I took over the role of a UI Designer when there was a need for it.
Engine Editor UI Complexity
80lv: You probably hear this question a lot but why are the game engine interfaces so counterintuitive and complex? Is it really true or is it just the outcome of game developers being used to certain things and certain tool layouts?
Engine editors need to handle a big variety of systems and (sub-)editors. All with their own requirements, workflows, and users.
You have an Environment Artist who wants to quickly manipulate material properties. A System Designer who wants to change an NPC’s AI behavior. A Game Designer who wants to tweak the reward a player receives for an action. Or a Narrative Designer who wants to change how dialogue is triggered under a certain condition. There are so many of these examples. Animations, cinematics, level design, game logic, particles, sound, and so many more… everything is unique and requires its own way of editing.
So these editors can be complex, yes. Counterintuitive, maybe. Depends on who’s looking at them. Somebody who is not familiar with animation, in general, might be overwhelmed by the interface to set up a complex animation clip, while a Senior Animator might like the convenience of having everything at hand on one screen.
New Content: Communicating Its Functionality
80lv: How do you communicate to the developer how all the tools and new features work? When you look at the growing library of features, it can get pretty frustrating to understand each of them because there are just so many tools out there.
When we develop a new feature, big or small, we usually involve our internal developers early on. They request something completely new or an improvement to something existing. Then we start evaluating. Why was the request made? What’s the current workflow? Where can we see problems? And so on. Then we sketch, prototype, and test to see if it meets the expectations of our developers before we put it into the next release. After that, it’s often “only” about communicating that a feature is available now.
Every once in a while there are bigger changes to old systems that need a bit more communication. This is usually done through internal presentations or newsletters highlighting the most important aspects.
And of course, there’s engine documentation that users can refer to, including video tutorials and downloadable example projects, which are especially useful for novice and/or external developers.
Last but not least, there’s a lot of talking involved as well. When developers have questions, our front-end department is there to answer, whether verbally, through chat, or via e-mail. For external users, we are supported by our community management team who handle all the social media platforms, like Discord or our own forums.
Creating Unobtrusive & Helpful UI
80lv: It is said that the tool buttons should be placed somewhere on the periphery and the majority of the space should be the working area. Do you agree with it? How do you make the interface unobtrusive and helpful?
There are more reasons why an interface might be obtrusive or hard to use than just the placement of things. The size, shape, and color of your UI elements play a huge role in that too. Some users prefer darker interfaces, while others prefer them to be brighter. Or icons might be easier to identify when you use a two-color scheme (and text).
In general, I think it’s not a bad start to give the developers’ work the most screen space. But where you place buttons (or interactive elements in general) highly depends on the complexity and type of the tool or workflow. Easy access to material parameters is probably just as important as seeing what effect they give on the material preview for example.
But there’s more. Think of the information flow. Most people here read from left to right. So consider this when you design an interface for these people. You probably don’t want users to constantly move their eyes from left to right or top to bottom. Put information where the user needs and expects it.
A simple example in CRYENGINE would be our selection helpers. Press and hold the space bar to get help selecting objects. Release the key and the helper cues are gone. It’s not obtrusive, and it is easy to reach when needed.
Show information on demand:
By now users are used to certain layout standards. It’s quite common to see 3D or 2D viewports on the left side of the screen while properties are placed on the right and tools on the top/left side.
And at the end keep in mind that a lot of artists use two, three, or even more DCC tools to create their work. Maybe there are ways to make your tool a liiittle bit like the one they are using already so it’s easier to switch between the two (I’m looking at you, camera controls!).
New Features vs. Habitual Workflows
80lv: We all know that old habits die hard. When you start doing something in a certain way, it’s very difficult to go another direction suddenly. Could you tell us how you manage to persuade developers to alter their workflow when you introduce new features?
Most of the time we only change smaller details, like adding a shortcut to something that was tedious to get to or cleaning up something that was cluttered and confusing. Sometimes simply sorting a list alphabetically is all that had to be done. Naming things properly. These kinds of things.
And since a lot of aspects we touch are based on user feedback we usually don’t really need to tell them to use something we improved for them. Of course, we don’t always nail a problem right away, and sometimes there are bigger changes that need explanation. But for this, we have meetings, documentation, or tutorial videos. We also try to bring documentation and tutorials closer to the user by putting a link to them right into the tool they cover.
You are right though, there are always users that will stick to their old workflow. Which is fine if it allows them to do their job.
Adjusting UI to the Needs of Non-Professionals
80lv: What do you think are the ways to make UI more suitable for the non-professional artistic crowd and newcomers who like to doodle and draw for themselves as well as don’t have any programming skills. It must be extremely challenging.
Allow user errors and experimentation. Allow the user to get to know and learn your tool. Maybe limit the number of elements a user is exposed to in the default interface and allow later modification. Eventually, users will become better at using your tool. Maybe they want to see fewer buttons and use more shortcuts instead. Make the tool adapt to the user and not the other way around.
Allow users to modify their workspace:
Allow the user to concentrate on the creation, not the management of his tools — like brushes or assets. Maybe automate that as much as possible (and necessary!). When designing an interface, don’t just count the amount of clicks it takes to do a certain thing. In my experience, it’s rarely a good indicator. Structure, consistency (where it makes sense!), and performance (!) are more important.
Easing Repetitive Tasks
80lv: How do you help the developer with the repetitive day-to-day tasks and what are the trick designers use to make the instruments for it easier?
As I mentioned in the answer above, have developers concentrate on their primary task and make your tool as invisible as possible. And plan big. Don’t test ideas with one or two objects. The reality of a game level can be quite extreme, and things that used to work fine when designing and testing a new interface or feature fall apart as soon as they are confronted with 50,000 assets or instances in a level.
But we will also see different companies doing tests with machine learning algorithms and similar things. Let’s see how these will really affect the work of artists. Maybe they will simply turn into an additional tool that you have to use at the right moment. There are a lot of interesting projects on the web already. For example, Promethean AI, to name one.
I think ultimately artists will do even less petty detail work in the future and instead will be allowed (or forced) to concentrate on the bigger picture of their project.
Remember a couple of years ago how half an art department just painted scratches into brick and planks meshes to make them look more realistic? They spent so much time on these assets and after many hours of hard work they finished one of many thousand assets that make a scene. And that was seen by gamers for… a split second. Now that was surely fun to make (the first or second time) but it rarely made the project look much better on a whole.
Can Complexity & Accessibility Be Combined?
80lv: Why do you think it’s difficult to combine both technical complexity and accessibility in a single tool? What are the limitations here?
Wrapping a complex feature or tool with an easy-to-use interface is a lot of work. There are a lot of details you have to consider. Who is this tool for, how do you structure it, what flexibility does it need to offer, which combination of interface elements solve which problem, etc.
And sometimes you can simplify only so much. Take renaming a file as an example. You select something, hit F2 (e.g.), and enter a new name. Done, very simple. My dad can do this. And it’s probably all he needs. But what if you want to rename multiple (image) files, maybe from multiple folders, based on EXIF data. Suddenly the process is a lot more complex, and you need a dedicated tool/window for this. If this was what my dad had to use, he probably would never rename files.
Current Obstacles on the Way of UI Design
80lv: What restrictions and obstacles do the UIs of the modern tools face nowadays? Do you think we’ll ever eradicate the need for scripting?
This is a hard question. Off the top of my head, I’d say performance and speed. Sometimes you plan features so big or flexible that it requires you to track and edit so much data that, well it’s simply not feasible to implement. Usually, you need to step back at that point and reevaluate the actual problem you want to solve.
I’m a big fan of visual scripting since it allows people with little to no prior programming experience to create logic. Some people need this perspective. They need to be able to follow a line from one node to another. It’s like a whiteboard with sticky notes. It can help solve problems. I guess it’s like machine code versus programming languages. They technically do the same thing but one is easier to read and write than the other.
There are aspects that still create problems in visual scripting though. Keeping an overview of your graph with growing complexity is still a huge problem. Maybe there are better ways to visualize this than with 2D nodes connected with arrows.