The UX problems of retroarch, the program that uses cores


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:


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

I appreciate the constructive feedback :slight_smile:

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.

1 Like

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.


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.

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.

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

In that case why don’t use this option

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

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.

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…

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.

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)

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?

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.

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.

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.

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.

1 Like

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

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.

1 Like

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.

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


1 Like

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.