Jun 17, 2020
RetroArch - libretro
So, it’s been a long time since we (prematurely) announced our intent to launch RetroArch on Steam. We’re nearing the finish line now however, so now is as good as any a time to start discussing how things are going to roll out.
Will launch on Windows first (Linux later)
We will be releasing on Windows first, with a release on Linux scheduled later (no ETA).
We are trying to limit our support burden at launch here since we are (understandably) concerned about the large amount of support requests and feedback we are bound to be receiving. Adding Linux right from the bat would further exacerbate that.
10 Cores Available On Launch Day
We are deciding to launch with 10 cores at launch. These cores have already been approved and uploaded on Steam. They are as follows:
- Mupen64 Plus Next
- Kronos
- PCSX ReARMed
- Stella
- SameBoy
- mGBA
- Mesen
- Mesen S
- Genesis Plus GX
- Final Burn Neo
There will be no ‘Core Downloader’ in RetroArch, or anything that is not hosted on Steam in fact. To obtain cores, you need to install cores separately that we provide as ‘DLC’. These are all free just like RetroArch itself.
NOTE: We need to stress – on its own, without installing any of the cores, the most you will be able to do with RetroArch is watch some movie files and playback music files through its builtin ffmpeg core. To make it do anything else, you will have to install cores.
Differences between regular RetroArch and Steam version
Apart from these aforementioned changes, there will be no substantial differences for now in the Steam version. We understand that even though we have consistently improved the User Experience and tried to make things more easily accessible that we will still be in for a lot of criticisms over the initial learning curve, so we’ve pretty much resigned to the fact that this will happen and will just brace for impact and try to do as much as what we can with the criticism that will inevitably be piling on. We will try to do our best to be as receptive to the feedback as possible with the thickest amount of skin possible, and try to suitably make some much needed UI changes.
This is also what helped inform our decision to go with 10 cores. We could have launched with over 60 cores, sure, but the ensuing fallout would have been a mess and it would have been near impossible to focus on bug reports and issues piling in. By focusing on 10 cores, we can do some much-needed Quality Control where issues inevitably get picked up, we can respond to it and in the process improve the quality of the core. This kind of isolated feedback time with a specific batch of cores is something we have found ourselves in the past always lacking, since it was always off to do the Next Big Thing as new features, cores, and other developments are made on an almost weekly basis. This gives us the much-needed time to focus on a specific batch of cores and polish them before we move on to the next batch of cores.
Share: 
