The UX problems of retroarch, the program that uses cores

Sorry to necro this year-old thread, but recently I had the same thoughts as OP here and I didn’t want to make a new one basically on the same topic.

The other day I was browsing through reviews about Android version of Retroarch on Google Play, and the main issue that comes out of all the negative comments is that it’s too hard to use.

At first I didn’t understand those people, because although I am very much a casual gamer myself right now, I never had any problems configuring and running Retroarch out of the box. Then I realized that it’s probably just me being a very patient man and already having heard lots of good stuff about Retroarch and being eager to make use of it, so in fact I was starting with a different mindset than others.

The fact is, I had no problems with the app even as a noob. So I realized that it is not that Retroarch IS hard, it’s just that it APPEARS hard. And the main problem here is the settings clutter and nomenclature within the app.

I’d not be so radical as to suggest dropping the concept or name of “cores”, I know it’s a crucial part of the philosophy. But there are a lot of other things in the settings that are totally counter-intuitive in a modern UX design.

To name a few examples:

Too many settings up front for the user -> why not limit the number of categories to 4-5 max and have a set of “General” and “Advanced” options in each? In “General” we would have only the most commonly used ones (eg. binding options in Input) and in the “Advanced” set the less-common ones (eg. analog deadzones).

Too much clutter in Settings -> there are really too many categories, eg. why having a separate category for Latency? Those options really should be distributed among Video, Audio and Input (and in an Advanced set within those categories, while we’re at it). The same with Drivers category (Menu driver already is included within User Interface and that’s cool, because that’s where it belongs). Frame Throttle -> this should go to Video (Advanced). On-Screen Display -> this should go to User Interface, etc.

Nomenclature -> the naming convention of some menu items really could be clearer, eg. core/directory/game overrides. Why not core/directory/game settings? Or, for better clarity, per-core, per-directory, per-game settings? Overrides is not a word causal users may be familiar with, and settings is meaningful enough. Other example: AI Service in Settings. What is AI Service for a person with special needs who opens the app for the first time? This should be changed to Accessibility, and only in this category the concept of AI Service should be introduced.

Not to make this too long, these are just examples of areas for improvement. There really are more ways to make Retroarch’s UI clutter-free, surely we can discuss them.

I hope this post will be taken for what it is: a constructive critique, because I love this project unconditionally and wish it all the best.

Also, I don’t want to make a dumbed-down version of Retroarch and strip it from its functionality. I simply would like it to be more welcoming for new users. Because there are a lot of smart kids out there, who might one day find this program and be amazed by it’s possibilities. In few years time, they might become devs themselves and even join the community and start giving back to the project. So this is really the benefit for all of us.

I’m not a dev myself, but I think I can help with some “casual perspective” regarding general user-friendliness. If there is some interest in this, just let me know.

2 Likes

I think you get more than necessary. It can be simpler.

  • Start the program.
  • Install the core.
  • And load the game.

That’s all to play, then you can configure the core and everything else.

I am aware that Retroarch has “UX” failures, personally it seems illogical that has the option “Load core” first. But treating it as a simple emulator is not correct, it is another approach, it is a complete retro emulation suite. Any emulator needs pre-configuration, some up to painful.

Although I do not understand something @hunterk. When I charge a decompressed ROM, it gives me option to load only compatible core. If I charge it in ZIP, it opens all the compatible with ZIP. But, the emulator decompresses the zip and can see the ROM extension.

Thanks for the constructive feedback.

We (the editorial “we”, as in “the people who work on RetroArch”) agree with your major points.

We do have advanced/basic settings, but there’s a constant push/pull of what to classify as advanced and what to leave visible by default. Everyone always wants their most-used settings exposed by default, and it would make sense to hide options used by less than some percentage of users, but we don’t have any way of determining that without adding telemetry to the program, which would likely upset a lot of people. Not to mention that some settings are used more on some platforms than others.

For the clutter, that’s another subjective value call. Lots of people complain about too many categories, while others complain about having to dig too deep into sub-sub-sub-menus to find the setting they want. These are exactly opposed to each other, and we get both as feedback. :man_shrugging: The only way to satisfy both would be to straight-up remove stuff (or make them config-only), which takes us right back to the advanced vs basic dilemma.

