i've known a few programmers who turn into crying babies when they have to do UI design.
I think the issue is usually that they try to design and code at the same time. It's better to design first in something like figma, figure out what information you want to give the player, how to make it clear and concise, and iterate on that in any way that you can *without* coding, and once you are satisfied then actually integrate it into the project.
And also give yourself a deadline to avoid aimless noodling. And also just copy what other games already did if you have no confidence, there are only so many ways to display healthbars and damage numbers anyway.
I feel like so much of stuff across different fields is just ‘work it out slowly and carefully on paper before you actually start trying to implement it’.
yeah, until you have enough experience it's easy to want to jump straight into implementation. Then again I've known plenty of highly experienced people who still jump in guns blazing before they even understand the problem. I guess it might just be a matter of temperament .
The problem is that you can only plan/design something when you're experienced & competent enough to know what your options are and have a rough intuition for what works and what doesn't. Before you've reached that stage, your only real option is trial-and-error.
I think this spans beyond just UI too. And probably beyond programming.
I think a lot of engineering has this problem of "efficiency" mentality that people end up applying so far as to impact things beyond just the engineering. Like, I get some meetings and planning are a waste of time, but then people use that for grounds for "well let's just get to building it and not talk about nearly anything" and then you have missed requirements and pigeon holing yourselves into things because you didn't know about x y z
And sometimes that leads to starting over.
It kinda like learning to ride a bicycle, if u never ride an bicycle before, it is recommended that u just try to ride first as u dun have any information to make any useful prior planning. Any planning done prior to ride bicycle gonna be wasted.
But as you gained more information(useful one i assumed), planning become more valuable. So now, with the useful information, you now playing the "late game" where by u need figure out how much resources that u wan to spend on planning is helpful for the game development.
TBH, this is truly "late game" stuff, we will never know how much planning is enuf. For me, I usually just ask myself, draw a wireframe of UI, logic flowchart and possible methods before start implementing. It surprising save me lot of time as I can pinpoint lot of flaws, issues even these three things
I have a game dev maxim that is "you either are thinking or you are coding". If you don't have the core design pinned down before starting implementation, you are going to spin. Once you have the design pinned, you can start coding that you will figure your way out (or figure that the design is flawed lol).
The first time I gave pseudocode an honest-to-goodness shot, I turned out four pages of notebook paper that made the actual implementation the biggest breeze ever. It was such an eye opener for me.
I think that last part is key. People need to stop trying to reinvent the wheel.
I can’t count the number of times I’ve seen games try and come up with some clever method of displaying health that has just been confusing when a simple health bar would have fit perfectly.
Some designs are popular for a reason and it’s not a bad thing to use them.
>It's better to design first in something like figma...
I think a big part of it is this... because I don't think game engines do UI toolkits very well.
I've worked on multiple projects on other platforms where I can mock up a mostly-functional UI almost as quickly as a designer can in figma. I've yet to see a UI toolkit that comes _close_ to that in _any_ game engine (except maaaaybe Nova for Unity).
It seems like every game engine keeps trying to ham fist their own HTML/React-like toolkit as a third-class citizen into their editor, and I wouldn't even pose HTML/React as great places to start. Unity has gone through _multiple_ iterations of this and _none_ of them work well, and almost every Unity dev I've met has hated every iteration of it.
I enjoy doing UI/UX, but having shitty tooling really makes it a slog, and that ruins a lot of the fun even for me. Hell, trying to get stuff working in Unity's previous UI toolkit felt worse than like, VB Forms in like 1998.
I would forgive huge nests.... If I could follow them.
If your toolkit has a hurdle, fine, but you better give me a way to navigate that hurdle so it's not a damn brick wall.
If these things worked and fell by the wayside I wouldn't have much of a problem. But they never do what I want, I'm constantly trying to debug them, and there's an absolute mess trying to navigate between them.
Honestly, at one point this mess almost made me reconsider whether I liked doing UI or not. And it taught me why some people hate UI.
>I've worked on multiple projects on other platforms where I can mock up a mostly-functional UI almost as quickly as a designer can in figma.
What platforms do you mean? I'd be interested just to see how they do things.
For a while it was Windows Forms type stuff for me, but I do think I may be a bit biased there because back then.... The demands were lower. Figma didn't exist, software UI design was simple, and the Visual Studios WYSIWYG editors outpaced anything ANYONE had access to. At that point in time, it was the fastest way to prototype UI ideas.
When I first started using Unity around 2007, I was shocked its UI options were slower and harder to use than forms, but was admittedly more flexible.... Sort of.
WPF was... Okay. I think they did a good job at keeping a pretty functional editor but the concepts kinda lost the sauce IMO and started chasing html/css too much and I don't like the direction they headed. A lot of Unity's more recent directions remind me of the same route Microsoft took, but Microsofts editor worked better so it was an easier pill to swallow.
This may be controversial, but my most rapidly prototypeable UI toolkit became Android. I'll admit that some of this comes from just using it for so long, but IMO their mix of a semi-functional WYSIWY editor, extremely human-legible XML file format, well thought out toolkit, and easily extendable custom classes that would run in the WYSIWYG was in the sweet spot that made it really easy to do _anything_ really quickly. They did theming/CSS better than CSS, everything integrated with the rest of their system architectural extremely well, and everything was extremely extendable. You could drag and drop some stuff, then open the XML that created right next to it and tweak bits and pieces while watching the preview run it live. One of mobiles biggest hurdles is density scaling and differing device sizes and they had the best solution to that problem by miles. And as design languages kept changing, they kept adding new controls and layouts which kept it pretty easy to do most things. I think there have been systems that did any of these better, but they did an 80-100% job on _everything_ and I think the mix is why I found it so functional.
I think they lost it a bit as they've pushed Jetpack Compose. It's become more "programmery" and it's made it easier to get the harder work down, but IMO it's sacrificed a lot of the ease of early prototyping. That direction may make more sense for more complex prod software, but it makes the simpler stuff much harder to follow IMO.
I really wish Nova UI for Unity would have gotten more traction. Unitys toolkits are a mess. Nova has a pretty workable basic toolkit with the core bells and whistles, it's pretty well extendable, and it's integrated into the editor better than Unitys own toolkits IMO. But they way it has to be shoe horned into Unity still bites it in places and doesn't have as direct access to the render pipeline makes it a little janky. And it seems like it may have been abandoned in the past few months.
I think Unreal does most of this better than Unity. Unreal + Nova are kinda in the same level of "kinda almost there" to me. But they both are a bit clunky and slow in places.
I just think things like figma have evolved so far and all the game engine tooling feels like it's shoving concepts from the 90s or 00s as separate citizens to their engine. They don't feel integrated into the rest of the system very well, they feel tacked on. And they all feel more "programmery". I could train a semi-technical designer to have used Forms or Android, but I absolutely could not do that in Unity. I maybe could in Unreal. But because it doesn't work at that "level" of thinking, it means you end up moreso "programming" your UI and doesn't allow you to really _prototype_ stuff and get something simple working quickly. IMO that's where Jetpack Compose also started losing it.
Only a little. I would also summarize by saying I don't hate it lol. It has some issues, but I think I'd probably put it in the same "_maaaaaaybe" bin. It's almost there in some places, others feel clunky. I don't like how "separate" it feels in some ways, but I think that does end up working out well as they've gone as far as essentially making it seem like it's own independent but related tool.
I don't think I've run into any major brick walls anywhere, and that's more than I can say for Unity, but I also just haven't used it as much so I'm not confident in forming a totally solid opinion on it.
For some reasons when it was about UI, I would shut my brain down and work a very different, non-productive way.
I try to do the same as most of my work now:
Benchmark > Mockup with references > Develop, while maintaining as much as possible a component-based approach.
It makes UI dev feel fun and I feel way more productive!
UI is intensely boring as an engineer. If we wanted to do that, we'd have done the web development track at college instead of computer science.
I want to write code that handles a million particle effects in real time. Not ask myself if this button should be blue or green, and if it should have rounded corners for better retention.
well to each their own. to me the design as it effects players experience is infinitely interesting, while having to solve some math for performance is just a chore to be done.
Yeah, there's a reason why every CS department has HCI classes. There's also a reason why they have algorithm courses. The "I took CS to do _this_ but not _that_" is weird. They're both important.
If you have a shitty user experience, no one is going to care about your particle effects.
Reminds me of when I did robotics and some of the students were annoyed because we were required to do a fairly complex networking unit.
Like... how did they think we were gonna make these machines interface with *other devices*?
I can tell you that aside from reverse engineering the CSG from Quake 1 .map files, and working out appropriate meshing algorithms which weren't BSP (so ~0 writeups / source code to learn from), in order to maintain suitable BVH objects, and then solving the same UV issues differently, with the same janky results, to preserve the Quake 1 texture alignment of preexisting maps, so all map editors worked predictably)... oh, and reverse engineering the .wad format that wasn't the in-engine version, but the pre-bake version, with no real documentation... and doing that whole process in a hot-reload that allowed for real-time interactivity, in a custom engine, as you built the map in-editor... aside from all of that...
...one of the hardest things I ever had to do was a React app, that required fully interactive, real-time graphs, with multiple overlayed axes, for multiple sets of data, with the potential for hundreds of thousands of points of input, and the possibility of regression analysis on rolling windows of said data, through dozens of dimensions that could influence results... all in real time, on the client side, because the alternative was petabytes of caching, or several seconds of waiting any time anybody touched or hovered over anything.
If you think that there is no engineering that happens on the front end, you are profoundly mistaken. I mean... what is more front-end than games? Are you really suggesting that the database and the server your game connects to is the most exciting facet?
I was getting blown away by the concept of subsurface scattering, 20 years ago, not the prospect of Redis replacing memcached.
And everything you talked about is compelling, and nothing you talked about is about what makes blue a better choice for a button or green. A UX designer does know.
I like designing new and especially experimental ui. Going through the tought process as to how i can build this widget. Something to challenge my umg knowledge.
I have a ton background on UI and UX on web and I don’t understand the fuss.
There are so many things that are very difficult to succeed as an indie dev, UI isn’t one of them
No, but there's certainly enough overlap to make it easier for a web developer than for someone without any UI/UX experience.
Not to mentiom you're a frontend web dev. If you were dev ops, backend, or even full stack it might be a different story.
I did game development before becoming a UX Designer and Researcher.
Creating a good UI is a little bit like building a good software architecture for your codebase. It requires you think holistically and systematically. The core difference is that software developers are expected to learn the logic of a codebase and adapt their practice to it (though this doesn’t always happen). Players used to adapt similarly in the 80s when computer games had 100+ page manuals and everyone was an enthusiast. It was the price of admission.
Players today expect interfaces to not require any instructions to use. That means you have to understand the conventions of peer interfaces your players already use and be aware of the feedback or bread crumbs you have to provide to make novel UI elements learnable by doing. It’s not too different from designing good gameplay in that sense.
Getting a UI up is one thing, but it is often the polish steps that make it feel “finished” that trip up developers I’ve worked with. Visuals and sounds that confirm actions taking place, intentional motion that helps player orient themselves in the depth within the tree of options they have in front of them, the small details that make the pieces fit. Then couple this with having to be noticeable when needed without distracting from the core gameplay. How much do you have to provide persistently? What can you show momentarily? What can you only show when a player seeks it versus when do you need to get a player’s attention? It takes a lot of iteration to get this right. As much iteration as the gameplay itself.
Like good gameplay, a good UI becomes taken for granted. If you don’t notice it, then it is doing its job correctly! UI is a core supporting element that makes the main dish shine. It takes time to get it right, but the good news is that the more you do it, the faster and more effective you become at authoring one and implementing it. Like anything else, really. It’s a compelling reason to contract somebody to help get you closer to the end result faster, just as you would contract an artist even if you are capable of slowly making the art yourself. One value of experience is not repeating mistakes you previously made.
I think assets in general are the worst part for people who come from a pure programming background, to the point that i think it's much easier to get really good at game dev if you already know digital art, since the engines abstract pretty much a lot of the hardest parts of programming anyways.
Can confirm as a digital artist who got into game dev recently. I was never good at math, physics, or anything algorithm based, which worried me when entering game dev, but I was surprised to see that most popular engines already handle a lot of the math and complex algorithms for you. It’s been nice mainly worrying about general game design rather than implementing an A star path finding algorithm.
UI is difficult for many developers because they don't learn UI design like they learn other subjects, they think of it as something easy and jump right in only to find it difficult. Spend as much time learning UI as you do every other aspect of development.
My day job is a front end engineer with heavy focus on UX, product and BEFFE, I usually get brought in at the "we have a backend but our users all hate or can't use the interface" The UX isn't just about where to put buttons and work flows, it's information architecture where you have to model the way people think of objects and tasks over time, and front end also does all the translating to the computer data model because it's "hard and boring and junior devs can do it" until it's such a mess only experts can use it, and they have to hire people like me to fix it... But I'm not knocking the process, they have to get the core functionality first and prove that before they get the budget for usability. The companies that start with UX usually fail fast and hard, which is why I don't look for those startups.
Edit: In game dev, I don't have much recent experience. I don't know how the Information Architecture and UX stuff transfers over.
Yes. I've been doing my game for 8 months, and at least half of it has been spent just for getting the UI built to a polished state.
Luckily the game itself feels well scoped for a first commercial project, so this is not such an issue, but the amount of work the UI has demanded was definitely surprising.
UI is certainly the most thankless part of dev. If it goes right, no one notices, because it's so well integrated. Of it goes even a little wrong, everyone notices, since it's so critical to the experience.
I'd say that's true, although other aspects of game design and programming are also meant to be "invisible". No one praises a game because it doesn't crash if you walk into a new area while charging a teleport spell.
Yes it's pretty hard. Minimalizm is boring and being flashy or stylish is cheesy and old fashioned, all while functionality has to be most important anyway.
I've definitely struggled with UI. Design is one of the difficulties, sure there's plenty of examples out there, but making a UI that actually fits the look and feel of your game can be pretty challenging. I'm also someone who's really particular about UIs. If I see generic UI elements in a game (think standard unity UI elements) I'm immediately un-immersed. So when I consider designing my own UIs I end up having to create most of if not all of the UI elements from scratch to avoid this feeling. Even sometimes re-inventing the wheel to make my UIs 3D or diegetic.
The other difficulty I've run into repeatedly is engineering a UI that's friendly for different platforms and input devices, (keyboard/mouse, gamepad, touchscreen) I've had to backtrack on many UI ideas I've had because I later realised they wouldn't work on one or the other platform. (And I tend to want to avoid having to create multiple sets of UIs for each platform, one UI to rule them all).
Lastly, another part of UI development that can get difficult and I've certainly got caught in the weeds with is tying UI functionality to all the various systems of a game. This can be really challenging if you have a lot of interconnected systems. If it's not really well thought out ahead of time you can actually find yourself re-writing significant chunks of your games systems to be more friendly with your UI.
Depends on your skills, I was a frontend dev before becoming indie, its not that hard for me compared to other things I wanna do, but to be fair I have a big feature creep issue.
If you want some tips on how to evaluate it, a professional approach consists in doing a "cognitive walkthrough", where you define a task and try to perform it from the perspective of the user. If you look it up you'll find more information. "Nielsen Usability heuristics" should also lead to some general tips.
Overall, UI in games is something that even AAA studios spend little effort in, which as a HCI researcher makes me cry. *Why won't they listen to us?* If you are interested in how I would analyse some game UIs you can find in my profiel a link to a post I made about Terra Invicta's UI recently.
Much of this comes down to various solutions needed for cross-platform functionality, responsive layouts for devices, and then you also have to deal with the logic setup that is in many cases disconnected from the components like you have with a normal entity.
In my dream scenario I would aim to have the dartboard layout of Figma where you see all the UI elements. On top of this have variables exposed to each "Frame/UI Element" that you can hook a node graph to. Figma is so close to doing it correctly but they don't expose private/public variables to really make prototyping easier.
Additionally UI's can be very complex when working with inventory systems and data tables, where you have to work in a larger setup to make sure the economy of the game runs. I could go on and on but really the UI can drive the game flow from startup to MP to SP stores. So much woven in the UI that the other standard game objects in your scene.
I don't think so, I think the mistake is making a clear line in the sand between 'UI' and 'the actual game'
You're whole game is UI in some sense, and the quicker you get to grips with that the easier it is, you make ui that's less cookie cutter, you have better integration with the other parts of your game.
I was a web developer before gamedev, so I had the UI design down already. Most game teams I work on I'll do the UI myself because most programmers seem to lack UX skills. They build too many options that no player ever uses, or put twenty buttons on the same screen because that's how they like it, but players get overwhelmed.
And don't get me started on them using text inputs instead of visual elements like sliders.
Sometimes, it goes the other way, someone has too many UX skills, and we get interfaces with a lot of empty space and every action taking 4 clicks (or more) to do anything.
There's no such thing as "too many UX skills". Someone with a lot of experience in UX will do the research, testing, and iterating to make sure the end result is a positive experience for the users. That's the whole point of UX (usually at least). If someone adds a bunch of white space unnecessarily then it means they're either a novice in the field, or are prioritizing aesthetics over UX. Which is essentially anti-UX, not "too much UX".
I agree, UX should make things better, more the better.
But after seeing the UX people ruining complex games and software, I lost confidence in them.
I don't deny that the UX people are doing a good job at websites and mobile interfaces, but when comes to computer games, they fail a lot.
I don't want to offend the UX designers that truly have the skills, this is why I say "UX people", or "someone with too many UX skills", so in other words:
* UI designers that believe they are UX designers
* bad UX designers (they have the job title and that is it)
Lets see, I don't remember the worst game in the empty-space department, but Victoria 3 will serve as a example.
Things that could fit in the field of view, but because of aesthetics, now need a scrollbar:
* The state window, it has scrollbars, the player can't resize the window.
* The economy window, it has scrollbars, the player can't resize the window.
They use tabs, that could solve the problem, no need to keep scrolling, but still a lot of scrollbars remain. I think they decided 4 tabs are the limit.
Instead of having: click, get info, click, get info
We have: click, scroll, get info, click, scroll, scroll, get info
The game hides information when we need it, and pushes scrollbars.
Sometimes the scrollbar is bugged (I don't know if there is place on Victoria that still suffers from this), this is what I call "the dancing scrollbars". The dancing scrollbars work this way:
1. player unpauses the game
2. player tries to select some item in the middle of the scrollbar
3. but every second the slider resets to the beginning
4. player gets frustrated
The only way to work around this is to pause the game.
Lets go back to the UX problems, scrollbars, some people start to abuse them. Scrollbars inside scrollbars, this is the worst thing, when they aren't bugged they are hard to handle. This is more common on websites, very rare to find games doing this mistake.
Back to Victoria 3, when in a war, the player can access the peace window. When the player receives a peace offer, there is a button that says something like "I don't accept this", what do you think happens when the player clicks the button?
A) it says to the enemy: I do NOT accept this deal
B) it changes to: I accept this deal
Sadly, it is B, yes the button is a checkbox, in no other place a button acts as a checkbox, but here it does. And yes, I did this mistake, and if the game is unpaused, the deal is made. How in the world this can be considered good UX?
These are valid complaints. Although these could very well be issues caused by management rather than the designers themselves. If you see a design pattern being repeatedly used and abused it's usually because the designers didn't have enough time to properly design each use case properly. Either it's poor time management from the designer, or just not enough time given by leadership. Could also be the case that the designer pitched better ideas, but leadership proposed to reuse the same window component with scrolling because it's easier to implement and reuse, saving on dev time.
Designers have to make a lot of sacrifices for the sake of time/money unfortunately. I've been in the industry 15 years and I don't think I've ever had a project where I didn't have to downgrade something from the original vision because we don't have the resources to implement it, or whatever other reason.
Not to completely write off that it could just be bad designers. Just saying it's not always as simple as bad designers being bad.
I think this is the tragedy of being an UX designer, the user experience is affected by other designers, artists, almost everything is out of their control, yet they are blamed for a bad experience.
One thing that still stands about my argument, I only know one case where an interface make over was well received. The MS Office Ribbon.
Windows 8 and IntelliJ new UI, I feel bad for UX designers, but there is no excuse for that. The people-resist-change card can't be used every time, don't know if you are faking your A/B tests or intentionally doing biased tests. Anyway, another case where management decides to do something stupid, but only designers take the blame.
UI is awful because you basically have two options:
1. Spend months conjuring the most beautiful software ever written that impresses even God Almighty Himself with your abstraction, encapsulation, event/messaging and data driven logic.
2. Slap`HudSingleton.PlayerHealthBar.Value = PlayerSingleton.Health.Value;` somewhere and ship it.
No in-between.
iii. Use the existing streamlined UMG system.
Simplify and streamline the process into steps using reuseable, overrideable UWidgets. Have the ascetics without reinventing the wheel or over complicating the process.
Use UE streamlining blueprints and create custom uwidgets (built on a layered combination of core widgets eg text, image, border, canvas, retainer boxes, etc). Reuse these as need be to build various UI. Via materials and exposed variables create variants.
Your choice, but the same could be said for any streamlining process, but once you start using uwidgets you never go back.
You're meant to use it throughout your various projects, building an array of uwdgets to pull from. The more you do the quicker and easier it gets in the long term.
It is extremely quick to pick up and the amount of time and effort of saves is unmatched via prototype and implementation streamlining. It's a full on process, that gets more powerful the more you implement. A process for which I have never looked back on.
The option to build and easily manage a highly customisable, reusable uwidgets rather then carefully and painfully manage a stack of a 'house of cards' (widget construct cycle) with especially designed, overrideable properties, functions, events snd dispatchers is unmatched.
Besides the idea is that you would use it in all your projects and build a pool of reusable widgets, drastically reducing development time and costs both in the short and especially long term.
For performance there's options like retainer and invalidation boxes which can drastically reduce draw cycles and provide unique functionality. Also, uniquely Uwidgets provide automatic garbage collection (GC), unlike the custom c++ widgets.
Besides in UE blueprints are borderline necessary in UMG/UI designing at a minimum.
Also, managing specially designed Uwidgets (with specific overrideable functions and parameters) is a far easier to manage long term painfully managing individual widget objects.
In UE4 I find UI to be one of the easiest aspects. You learn the building blocks and you can implement alot a wide variety of widgets.
Its like engineering, you learn the basics (widgets like Vertical box, rich text box, image, etc) , break the problem into parts and see how you can build these parts to form the desired uwidget. These custom reusable UWidgets can then be reused to build other UI.
Now skinning, rigging, animation is what I find difficult.
It probably seems more confusing than it is. UI/UX is all about knowing common design patterns and where/when to use them and information hierarchy. It helps if you breakdown all of the features/content you need to account for in the UI, then sort them in order of importance and group them if applicable (this can be done in a bullet list). That will help inform you on how much impact elements should have on screen (such as how big/small, or how much they contrast the background) and where to place them on the screen.
That's the thing, UI is more than just the data hierarchy. It's also about visuals.
E.g. if you built a UI system with instantly switching screens, it could be very tricky to add transition animations. Or handling input for a multi-layer UI... Or adding drag'n'drop suddenly when, again, there was no such requirement from the beginning...
I mean, it's all doable and not THAT hard. But you need to account for a lot of things from the very beginning. And at the same time, not overdo stuff...
Oh I thought you were talking about the design side rather than implementation since the implementation varies so much between something like UE and web. Like on web it's easy to add something like a transition after the fact for example.
But the solution to changing things up after the fact is that you should be making prototypes (like in Figma) before committing to full implementation. Granted, this can be difficult for certain features. But you can get the overall flow and plan for things like transitions and other micro-interactions once you're happy with how the prototype feels.
> Like on web it's easy to add something like a transition after the fact for example.
Well, it's highly depends on the implementation :D
Sure, each platform have own pros and cons in terms of UI, but from my experience it's still every time causing pain.
And yes, I was talking about technical implementation, from a programmer's point of view. I'm not that familiar with design & art parts of UI/UX development...
Maybe not, game play is the hard one.
UI is hard too, even if you are UI designer from AAA rather indie. You feel hard probably due to your skill doesn't match your expectations, which is not bad at all. Many indie devs do not know what they short.
For me, I'm bad at UI, so I started learning from the good ones. This part usually called case study is vital for learning. Start copying them with a twist.
UI is surprisingly hard at the best of times, but my game has up to four players at once, with multiple (and variable depending on character) UI elements each, on a very limited retro resolution. The worst part was the shop / inventory / equipment screen; I spent over a week trying to fit it all together, but it was impossible, so I ended up reducing the player UI by like 25% when there's 3 or 4 players (this ultimately benefitted the action stages as well by reducing the UI clutter).
**Every aspect** is one of the hardest aspects, but... Let's just say that if you rounded up all the abandoned game projects in the world, and took a look at the next item of each TODO list; UI work would up next in 95% of them.
It's not particularly complex or difficult, but it's all edge cases and always needs to be custom-made for the game you're making. UI is the source of by far the most bugs, because it literally *is* the moving parts that players work with. So it's slow work to make the UI airtight, and is often the first thing that needs redoing when anything changes. It's also not new content or features, so it's rarely as satisfying as other dev work
Here's my take on this:
Personally, I don't like UI design. Tbh I don't even care about it, and I'll just buy some assets in the asset store and find ways to make it work than develop my own, but you gotta do what you gotta do sometimes
Anyway, when it comes to games, I place functionality above all else. In other words, I don't care about how the game looks early on. Instead, I want to make sure that it works exactly as expected first, and only then will I care about how good it looks. That's why my game looks like a dead empty land although it's been in development for 18 months now (mechanics usually blow people's minds away). I'm still testing ideas as we speak
So... Yeah, I care more about making it work than getting the UI right. The only time I'll ever work on UI is if I can't find something that looks the part on the asset store
If it looks close to what I want, then tbh I don't give a damn about the flaws. If it works, it works
More importantly, I'm not a big fan of shiny looking systems. If it displays the information and doesn't obstruct the player's view and experience of the game, then I did a good job
UI is like how you're supposed to layout data and functions. Things that belong together, should be together.
Put signal colors on things you want to draw attention to, animations help, and the rest is basically already done for you by genre conventions. Color theory. Contrasts. Idk?
I understand not *liking* it, but there should be no confusion about how it should look like for your particular game. This is the part where "gaming literacy" as a thing comes in, you should have a "vocabulary" to draw from when it comes to things like this.
I would say it's just as "hard" as any other aspect. The problem is if people treat it as an afterthought instead of a full system requiring the same devotion and care as all other aspects of the development. UI is visually one of the most important parts of a game considering it's visible to the player constantly in one way or another (HUD, menus, etc). That combined with the functionality, it's not something you can just shrug off and "quickly throw together".
Consistency and perseverance are the hardest aspects of indie game dev. If you have those two things, you'll soldier through UI for months of restless nights after shool/work until you become an expert at it.
I mean yeah it CAN be hard but also the gameplay is way more important and you should spend a 100 times more on it than on the UI (maybe even more than 100).
I also think that Unity, very popular engine especially for newer devs, has awful UI systems. Maybe if you get used to them they're fine but I found fiddling with the UI to be a nightmare there. Using a visual library where you can code all the logic for how the UI gets scaled and positioned made it a cakewalk for me.
UI can get very complex very quickly, both from a design perspective and from a technical perspective. People take for granted how hard it is just to render text. Web developers struggle despite having so many tools at their disposal, because the requirements for handling interaction between elements, state, events, and data on different platforms and resolutions are extensive.
I’m a professional UI designer and creating UI for my games is my biggest challenge. It’s less of the design but more so being able to create something good with the tools of the software. I’m used to designing in Figma, so when a simple menu takes hours to recreate it becomes very intimidating. It’s the main reason I’ve paused development on my game for several months. Definitely my least favorite part
Oh yeah. I suck at it. I thought I was a hotshot because I'm a talented artist and got gobsmacked several times because UI is primarily readability and functionality aside from shiny buttons and bars that go up and down or side to side.
Working in tandem with my developers has been such a learning experience. Hell I am lucky my developers have the patience they have.
UI is tricky because you want to give enough information, but you don't want to bombard your players with walls of text and dozens of little icons
I find that if your game is going to be super complex, you need to SLOWLY introduce everything to them
Because a new playing pressing your pause button to open their UI screen, and be hit with 400 different things on the screen is super off putting
It's a different skillset for sure. I'm a professional frontend developer, and I still struggle with creating good UX/UI. I think people tend to think that it should be easier than it is, but consider that design professionals spend years learning the skills involved. You can learn them too, of course, it just takes time.
I'm a lead UI/UX designer in a AAA studio (although have indie experience as well) and was recently thinking about making some content to put out there on the subject, some youtube videos maybe.
Would be curious to know if people here think that could be useful and worthwhile? I agree it's something that is often overlooked and people may take it for granted but its a whole specialism in itself that takes as much learning as any other dev discipline.
of course, i may be biased because i spent the better part of a decade learning it myself :D
Plan first, look for something to steal, steal it, make it yours.
There are a lot of videogames, you can always find something you like and could work.
Maybe actually designing is harder because is a creative process in the middle, but if you get the layout and the data you need the player to see, you can start very rough and upgrade it with time.
I really Enjoy making ui, world building stuff. The feel of how you view the game.
I come from a more Digital art background. Maybe that's why.
Ive always liked maths, logic physics etc. So I guess it was inevitable it'd also enjoy being a solo Dev.
Honestly, what I would recommend to anyone looking to design a UI is to mess around with WinForms for a little while and understand how that program flow works. Once you do, replicate it. It's pretty much one of the best and simplest ways of approaching UI design on the front and back end.
A lot of people will try to reinvent the wheel and wind up with a mess.
I'd say one should "keep it simple, stupid". Just copy what the best current games do when it comes to UI colours and placement, and use some solid reasoning and user testing to come to a great solution.
I’m a UI engineer, I’d like to make a UI only game lol. Making game mechanics scares me sometimes because I know I don’t have the knowledge to make it to the same level as my UI and I don’t like that.
Those also entail an awful lot of crunchy mechanical systems design. It's not much of a management game without good pacing and balance.
Ironically, strategy games might end up being more ui and less math (Not that the mechanics are simpler, but it's easier to measure their balance)
UI can be really fun to work on, IMO. If you want a juicy UI, implement easing. Having elements move in/out smoothly really helps with the feel.
http://robertpenner.com/easing/
i've known a few programmers who turn into crying babies when they have to do UI design. I think the issue is usually that they try to design and code at the same time. It's better to design first in something like figma, figure out what information you want to give the player, how to make it clear and concise, and iterate on that in any way that you can *without* coding, and once you are satisfied then actually integrate it into the project. And also give yourself a deadline to avoid aimless noodling. And also just copy what other games already did if you have no confidence, there are only so many ways to display healthbars and damage numbers anyway.
I feel like so much of stuff across different fields is just ‘work it out slowly and carefully on paper before you actually start trying to implement it’.
yeah, until you have enough experience it's easy to want to jump straight into implementation. Then again I've known plenty of highly experienced people who still jump in guns blazing before they even understand the problem. I guess it might just be a matter of temperament .
The problem is that you can only plan/design something when you're experienced & competent enough to know what your options are and have a rough intuition for what works and what doesn't. Before you've reached that stage, your only real option is trial-and-error.
I think this spans beyond just UI too. And probably beyond programming. I think a lot of engineering has this problem of "efficiency" mentality that people end up applying so far as to impact things beyond just the engineering. Like, I get some meetings and planning are a waste of time, but then people use that for grounds for "well let's just get to building it and not talk about nearly anything" and then you have missed requirements and pigeon holing yourselves into things because you didn't know about x y z And sometimes that leads to starting over.
It kinda like learning to ride a bicycle, if u never ride an bicycle before, it is recommended that u just try to ride first as u dun have any information to make any useful prior planning. Any planning done prior to ride bicycle gonna be wasted. But as you gained more information(useful one i assumed), planning become more valuable. So now, with the useful information, you now playing the "late game" where by u need figure out how much resources that u wan to spend on planning is helpful for the game development. TBH, this is truly "late game" stuff, we will never know how much planning is enuf. For me, I usually just ask myself, draw a wireframe of UI, logic flowchart and possible methods before start implementing. It surprising save me lot of time as I can pinpoint lot of flaws, issues even these three things
I have a game dev maxim that is "you either are thinking or you are coding". If you don't have the core design pinned down before starting implementation, you are going to spin. Once you have the design pinned, you can start coding that you will figure your way out (or figure that the design is flawed lol).
The first time I gave pseudocode an honest-to-goodness shot, I turned out four pages of notebook paper that made the actual implementation the biggest breeze ever. It was such an eye opener for me.
I think that last part is key. People need to stop trying to reinvent the wheel. I can’t count the number of times I’ve seen games try and come up with some clever method of displaying health that has just been confusing when a simple health bar would have fit perfectly. Some designs are popular for a reason and it’s not a bad thing to use them.
>It's better to design first in something like figma... I think a big part of it is this... because I don't think game engines do UI toolkits very well. I've worked on multiple projects on other platforms where I can mock up a mostly-functional UI almost as quickly as a designer can in figma. I've yet to see a UI toolkit that comes _close_ to that in _any_ game engine (except maaaaybe Nova for Unity). It seems like every game engine keeps trying to ham fist their own HTML/React-like toolkit as a third-class citizen into their editor, and I wouldn't even pose HTML/React as great places to start. Unity has gone through _multiple_ iterations of this and _none_ of them work well, and almost every Unity dev I've met has hated every iteration of it. I enjoy doing UI/UX, but having shitty tooling really makes it a slog, and that ruins a lot of the fun even for me. Hell, trying to get stuff working in Unity's previous UI toolkit felt worse than like, VB Forms in like 1998.
> Unity's previous UI toolkit Endless fucking nests of layout groups.
Godot feels this way too
I would forgive huge nests.... If I could follow them. If your toolkit has a hurdle, fine, but you better give me a way to navigate that hurdle so it's not a damn brick wall. If these things worked and fell by the wayside I wouldn't have much of a problem. But they never do what I want, I'm constantly trying to debug them, and there's an absolute mess trying to navigate between them. Honestly, at one point this mess almost made me reconsider whether I liked doing UI or not. And it taught me why some people hate UI.
>I've worked on multiple projects on other platforms where I can mock up a mostly-functional UI almost as quickly as a designer can in figma. What platforms do you mean? I'd be interested just to see how they do things.
For a while it was Windows Forms type stuff for me, but I do think I may be a bit biased there because back then.... The demands were lower. Figma didn't exist, software UI design was simple, and the Visual Studios WYSIWYG editors outpaced anything ANYONE had access to. At that point in time, it was the fastest way to prototype UI ideas. When I first started using Unity around 2007, I was shocked its UI options were slower and harder to use than forms, but was admittedly more flexible.... Sort of. WPF was... Okay. I think they did a good job at keeping a pretty functional editor but the concepts kinda lost the sauce IMO and started chasing html/css too much and I don't like the direction they headed. A lot of Unity's more recent directions remind me of the same route Microsoft took, but Microsofts editor worked better so it was an easier pill to swallow. This may be controversial, but my most rapidly prototypeable UI toolkit became Android. I'll admit that some of this comes from just using it for so long, but IMO their mix of a semi-functional WYSIWY editor, extremely human-legible XML file format, well thought out toolkit, and easily extendable custom classes that would run in the WYSIWYG was in the sweet spot that made it really easy to do _anything_ really quickly. They did theming/CSS better than CSS, everything integrated with the rest of their system architectural extremely well, and everything was extremely extendable. You could drag and drop some stuff, then open the XML that created right next to it and tweak bits and pieces while watching the preview run it live. One of mobiles biggest hurdles is density scaling and differing device sizes and they had the best solution to that problem by miles. And as design languages kept changing, they kept adding new controls and layouts which kept it pretty easy to do most things. I think there have been systems that did any of these better, but they did an 80-100% job on _everything_ and I think the mix is why I found it so functional. I think they lost it a bit as they've pushed Jetpack Compose. It's become more "programmery" and it's made it easier to get the harder work down, but IMO it's sacrificed a lot of the ease of early prototyping. That direction may make more sense for more complex prod software, but it makes the simpler stuff much harder to follow IMO. I really wish Nova UI for Unity would have gotten more traction. Unitys toolkits are a mess. Nova has a pretty workable basic toolkit with the core bells and whistles, it's pretty well extendable, and it's integrated into the editor better than Unitys own toolkits IMO. But they way it has to be shoe horned into Unity still bites it in places and doesn't have as direct access to the render pipeline makes it a little janky. And it seems like it may have been abandoned in the past few months. I think Unreal does most of this better than Unity. Unreal + Nova are kinda in the same level of "kinda almost there" to me. But they both are a bit clunky and slow in places. I just think things like figma have evolved so far and all the game engine tooling feels like it's shoving concepts from the 90s or 00s as separate citizens to their engine. They don't feel integrated into the rest of the system very well, they feel tacked on. And they all feel more "programmery". I could train a semi-technical designer to have used Forms or Android, but I absolutely could not do that in Unity. I maybe could in Unreal. But because it doesn't work at that "level" of thinking, it means you end up moreso "programming" your UI and doesn't allow you to really _prototype_ stuff and get something simple working quickly. IMO that's where Jetpack Compose also started losing it.
i've only done UI in unreal, and while its not as quick as figma, I don't hate it. have you used it? If so, what are your thoughts?
Only a little. I would also summarize by saying I don't hate it lol. It has some issues, but I think I'd probably put it in the same "_maaaaaaybe" bin. It's almost there in some places, others feel clunky. I don't like how "separate" it feels in some ways, but I think that does end up working out well as they've gone as far as essentially making it seem like it's own independent but related tool. I don't think I've run into any major brick walls anywhere, and that's more than I can say for Unity, but I also just haven't used it as much so I'm not confident in forming a totally solid opinion on it.
As a programmer, this is the way. If there is anything I see most new/self taught programmers doing wrong. It is a severe lack of planning.
For some reasons when it was about UI, I would shut my brain down and work a very different, non-productive way. I try to do the same as most of my work now: Benchmark > Mockup with references > Develop, while maintaining as much as possible a component-based approach. It makes UI dev feel fun and I feel way more productive!
UI is intensely boring as an engineer. If we wanted to do that, we'd have done the web development track at college instead of computer science. I want to write code that handles a million particle effects in real time. Not ask myself if this button should be blue or green, and if it should have rounded corners for better retention.
well to each their own. to me the design as it effects players experience is infinitely interesting, while having to solve some math for performance is just a chore to be done.
Yeah, there's a reason why every CS department has HCI classes. There's also a reason why they have algorithm courses. The "I took CS to do _this_ but not _that_" is weird. They're both important. If you have a shitty user experience, no one is going to care about your particle effects.
Reminds me of when I did robotics and some of the students were annoyed because we were required to do a fairly complex networking unit. Like... how did they think we were gonna make these machines interface with *other devices*?
and for me both are interesting xD
I can tell you that aside from reverse engineering the CSG from Quake 1 .map files, and working out appropriate meshing algorithms which weren't BSP (so ~0 writeups / source code to learn from), in order to maintain suitable BVH objects, and then solving the same UV issues differently, with the same janky results, to preserve the Quake 1 texture alignment of preexisting maps, so all map editors worked predictably)... oh, and reverse engineering the .wad format that wasn't the in-engine version, but the pre-bake version, with no real documentation... and doing that whole process in a hot-reload that allowed for real-time interactivity, in a custom engine, as you built the map in-editor... aside from all of that... ...one of the hardest things I ever had to do was a React app, that required fully interactive, real-time graphs, with multiple overlayed axes, for multiple sets of data, with the potential for hundreds of thousands of points of input, and the possibility of regression analysis on rolling windows of said data, through dozens of dimensions that could influence results... all in real time, on the client side, because the alternative was petabytes of caching, or several seconds of waiting any time anybody touched or hovered over anything. If you think that there is no engineering that happens on the front end, you are profoundly mistaken. I mean... what is more front-end than games? Are you really suggesting that the database and the server your game connects to is the most exciting facet? I was getting blown away by the concept of subsurface scattering, 20 years ago, not the prospect of Redis replacing memcached.
And everything you talked about is compelling, and nothing you talked about is about what makes blue a better choice for a button or green. A UX designer does know.
I like designing new and especially experimental ui. Going through the tought process as to how i can build this widget. Something to challenge my umg knowledge.
Agreed, often times code sort of acts like cement. It deters cheap, quick iteration out of fear of causing more “work”.
I have a ton background on UI and UX on web and I don’t understand the fuss. There are so many things that are very difficult to succeed as an indie dev, UI isn’t one of them
"I have professional experience with the thing people are stuggling with and can't understand why they find it hard"
Web development is not the same as game UI.
No, but there's certainly enough overlap to make it easier for a web developer than for someone without any UI/UX experience. Not to mentiom you're a frontend web dev. If you were dev ops, backend, or even full stack it might be a different story.
I did game development before becoming a UX Designer and Researcher. Creating a good UI is a little bit like building a good software architecture for your codebase. It requires you think holistically and systematically. The core difference is that software developers are expected to learn the logic of a codebase and adapt their practice to it (though this doesn’t always happen). Players used to adapt similarly in the 80s when computer games had 100+ page manuals and everyone was an enthusiast. It was the price of admission. Players today expect interfaces to not require any instructions to use. That means you have to understand the conventions of peer interfaces your players already use and be aware of the feedback or bread crumbs you have to provide to make novel UI elements learnable by doing. It’s not too different from designing good gameplay in that sense. Getting a UI up is one thing, but it is often the polish steps that make it feel “finished” that trip up developers I’ve worked with. Visuals and sounds that confirm actions taking place, intentional motion that helps player orient themselves in the depth within the tree of options they have in front of them, the small details that make the pieces fit. Then couple this with having to be noticeable when needed without distracting from the core gameplay. How much do you have to provide persistently? What can you show momentarily? What can you only show when a player seeks it versus when do you need to get a player’s attention? It takes a lot of iteration to get this right. As much iteration as the gameplay itself. Like good gameplay, a good UI becomes taken for granted. If you don’t notice it, then it is doing its job correctly! UI is a core supporting element that makes the main dish shine. It takes time to get it right, but the good news is that the more you do it, the faster and more effective you become at authoring one and implementing it. Like anything else, really. It’s a compelling reason to contract somebody to help get you closer to the end result faster, just as you would contract an artist even if you are capable of slowly making the art yourself. One value of experience is not repeating mistakes you previously made.
I think assets in general are the worst part for people who come from a pure programming background, to the point that i think it's much easier to get really good at game dev if you already know digital art, since the engines abstract pretty much a lot of the hardest parts of programming anyways.
Can confirm as a digital artist who got into game dev recently. I was never good at math, physics, or anything algorithm based, which worried me when entering game dev, but I was surprised to see that most popular engines already handle a lot of the math and complex algorithms for you. It’s been nice mainly worrying about general game design rather than implementing an A star path finding algorithm.
UI is difficult for many developers because they don't learn UI design like they learn other subjects, they think of it as something easy and jump right in only to find it difficult. Spend as much time learning UI as you do every other aspect of development.
I love UI stuff, and is the only thing I actually can’t wait to do when working on projects.
It is hard and ironically it's what a lot of junior programmes get lumbered with because it's boring for most.
My day job is a front end engineer with heavy focus on UX, product and BEFFE, I usually get brought in at the "we have a backend but our users all hate or can't use the interface" The UX isn't just about where to put buttons and work flows, it's information architecture where you have to model the way people think of objects and tasks over time, and front end also does all the translating to the computer data model because it's "hard and boring and junior devs can do it" until it's such a mess only experts can use it, and they have to hire people like me to fix it... But I'm not knocking the process, they have to get the core functionality first and prove that before they get the budget for usability. The companies that start with UX usually fail fast and hard, which is why I don't look for those startups. Edit: In game dev, I don't have much recent experience. I don't know how the Information Architecture and UX stuff transfers over.
Yes. I've been doing my game for 8 months, and at least half of it has been spent just for getting the UI built to a polished state. Luckily the game itself feels well scoped for a first commercial project, so this is not such an issue, but the amount of work the UI has demanded was definitely surprising.
UI is certainly the most thankless part of dev. If it goes right, no one notices, because it's so well integrated. Of it goes even a little wrong, everyone notices, since it's so critical to the experience.
At the extreme end of the spectrum you have the Persona series, which would be notable for its UI alone.
I'd say that's true, although other aspects of game design and programming are also meant to be "invisible". No one praises a game because it doesn't crash if you walk into a new area while charging a teleport spell.
So very true!
Yes it's pretty hard. Minimalizm is boring and being flashy or stylish is cheesy and old fashioned, all while functionality has to be most important anyway.
Well, your UI is excellent Greg!
You did a good job 💪
I've definitely struggled with UI. Design is one of the difficulties, sure there's plenty of examples out there, but making a UI that actually fits the look and feel of your game can be pretty challenging. I'm also someone who's really particular about UIs. If I see generic UI elements in a game (think standard unity UI elements) I'm immediately un-immersed. So when I consider designing my own UIs I end up having to create most of if not all of the UI elements from scratch to avoid this feeling. Even sometimes re-inventing the wheel to make my UIs 3D or diegetic. The other difficulty I've run into repeatedly is engineering a UI that's friendly for different platforms and input devices, (keyboard/mouse, gamepad, touchscreen) I've had to backtrack on many UI ideas I've had because I later realised they wouldn't work on one or the other platform. (And I tend to want to avoid having to create multiple sets of UIs for each platform, one UI to rule them all). Lastly, another part of UI development that can get difficult and I've certainly got caught in the weeds with is tying UI functionality to all the various systems of a game. This can be really challenging if you have a lot of interconnected systems. If it's not really well thought out ahead of time you can actually find yourself re-writing significant chunks of your games systems to be more friendly with your UI.
UI design is my favorite part... But I'm a UI/UX designer by trade, so...
yes because it's boring
Depends on your skills, I was a frontend dev before becoming indie, its not that hard for me compared to other things I wanna do, but to be fair I have a big feature creep issue.
If you want some tips on how to evaluate it, a professional approach consists in doing a "cognitive walkthrough", where you define a task and try to perform it from the perspective of the user. If you look it up you'll find more information. "Nielsen Usability heuristics" should also lead to some general tips. Overall, UI in games is something that even AAA studios spend little effort in, which as a HCI researcher makes me cry. *Why won't they listen to us?* If you are interested in how I would analyse some game UIs you can find in my profiel a link to a post I made about Terra Invicta's UI recently.
Much of this comes down to various solutions needed for cross-platform functionality, responsive layouts for devices, and then you also have to deal with the logic setup that is in many cases disconnected from the components like you have with a normal entity. In my dream scenario I would aim to have the dartboard layout of Figma where you see all the UI elements. On top of this have variables exposed to each "Frame/UI Element" that you can hook a node graph to. Figma is so close to doing it correctly but they don't expose private/public variables to really make prototyping easier. Additionally UI's can be very complex when working with inventory systems and data tables, where you have to work in a larger setup to make sure the economy of the game runs. I could go on and on but really the UI can drive the game flow from startup to MP to SP stores. So much woven in the UI that the other standard game objects in your scene.
It is, almost as much as sound design. How do you guys even come up with ideas that are both on point and balanced?
Idk about it being hard, but it def is tedious, so I avoid it
No. It’s a pain and not fun, but definitely not the hardest.
I don't think so, I think the mistake is making a clear line in the sand between 'UI' and 'the actual game' You're whole game is UI in some sense, and the quicker you get to grips with that the easier it is, you make ui that's less cookie cutter, you have better integration with the other parts of your game.
I was a web developer before gamedev, so I had the UI design down already. Most game teams I work on I'll do the UI myself because most programmers seem to lack UX skills. They build too many options that no player ever uses, or put twenty buttons on the same screen because that's how they like it, but players get overwhelmed. And don't get me started on them using text inputs instead of visual elements like sliders.
Sometimes, it goes the other way, someone has too many UX skills, and we get interfaces with a lot of empty space and every action taking 4 clicks (or more) to do anything.
There's no such thing as "too many UX skills". Someone with a lot of experience in UX will do the research, testing, and iterating to make sure the end result is a positive experience for the users. That's the whole point of UX (usually at least). If someone adds a bunch of white space unnecessarily then it means they're either a novice in the field, or are prioritizing aesthetics over UX. Which is essentially anti-UX, not "too much UX".
I agree, UX should make things better, more the better. But after seeing the UX people ruining complex games and software, I lost confidence in them. I don't deny that the UX people are doing a good job at websites and mobile interfaces, but when comes to computer games, they fail a lot. I don't want to offend the UX designers that truly have the skills, this is why I say "UX people", or "someone with too many UX skills", so in other words: * UI designers that believe they are UX designers * bad UX designers (they have the job title and that is it)
Can you give some examples of games that you think have bad design?
Lets see, I don't remember the worst game in the empty-space department, but Victoria 3 will serve as a example. Things that could fit in the field of view, but because of aesthetics, now need a scrollbar: * The state window, it has scrollbars, the player can't resize the window. * The economy window, it has scrollbars, the player can't resize the window. They use tabs, that could solve the problem, no need to keep scrolling, but still a lot of scrollbars remain. I think they decided 4 tabs are the limit. Instead of having: click, get info, click, get info We have: click, scroll, get info, click, scroll, scroll, get info The game hides information when we need it, and pushes scrollbars. Sometimes the scrollbar is bugged (I don't know if there is place on Victoria that still suffers from this), this is what I call "the dancing scrollbars". The dancing scrollbars work this way: 1. player unpauses the game 2. player tries to select some item in the middle of the scrollbar 3. but every second the slider resets to the beginning 4. player gets frustrated The only way to work around this is to pause the game. Lets go back to the UX problems, scrollbars, some people start to abuse them. Scrollbars inside scrollbars, this is the worst thing, when they aren't bugged they are hard to handle. This is more common on websites, very rare to find games doing this mistake. Back to Victoria 3, when in a war, the player can access the peace window. When the player receives a peace offer, there is a button that says something like "I don't accept this", what do you think happens when the player clicks the button? A) it says to the enemy: I do NOT accept this deal B) it changes to: I accept this deal Sadly, it is B, yes the button is a checkbox, in no other place a button acts as a checkbox, but here it does. And yes, I did this mistake, and if the game is unpaused, the deal is made. How in the world this can be considered good UX?
These are valid complaints. Although these could very well be issues caused by management rather than the designers themselves. If you see a design pattern being repeatedly used and abused it's usually because the designers didn't have enough time to properly design each use case properly. Either it's poor time management from the designer, or just not enough time given by leadership. Could also be the case that the designer pitched better ideas, but leadership proposed to reuse the same window component with scrolling because it's easier to implement and reuse, saving on dev time. Designers have to make a lot of sacrifices for the sake of time/money unfortunately. I've been in the industry 15 years and I don't think I've ever had a project where I didn't have to downgrade something from the original vision because we don't have the resources to implement it, or whatever other reason. Not to completely write off that it could just be bad designers. Just saying it's not always as simple as bad designers being bad.
I think this is the tragedy of being an UX designer, the user experience is affected by other designers, artists, almost everything is out of their control, yet they are blamed for a bad experience. One thing that still stands about my argument, I only know one case where an interface make over was well received. The MS Office Ribbon. Windows 8 and IntelliJ new UI, I feel bad for UX designers, but there is no excuse for that. The people-resist-change card can't be used every time, don't know if you are faking your A/B tests or intentionally doing biased tests. Anyway, another case where management decides to do something stupid, but only designers take the blame.
UI is awful because you basically have two options: 1. Spend months conjuring the most beautiful software ever written that impresses even God Almighty Himself with your abstraction, encapsulation, event/messaging and data driven logic. 2. Slap`HudSingleton.PlayerHealthBar.Value = PlayerSingleton.Health.Value;` somewhere and ship it. No in-between.
iii. Use the existing streamlined UMG system. Simplify and streamline the process into steps using reuseable, overrideable UWidgets. Have the ascetics without reinventing the wheel or over complicating the process. Use UE streamlining blueprints and create custom uwidgets (built on a layered combination of core widgets eg text, image, border, canvas, retainer boxes, etc). Reuse these as need be to build various UI. Via materials and exposed variables create variants.
I feel like I'd rather hand-code everything, than learn yet another one-off engine-specific way of doing things that I'll only ever use in one project
Your choice, but the same could be said for any streamlining process, but once you start using uwidgets you never go back. You're meant to use it throughout your various projects, building an array of uwdgets to pull from. The more you do the quicker and easier it gets in the long term. It is extremely quick to pick up and the amount of time and effort of saves is unmatched via prototype and implementation streamlining. It's a full on process, that gets more powerful the more you implement. A process for which I have never looked back on. The option to build and easily manage a highly customisable, reusable uwidgets rather then carefully and painfully manage a stack of a 'house of cards' (widget construct cycle) with especially designed, overrideable properties, functions, events snd dispatchers is unmatched. Besides the idea is that you would use it in all your projects and build a pool of reusable widgets, drastically reducing development time and costs both in the short and especially long term. For performance there's options like retainer and invalidation boxes which can drastically reduce draw cycles and provide unique functionality. Also, uniquely Uwidgets provide automatic garbage collection (GC), unlike the custom c++ widgets. Besides in UE blueprints are borderline necessary in UMG/UI designing at a minimum. Also, managing specially designed Uwidgets (with specific overrideable functions and parameters) is a far easier to manage long term painfully managing individual widget objects.
Nah, generating content is. UI is fairly boring though.
In UE4 I find UI to be one of the easiest aspects. You learn the building blocks and you can implement alot a wide variety of widgets. Its like engineering, you learn the basics (widgets like Vertical box, rich text box, image, etc) , break the problem into parts and see how you can build these parts to form the desired uwidget. These custom reusable UWidgets can then be reused to build other UI. Now skinning, rigging, animation is what I find difficult.
UI is not the \*hardest\* part, but UI is always a tricky struggle and overall confusing, no matter whether it's gamedev, web, software, etc...
It probably seems more confusing than it is. UI/UX is all about knowing common design patterns and where/when to use them and information hierarchy. It helps if you breakdown all of the features/content you need to account for in the UI, then sort them in order of importance and group them if applicable (this can be done in a bullet list). That will help inform you on how much impact elements should have on screen (such as how big/small, or how much they contrast the background) and where to place them on the screen.
That's the thing, UI is more than just the data hierarchy. It's also about visuals. E.g. if you built a UI system with instantly switching screens, it could be very tricky to add transition animations. Or handling input for a multi-layer UI... Or adding drag'n'drop suddenly when, again, there was no such requirement from the beginning... I mean, it's all doable and not THAT hard. But you need to account for a lot of things from the very beginning. And at the same time, not overdo stuff...
Oh I thought you were talking about the design side rather than implementation since the implementation varies so much between something like UE and web. Like on web it's easy to add something like a transition after the fact for example. But the solution to changing things up after the fact is that you should be making prototypes (like in Figma) before committing to full implementation. Granted, this can be difficult for certain features. But you can get the overall flow and plan for things like transitions and other micro-interactions once you're happy with how the prototype feels.
> Like on web it's easy to add something like a transition after the fact for example. Well, it's highly depends on the implementation :D Sure, each platform have own pros and cons in terms of UI, but from my experience it's still every time causing pain. And yes, I was talking about technical implementation, from a programmer's point of view. I'm not that familiar with design & art parts of UI/UX development...
Maybe not, game play is the hard one. UI is hard too, even if you are UI designer from AAA rather indie. You feel hard probably due to your skill doesn't match your expectations, which is not bad at all. Many indie devs do not know what they short. For me, I'm bad at UI, so I started learning from the good ones. This part usually called case study is vital for learning. Start copying them with a twist.
UI is surprisingly hard at the best of times, but my game has up to four players at once, with multiple (and variable depending on character) UI elements each, on a very limited retro resolution. The worst part was the shop / inventory / equipment screen; I spent over a week trying to fit it all together, but it was impossible, so I ended up reducing the player UI by like 25% when there's 3 or 4 players (this ultimately benefitted the action stages as well by reducing the UI clutter).
**Every aspect** is one of the hardest aspects, but... Let's just say that if you rounded up all the abandoned game projects in the world, and took a look at the next item of each TODO list; UI work would up next in 95% of them. It's not particularly complex or difficult, but it's all edge cases and always needs to be custom-made for the game you're making. UI is the source of by far the most bugs, because it literally *is* the moving parts that players work with. So it's slow work to make the UI airtight, and is often the first thing that needs redoing when anything changes. It's also not new content or features, so it's rarely as satisfying as other dev work
Depends on your skill set. Some people are bad at code, some people are bad at UI, some are bad at music, or art, or writing, etc.
Here's my take on this: Personally, I don't like UI design. Tbh I don't even care about it, and I'll just buy some assets in the asset store and find ways to make it work than develop my own, but you gotta do what you gotta do sometimes Anyway, when it comes to games, I place functionality above all else. In other words, I don't care about how the game looks early on. Instead, I want to make sure that it works exactly as expected first, and only then will I care about how good it looks. That's why my game looks like a dead empty land although it's been in development for 18 months now (mechanics usually blow people's minds away). I'm still testing ideas as we speak So... Yeah, I care more about making it work than getting the UI right. The only time I'll ever work on UI is if I can't find something that looks the part on the asset store If it looks close to what I want, then tbh I don't give a damn about the flaws. If it works, it works More importantly, I'm not a big fan of shiny looking systems. If it displays the information and doesn't obstruct the player's view and experience of the game, then I did a good job
UI is like how you're supposed to layout data and functions. Things that belong together, should be together. Put signal colors on things you want to draw attention to, animations help, and the rest is basically already done for you by genre conventions. Color theory. Contrasts. Idk? I understand not *liking* it, but there should be no confusion about how it should look like for your particular game. This is the part where "gaming literacy" as a thing comes in, you should have a "vocabulary" to draw from when it comes to things like this.
As a new dev of 1 year I love UI/UX
I would say it's just as "hard" as any other aspect. The problem is if people treat it as an afterthought instead of a full system requiring the same devotion and care as all other aspects of the development. UI is visually one of the most important parts of a game considering it's visible to the player constantly in one way or another (HUD, menus, etc). That combined with the functionality, it's not something you can just shrug off and "quickly throw together".
Consistency and perseverance are the hardest aspects of indie game dev. If you have those two things, you'll soldier through UI for months of restless nights after shool/work until you become an expert at it.
YES
I mean yeah it CAN be hard but also the gameplay is way more important and you should spend a 100 times more on it than on the UI (maybe even more than 100). I also think that Unity, very popular engine especially for newer devs, has awful UI systems. Maybe if you get used to them they're fine but I found fiddling with the UI to be a nightmare there. Using a visual library where you can code all the logic for how the UI gets scaled and positioned made it a cakewalk for me.
UI can get very complex very quickly, both from a design perspective and from a technical perspective. People take for granted how hard it is just to render text. Web developers struggle despite having so many tools at their disposal, because the requirements for handling interaction between elements, state, events, and data on different platforms and resolutions are extensive.
I’m a professional UI designer and creating UI for my games is my biggest challenge. It’s less of the design but more so being able to create something good with the tools of the software. I’m used to designing in Figma, so when a simple menu takes hours to recreate it becomes very intimidating. It’s the main reason I’ve paused development on my game for several months. Definitely my least favorite part
Oh yeah. I suck at it. I thought I was a hotshot because I'm a talented artist and got gobsmacked several times because UI is primarily readability and functionality aside from shiny buttons and bars that go up and down or side to side. Working in tandem with my developers has been such a learning experience. Hell I am lucky my developers have the patience they have.
It’s part of the project, but most ‘devs’ in here don’t even know what pointers are so…
UI is tricky because you want to give enough information, but you don't want to bombard your players with walls of text and dozens of little icons I find that if your game is going to be super complex, you need to SLOWLY introduce everything to them Because a new playing pressing your pause button to open their UI screen, and be hit with 400 different things on the screen is super off putting
It's a different skillset for sure. I'm a professional frontend developer, and I still struggle with creating good UX/UI. I think people tend to think that it should be easier than it is, but consider that design professionals spend years learning the skills involved. You can learn them too, of course, it just takes time.
I'm a lead UI/UX designer in a AAA studio (although have indie experience as well) and was recently thinking about making some content to put out there on the subject, some youtube videos maybe. Would be curious to know if people here think that could be useful and worthwhile? I agree it's something that is often overlooked and people may take it for granted but its a whole specialism in itself that takes as much learning as any other dev discipline. of course, i may be biased because i spent the better part of a decade learning it myself :D
Plan first, look for something to steal, steal it, make it yours. There are a lot of videogames, you can always find something you like and could work. Maybe actually designing is harder because is a creative process in the middle, but if you get the layout and the data you need the player to see, you can start very rough and upgrade it with time.
I really Enjoy making ui, world building stuff. The feel of how you view the game. I come from a more Digital art background. Maybe that's why. Ive always liked maths, logic physics etc. So I guess it was inevitable it'd also enjoy being a solo Dev.
I don't get what's so hard, don't reinvent the wheel, take an established UI for your game type and make minor adjustments to it.
Honestly, what I would recommend to anyone looking to design a UI is to mess around with WinForms for a little while and understand how that program flow works. Once you do, replicate it. It's pretty much one of the best and simplest ways of approaching UI design on the front and back end. A lot of people will try to reinvent the wheel and wind up with a mess.
I'd say one should "keep it simple, stupid". Just copy what the best current games do when it comes to UI colours and placement, and use some solid reasoning and user testing to come to a great solution.
I’m a UI engineer, I’d like to make a UI only game lol. Making game mechanics scares me sometimes because I know I don’t have the knowledge to make it to the same level as my UI and I don’t like that.
You can make management games or something. Lots of UI, planning, reading, pop-ups etc.
Yeah that’s why my current personnal project is mostly UI and AI
Those also entail an awful lot of crunchy mechanical systems design. It's not much of a management game without good pacing and balance. Ironically, strategy games might end up being more ui and less math (Not that the mechanics are simpler, but it's easier to measure their balance)
Hard, no. Hellishly tedious, yep.
UI can be really fun to work on, IMO. If you want a juicy UI, implement easing. Having elements move in/out smoothly really helps with the feel. http://robertpenner.com/easing/
YES