The UX problems of retroarch, the program that uses cores

[NickName2]

Hi

We all know that the retroarch interface and user experience has been much discussed, it is very problematic for users. There is debate over whether retroarch should allow for many options or whether it should be simpler for new users, becoming a Gordian knot for the UX. I would like to comment on this topic again and propose a series of changes that without being profound at the application level would make the UX of all users much more comfortable without losing any option or customization.

The problem:

The problem of retroarch, from my point of view, is not the professional, veteran, geeky public or the most mainstream public. Nor is it the amount of options it gives the user, nor the complexity of these … it’s a simple clear hierarchy problem problem in the UX / UI.

As a user, my main problem when facing retroarch is the concept of core (don’t worry, I’m not going to ask to eliminate that idea) and the importance of this concept in the UX.

When a user uses retroarch for the first time, he doesn’t see anything about games, platforms, roms … The program is not about to play games, it is about to use cores. To play games, the true intention of the user, is secondary from the point of view of the interface and the design of the application.

This is what a user expects:

• Run program
• Select platform
• Select game
• Play it

This is RetroArch:

• Run Program
• Install a Core
• Load a Core
• Set up a Core
• Search for Core content
• Select the content for the core
• Ask him again what core he wants to use.
• Play it

The problem with retroarch is that it is a program about cores, not about games!

Why this abstraction for the program? I see no reason for retroArch to be “corecentric”, nor an impediment to fix this just by changing the interface, without breaking all that libretro means.

The solution:

The solution is much simpler than it seems to allow ordinary users, those players who are now between 30 and 50 years old, to easily approach retroarch

Change current retroarch hierarchy:

Core -> Options -> Game

To a more logical hierarchy:

Platform -> Game -> Options -> Core

The proposal:

To relegate the central role of the core in the interface currently to a parameter within the options, which has global options, or being overwritten for each particular game. As it currently happens.

Most of the general options of the cores would be relegated to a menu within options dedicated to cores, where cores could be installed, updated or configured. Remove all traces of cores in the interface main menus.

When a user wants to play a rom, it is part of a platform, which he must select, which has an associated core (the first installed of that platform, that you can change in the core tab settings), but the user can load that rom with another core and that always remains that option saved there.

This idea is very brief, but if the developers are interested I can expand it further or qualify depending on important limitations of the system.

Other problems:

Pause:

One of the problems that I find most when using retroarch is the menu that comes out when you pause the ROM, it does not make sense, I easily get lost in this concept and I have useda lot of times. Instead of block the user in a menu while executing a ROM, what it does is send it to the general interface with a submenu, very hidden, where you can go back to the rom or close it.

It should be clearer how pausing a rom works. You should hide all options about library to load a new rom while you still have one running, and exchange with a menu dedicated to that particular ROM, its options, if you want to stop the execution, …

Losing configuration:

Another fundamental problem is that retroarch crashes, crashes a lot. This is normal and expected when dealing with emulators, more so with a suite of emulators. The problem is that as a user every time you try something if retroarch crashes you lose the settings. And since the interface is so complex, many times you end up leaving the program forcing the program to exit or close.

This makes retroarch, for the first 10-20 uses a user is always going back to the default settings even if you have configured 1000 things. And that you are constantly losing the changes.

A program with so many options cannot work like this. Every time an option is changed something must be saved and this setting should not be lost under any circumstances other than at the request of the user.

Default directory:

Another thing that retroarch needs is to ask, as soon as it starts up for the first time, the default path it will use. It is very problematic

[hunterk]

I appreciate the constructive feedback

There are a couple of things that keep us from being able to switch to a system-based paradigm, but the biggest is that RetroArch (the frontend) isn’t allowed to know anything about the cores (the backends) before loading them. Otherwise, RetroArch would need to be modified/updated to work with each new core.

That is, for example, let’s say there was a new core that plays games for System X and it’s the first core to do so. Whoever made the core would need to modify RetroArch to know about System X before anyone could actually use it.

We had the same idea, though, when we moved ‘load core’ and ‘load content’ up to the very top of the main menu.

Ultimately, it would be a lot easier for people if we just hardcoded specific cores to load certain files and hardcoded all of their options and inputs beforehand, and this is a large part of what makes projects like OpenEmu so easy to use.

It’s really a matter of project goals, and while we obviously want RetroArch to be as easy to use as possible, ease of use is several steps down in our list of priorities, below creating an open/decentralized platform and including advanced features and customization, among others.

As for saving options immediately, one of the arguments against that is that if a user sets a bad option and it’s saved immediately, they may have no way to get back in and change it. OTOH, if it crashes and they lose it, it reverts back to a known-safe state. If someone deliberately saves a bad option (through main menu > configuration file or whatever), they typically end up deleting their entire retroarch.cfg to fix it, which wipes out ALL of their settings, instead of just the things they’ve changed since the last opening, and this would be the case every time if we saved settings immediately.