The nomenclature suggestions are all good/accurate. However, with “overrides”, we’ve added more over time, so if it were named per-core/game/directory settings, each time we added something we would need to re-name (and re-translate) the menu. That is, they used to just be per-core, then we added per-game, then content-directory; they also used to be full configs, but then we changed to the override system that “overrides” the global config, so overrides seemed like the best way to describe what they do. It’s hard to find a succinct but descriptive name for things, so we usually rely on the “sub-labels” that appear down below to explain things better. I think the one for overrides is not very explanatory at the moment and could probably be improved.

EDIT: @alexb3d re: zips, it doesn’t actually decompress it (at least not at first), it just looks inside it. That is, it’s still a zip, so it will offer cores that can load zips (such as scummvm and mame). There’s no way to tell the difference between a MAME ROM (that is, a zip full of bins) and an archive of, say, Mega Drive ROMs (again, a zip full of bins).

Then I’m confused, this happens to me very often.

Yes, I know that the sample the nuclei associated with ZIP, are many more, sometimes the list is uncomfortable …

Now, how do you know that the ROM is from NES or SNES? When I charge a ROM of Nintendo, it shows me the nuclei of Nintendo Nes, the same goes through the Super Nintendo, Genesis and I do not know what others, I barely realize this.

When the “Browser Archive” option is selected Displays the ROM with the extension almost instantaneously, RA could know what the ZIP is treated and does not require too much system consumption.

It is that, this is emulation, it is not Steam. Emulation always requires additional steps. Android users are accustomed to downloading and starting, there are even applications that shows you lists of ROMs and is played by just selecting it, it is illegal and Google ignores it. These users have never configured "DOSBOX, MAME or even PCSX2.

I did not realize that the post was so old, I would not have commented on.

You could only add that the current menu arrangement gives you priority the configuration and not to the game. It would be beneficial for the user experience to place first “Load Content” in the main menu. The playback lists immediately afterwards. “History, Favorites, Playlist” The “Images, Music, Videos” can go after or even in a single category that type gallery and the configuration option, within the main menu.

I am happy with what RA offers, it is just an idea, it would be something like that…

I’m engineer and I play a lot to emulation, and only retroarch have this UX so terrible to use.

Let’s say it clearly the UX of retroarch is bad, almost all frontend based on libretro the first thing they do is to eliminate this problem, a problem that is unique and exclusive of retroarch. And it is the most excessive UX problem I have ever seen in any kind of software.

So no, it’s not because the user is a novice, a casual user, an idiot or anything like that. The retroarch interface is a maze where it is often difficult to know exactly where you are.

When I opened the topic a year ago I already said clearly that there is no reason why the changes I comment mean a worsening of the UX of anyone. Simply that newbies and people who just want to play do not find a wall of problems and learning every time they want to install retroarch on their mobile or computer. Seriously, I even feel lazy to configure retroarch to play a game on my mobile. It is a very unrewarding experience, rather traumatic.

On the other hand, I see little coherent to hear that there are people who seem to have fun for hours tweaking a thousand options and that is the essence of the emulation complain because it is proposed to put a single and unique option to display those options seems to me a solemn joke.

What is originally proposed are basic changes in the interface, nomenclature and UX that make a new user can simply use the program easily without facing a maze of UI and a series of concepts that only uses retroarch and also require a lot of time both learning and configuration. But the full power of the program is still there.

It is a pity that retroarch has to remain as a program relegated to a few ultra-geeks who, with a certain classism, seem to feel superior because of how complicated it is to use a program. Instead of being enjoyed by any user who likes retro games.

As I said before, I am open to help, propose ideas, agree on solutions that favor everyone. But I think the developers don’t agree with this perspective, maybe is a lot of work or are overly influenced by advanced users and have no intention to make changes. Something I respect anyway, but it saddens me.

Thanks for your reply and perspective, @hunterk. Now to your points:

OK, so telemetry is out of the question and probably there is no practical way to poll the current userbase. But how about looking at other similar software, eg. current, actively developed emulators like Cemu or RPCS3, and see how they tackled the problem? What types of options they put in general and what in advanced settings? Yeah, I know Retroarch is not only about emulation, but the userbase and functionalities is mostly the same as in those programs.

This separation of “General” and “Advanced” settings is really a standard since at least early 90s, and I think Retroarch could use it on a much bigger scale.

So how about two views of the whole UI for two types of users? Default view (simple) would have everything neatly organized in submenus, and the Pro view (advanced) would have everything up front for those who really know what they’re doing. A user could choose his desired view on startup (a splash screen), and this could be also changed later in User settings.

Settings must be grouped more intuitively, because right now many of them simply lack context. Having separate category for Drivers strips the options it contains of this context. It would be better to put them in their appropriate contexts, ie. Video, Audio, Input, and, say, Misc. This is the most natural path for users configuring a tool: “OK, let’s set Input, Video, Audio, I’ll check the advanced later”, not “Let’s set Drivers, Video, Audio, Input, oh, and Latency, and Saving, and Logging, and, yeah, Frame Throttle, definitely…”. Context fosters understanding.

It’s like that math teacher at school, who describes an idea in such a way that no one really knows what he’s talking about. Then you hear it explained by one of your classmates and you realize that it’s actually really simple. Right now, Retroarch is that math teacher. I believe the learning curve could be made much less steep.

That’s not the point. You can have a powerful, configurable software with simple UI. Retroarch doesn’t have to be like an elitist “Linux of emulation”.

Of course, I understand it’s impossible to make everyone happy, especially in a project of such a massive scope. But it all really boils down to one question: should Retroarch go for exclusiveness (rewarding only those who are savvy enough) or inclusiveness (welcoming for new users who want to check it out).

Right now it goes the “exclusiveness” path. If that’s part of a deliberate vision, ok, we can leave it at that. Yet looking at the UI it seems more like a side effect of adding new functionalities, so that they are readily available for the users, but without a clear idea where to put the controls. It’s like when you regularly buy new stuff to your house, but can’t be bothered with organizing it. The result is a massive clutter and you end up constantly tripping over your own things.

For reasons stated in my previous post, I believe Retroarch should be more inclusive, because bigger userbase = more potential contributors who could expand on the project and emu community as a whole. It’s like an investment for the future :wink:

I don’t understand the issue at all. I personally have never thought of RetroArch as a front end.

I have used RA for many years. I configure everything to run, then call it from the command line in something designed from the ground up to be a front end.

It is very gracious of the developers to add features that allow the very stubborn to use RA as a front end, but I would never be one of them.

There is no need to disgust. Yes, it is a free and collaborative project, but there is a group of responsible and this project belongs to them. Proposals are made and remains from them to adopt or not adopt the changes, based on a context.

Let’s be objective. This comment is 20 years decontextualized. Linux is easier to use than Windows and emulators have always had extensive configurations.

Precisely one of Retroch’s strengths is its ease of use. It is easy to forget what it meant configuring the controls, or how to configure a shader in MAME. Try to emulate something in MS-DOS. Have you ever configured DOSBox (in Windows)? If you do not do it, you will not understand the importance of" DOSBox Pure.

RetroArch is hard to configure! It is difficult to use! In comparison with? Hyperspin? Lauchbox? o Mednafen, which directly does not have an interface.

Yeah, it’s really crazy think in retroarch like a frontend…

imagen

Maybe that is the problem, to think that linux is as easy as windows and to think that this is an objective opinion.

Retroarch is not easy to use, it is not one of your strengths. The configuration of mame was not complicated, I did it when I was 12 years old, neither was the dosbox configuration. You are mixing very basic UX concepts.

HyperSpin is not at all an example of bad UX, it has a somewhat complicated initial configuration, but nothing to worry about. And once configured it is simply one of the simplest frontend that exists, you choose platform, you choose game. All with a simple and vibrant interface, which is exactly why people like it so much.

Heh, I knew this comment will trigger some people :slight_smile: To make things clear: I have nothing against Linux, have used some distros in the past, recently got into Tails. I was talking about the general opinion among majority of users of commercial systems, which still prevails.

Only it’s not, and I covered my arguments quite extensively in previous posts. The settings are cluttered, not reflecting the usual user’s journey, lacking their context that would help onboard new users. This is totally against modern UX design.