As for the default directory, yes, we would like to have a setup wizard at some point, but it’s a lot of work to set something like that up in our custom raster UI and no one has wanted to take it on yet.

[zachmorris]

I think the Kodi implementation with libretro cores is good in this sense:

• The user loads a game (or attempts to)
• The file extension is known, and the application looks to see if there are any existing cores that can load that filetype
• If one doesn’t exist, then it either:
  • Looks at the available info files to see if any cores are available that can load such an extension. Then prompts the user to ask which core to download, they choose one and the game is then loaded after the core is downloaded or
  • if only one core is available that is capable of loading that file extension, the core is automatically downloaded and the game is loaded

All of the pre-determined info needed for this is contained in the info files. I think the only change needed then would be to require each core has an info file available locally (and then the updater can also pull info files from the repository). Info files could be extended to include the options as well.

[NickName2]

@hunterk

There are a couple of things that keep us from being able to switch to a system-based paradigm, but the biggest is that RetroArch (the frontend) isn’t allowed to know anything about the cores (the backends) before loading them. Otherwise, RetroArch would need to be modified/updated to work with each new core.

I don’t see the problem with this. You load the core when you go to run the game, then you can see the core options.

• Select platform (it’s not necessary)
• Select game, the core is loaded
• You can see core options.

@hunterk

Ultimately, it would be a lot easier for people if we just hardcoded specific cores to load certain files and hardcoded all of their options and inputs beforehand, and this is a large part of what makes projects like OpenEmu so easy to use.

I don’t see necessary, the only necessary thing is that when you go to load a game have a clear platforms system.

Actually you have a infinity list of cores, with that cores subdivide by

Platform Core Subcore

Could be easy to configure for the users.

@hunterk

It’s really a matter of project goals, and while we obviously want RetroArch to be as easy to use as possible, ease of use is several steps down in our list of priorities, below creating an open/decentralized platform and including advanced features and customization, among others.

I know, that is a problem of all development, that UX is not a “important” part of the development, but people don’t use projects because UX is problematic.

In this case I say it so that if it’s easy, it can be done, and someone is interested see it from the perspective of someone quite used to deal with UX issues. But if not, it’s also good to keep it in mind so that when future changes are made, the path to future changes is smoothed out

@hunterk

As for saving options immediately, one of the arguments against that is that if a user sets a bad option and it’s saved immediately, they may have no way to get back in and change it. OTOH, if it crashes and they lose it, it reverts back to a known-safe state. If someone deliberately saves a bad option (through main menu > configuration file or whatever), they typically end up deleting their entire retroarch.cfg to fix it, which wipes out ALL of their settings, instead of just the things they’ve changed since the last opening, and this would be the case every time if we saved settings immediately.

In that case why don’t use this option

• Saves all changes
• Give the option to use previous sesion config if something fail.

[metchebe]

Hi! So I read this and just wanted to comment that I started using Retroarch first through Lakka, and the core-centric nature is mostly gone in this implementation. Upon first use all I did was scan and load games. The key, I believe, is a selection of cores set as defaults for most systems.

Fully understanding cores etc. came later. I still somewhat disagree that RA is core-centric all the time, once set up it really isn’t.

[jnsl]

I completely agree on the pause menu. It’s disorienting that you can get back out into the whole main menu. I think F1 should be a games-specific options menu only, and ESC should take you back to the main menu. If you want to quit the entire program, it should be done through the main menu not pushing ESC twice.

As for cores, maybe I misunderstand the OP but I think that a lot of that would be solved by installing a set of basic cores by default. I understand in the past there was no interest in doing that for political reasons. But now it’s being done on Steam and apparently Lakka so…

[NickName2]

what I want to mean with “corecentric” is that when we run retroarch… do we see something that give us the impression that we are in a program to play roms?

I don’t see nothing about roms, play, games, plaftforms, controls, gamepad. All the UX is based in “Load Core” what is not named “Load emulator” at least to give some hint about.

In reality all the things are strange for a new user

• Load core… What is a core?
• Load content… A doc file? the icon appear a doc file
• Show desktop Menu… I don’t what it do, really.
• Online Updater… Why is not in config?
• Information… about what?
• Configuration file… the the configuration icon at the right of the space invaders what is?
• Help… The first thing that I know what do.
• Quit Retroarch…

If we quit the space invaders icons in reality it appear anything except a program about games and emulators.

[hunterk]

It’s intentionally vague because, like I said with regard to differences from OpenEmu, RetroArch isn’t emulator-specific (this is also one of the reasons we don’t pre-package cores, among several others). Yes, most of the cores are emulators, and most of the people using it are using it because of the emulators, but it does a lot of other stuff, too, and as the reference frontend for the libretro API, we don’t want to discourage people from making non-emu cores.