Mentioning DOSBox Pure invalidates your own argument here, because this core was made exactly to simplify the DOSBox experience, which was a pain. And that’s what we’re talking about here, except for the context of the whole frontend.

Retroarch for years was about functionalities. I understand this was the main priority, and also the team probably doesn’t have enough time and manpower to cover much of the other things.

However, I believe that a major UI revamp is inevitable at some point in the future, as new functionalities get added, simply for the sake of not collapsing under its own weight.

And yeah, I’m aware the project is mainained by a specific group of people, and no one is taking that away from them. We’re just discussing ways of improvement, possibilies, what works and what doesn’t. The team may get involved, just like Hunter does, take some ideas out of our rants, or they can ignore the issue whatsoever and move by their own agenda. And that’s cool with me. It’s a discussion forum, so we discuss.

In fact, I have some specific ideas about streamlining UX, but I need to think them through. Probably will get down to it after the weekend.

Precisely, this is not objective.

These discussions do not contribute and do not give a solution. Because in the end, everything is a matter of tastes.

That is a fallacy that only you believe in order to defend that nothing should change.

UX is based on science, on neurology, on sociology, on how human beings understand the patterns of their environment,… and no, it is not based on “tastes”.

And many solutions have been proposed and would make a contribution. What do not contribute anything are your messages that are based on prejudices, attacking those who want to change something and denigrating their opinion.

Take it down a notch guys. No need to get heated.

That said, I’m not interested in arguing with an anonymous person on the internet about a year-old topic about things he knows nothing about.

If someday the developers will consider any change, they will do it.And if they want, they can send me a private message, because I’m going to mute the thread.

In the last few times I have become a better person. I have walked the trail of respect, and of deep peace.

I am a good human, so good that I am almost a saint. I already talk to Bergoglio to sanctify me, I am going to be “San alexb3d”.

And you…

you hurt me…

my…

feelings.

imagen

There seems to be some misunderstanding as to what has been proposed here.

To drive the point home, I’ve made this lousy-looking diagram of my vision of Retroarch’s Settings menu tree (you may want to open it in a separate tab):

The bubble items represent submenus, the text items are individual options without deeper levels. The contents of submenus remain the same as original, unless otherwise noted.

The UI items are presented as they appear in Ozone menu on Windows 64-bit with Show Advanced Settings off. The settings currently considered advanced and hidden might be placed in Advanced submenu of individual menus.

My goals here were:

  1. To limit the number of top-level menu entries from a whopping 21 (with Show Advanced Settings off!) to 5.

  2. To contextualize the options by putting them within those 5 categories and respective submenus.

  3. To delete duplicates, as contextualized options are clear enough.

  4. To introduce an Advanced submenu within most categories with options for specific use cases.

The contents of the Advanced submenus are arbitrary at this moment, and so is the order of the items in individual menus. This may be up for a debate.

Also, I mostly left the current nomenclature as is, so it’s easier to compare it with current UI. I only changed Synchronization in VIDEO menu to Refresh Rate, and added some related options there. I was also thinking about changing Accessibility to Accessibility & Translation, because not every user of AI Service is an accessibility user.

In AUDIO menu I was wondering about viability of Output and Mute options. Does pressing Mute not mean to block the output? Is there some different mechanism involved? And does it make any difference for end user? I left them as is, just wondering if there are some use cases that would justify having them both.

You may also notice that there is no Network menu. That’s because those settings are already in the NetPlay menu, and that’s perfectly fine. We can safely assume that users who want to configure them are going to use the NetPlay functionality, so there’s no need to have duplicate (just like in standalone games, where you configure the server and whatnot after you choose multiplayer mode).

I proposed also a new label for Show Advanced Settings, which is Poweruser Mode. This would work exactly as before and/or expand all Advanced submenus for those users who don’t like diving too deep in search of their options (or there may be a separate option for that). Otherwise it’s only one level deeper in most cases, but the benefit is better organization.

I also suggested moving Language setting to User Interface submenu (I always look for it in the wrong place, I’m sure I’m not the only one).

So there you have it guys, a concrete idea of what was proposed in my previous posts. We can discuss it either now, or when devs decide on a revamp, or maybe someone would like to use it in their own implementation, I don’t mind.

And yes, I suck at diagrams.

3 Likes