The rationale for the main menu is that it’s “actions”. You load cores, you load content, you show the desktop menu, you download updates, etc. etc. The quick menu was much more focused when it was first created, but a lot of other stuff has crept in over time, which I’m not a fan of, either. It was intended to just be things that you need while playing a game, but a lot of general settings have been added because people complained that “I need to change overlays while playing”, “I need to adjust latency while playing” and so on. I think all of that stuff should just be replaced with a single link to the settings menu (or not and people can just back out to the main menu to change that stuff).

As for not being clear enough about what its purpose is, if someone doesn’t already know what RetroArch does before downloading/launching it, I guarantee they are going to be unhappy with it anyway (where do I download the rawmz?? <- which we already get a lot of)

[jnsl]

I honestly think it would be way, way more intuitive to start Retroarch in desktop GUI mode. Steam offers both Big Picture and a normal GUI. It would be really weird to default to Big Picture in Steam. Virtually no other emulator software starts in this type of Big Picture either.

The problem is I’m not sure the basics are doable yet in the desktop GUI. Can you scan folders for ROMs etc?

[hunterk]

Yeah, you can do those things. There are a few other things (mainly input mapping) that it can’t do, though. We’re focused on the gamepad-driven interface, though. Similarly, Kodi launches right into their big picture-style mode.

[jnsl]

I hear you there but Kodi is a complete media player platform, so it makes sense to boot into that type of full-screen GUI.

I think its fine to have multiple GUIs, but IMO it’s worth considering targeting the default GUI depending on the platform. Lakka, obviously is a purpose-built system for Retroarch that needs a Big Picture GUI. On a desktop PC however, that is not the experience that anyone is expecting by default. No other major emulator does this that I can recall.

I feel like it could solve a lot of UX stuff and also cut down on support by defaulting to a GUI that people are expecting and that is more natural to navigate on the platform.

[hunterk]

@jnsl

Kodi is a complete media player platform

Yeah, and that’s what we’re going for, as well. You can run Kodi on an RPi as a turnkey device, just like Lakka, but that doesn’t mean that when you run Kodi inside Windows it’s going to give you a WIMP UI just because other Windows programs do so. Anywhere you run Kodi, you get the same UI and (mostly) the same options and (mostly) the same capabilities. Ditto for RetroArch.

@jnsl

No other major emulator does this that I can recall

Again, RetroArch isn’t an emulator and isn’t trying to be one. It’s a platform for running programs that conform to the libretro API (most of which are emulators). I will readily admit that the UI is not intuitive insofar as it doesn’t act like the emulator UIs people are used to, but I don’t think that’s a bad thing.

[NickName2]

I understand that it’s not just for emulators, although that’s how it’s advertised on the web basically.

and a big this

But I don’t see that as an impediment to improve the UX. If retroarch can run other kind of software (I don’t know what other software) it can have its tab, the same way it has one for music, one for movies… It will help to order the UI and improve the UX. Separating the abstract idea of the user want and put all the cores of all this features in the config tab

[hunterk]

You see Doom, Quake, Cave Story and Dinothawr in there alongside the consoles. Those are all game engines. Not emulators. It doesn’t make sense to call them emulators, and tailoring the UI around emulators works to the detriment of everything that’s not an emulator.

In the description, it says “emulators, game engines and media players.” Only one of those is an emulator. Most of the cores are indeed emulators, and most people use RetroArch for emulation, which is why it’s listed first, followed by the other things.

With all of that said, nothing is stopping anyone from making a purely emulation-focused libretro frontend, and several already exist (bizhawk, minir, etc.). RetroArch is also open-source, so if someone wants to replace all instances of the word “core” with “emulator”, it’s just a find-and-replace away.

[NickName2]

But add game engines in the concept is not a problem, also could be an improvement separate it because actually I think few people know that game engines are an option inside retroarch (me for example didn’t know that before this conversation). So the original goal you mentioned of not occluding other libretro features or other cores would even be improved.

[NickName2]

I have made a mockup of the idea (only left menu)

or

[Paultimate]

I feel that Retroarch for all its amazing developers, is developed with a mindset coming from a programmer rather than a UX developer. It offers a much more tool-based experience that has a steeper learning curve. Its not all bad, but it could also use improvement so its is more intuitive to end users. That results in improved usability and a large growth in community.

[AdamS]

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.

[alexb3d]

@NickName2

This is RetroArch:

• Run Program
• Install a Core
• Load a Core
• Set up a Core
• Search for Core content
• Select the content for the core
• Ask him again what core he wants to use.
• Play it

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.

[hunterk]

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. 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).