Retrom: an interview with the developer behind the self-hosted game library

Retrom is a self-hosted game library and launcher designed to bring order to the messy world of retro and modern gaming. It unifies emulated titles with native PC games, supports platforms like Steam, and automatically pulls in artwork, metadata, and more to make collections look seamless and polished. I got the chance to chat with its creator, John Beresford, to hear all about how the project started, the challenges of building an all-in-one library, and his vision for Retrom’s future.

Rather than cutting things down, I’ve chosen to also share our entire conversation in full. John’s answers speak for themselves, offering a clear picture of the fun, challenges, and philosophy behind Retrom...straight from the developer who built it.

The History:

Can you share a bit about your background? What was your path before Retrom (other gaming programs / projects?), and then what made you decide to focus on emulation/cloud-library tooling?

Prior to starting on Retrom I spent almost all of my time firmly in the intersection of UI/UX and graphics. This has been the case since university – and I even work at a company known for graphics, although my day job has been light on graphics work for a while.

I spent some time creating small open-source projects for use in web graphics. Things like a 3D form library for use in immersive web projects and a minimal, low-level webGPU library. I also spent a lot of time on hobby/artistic endeavors in that same realm. Just about all of this is publicly visible on my GitHub and/or my portfolio site(s) – which are both woefully out-of-date:

https://lab.john-beresford.com/ - For fun experiments and gfx art

https://john-beresford.com/ - For client work, open source projects etc

My work on Retrom, i.e. my transition to emulation and cloud-library tooling, was largely borne of my frustration with a lack of a distributed game library solution that checked every box. Every other solution I tried was missing something that I considered core to my use-case.

Even though Retrom is not big on the graphics side of things, I do have plans to integrate some of my old specialties into Retrom eventually. Things like 3D game boxes to display box art etc

Where did the idea for Retrom come from? Did Retrom start off as your own personal project for managing your own retro games, or was it public-facing from the beginning?

The idea for Retrom itself was something I had been playing around with in my head for a while – it was months before I ultimately began to work on implementing something. I had been frustrated with other solutions that were entirely missing or only had partially-functional shims/third-party support for important features. There simply was no perfect solution for a unified game library that had personal-cloud support and support for all major operating systems. Maintaining and using a large library across multiple devices required sacrificing one set of features for another. It was incredibly cumbersome due to storage constraints, issues with synchronization, hours of duplicative configuration on each new device and/or many other smaller issues. Honestly, Retrom still does not fill this gap even after a year of development – yet!

All of my software endeavors, Retrom included, tend to be public-facing from the get-go. If I am taking the time to create something, it is generally because I personally have a need for it – which implies there are likely others who could use it too! Making this type of work open-source and usable for all makes it more enjoyable and fulfilling for me. It’s easier to find motivation to work on something and to polish it to a higher-standard when you are sharing it with others.

How has the vision for it changed since those early days? Was it always about a full frontend, or did it start a little simpler?

The full scope of Retrom has not grown all that much. If anything, I am continuously working to make Retrom more digestible and simple for users who may not need the full functionality that Retrom provides.

If I had to pick one thing that may be considered an increase to Retroms’ scope it would be my consideration of making the Retrom client compliant w/ the libRetro API and usable as a libRetro front-end. In other words, integrating the features that RetroArch (the official, de-facto libRetro front-end) provides. Retrom already supports this for a sub-set of the libRetro-capable emulators via browser emulation with EmulatorJS, but full support of desktop/native emulator cores would be a huge improvement on this.

Did things like LaunchBox, RetroArch, or even Steam’s Big Picture Mode spark any inspiration or influence for you?

Yes, of course! Many, many of these things have influenced Retrom’s direction and goals. RetroArch, and libRetro as a whole, provides a fantastic way to generalize a lot of the features that Retrom supports or intends to support. Steam’s big-picture mode and effortless cloud-saving mechanisms are the north stars for Retrom’s respective fullscreen and cloud features. Playnite, Romm, Gaseous and many others have also had their hand in influencing Retrom as well!

To me Retrom feels like a kind of nice ‘middle ground’, between self-hosting and ease of use. How did you strike that balance early on?

I’m very happy to hear that you feel that way! I am always concerned with how complicated Retrom is in both terms of setup/configuration and usage. This is something I have been trying to improve on, and expect will continue to be working on for quite a while. With early announcements of Retrom I always paid particular attention to any and all issues that prohibited users from getting started with Retrom, or understanding how to use Retrom. I always prioritize fixing such issues to ensure that no-one ends up left out before they can get started, and I think this has made Retrom much easier to use as a whole.

Core / tech design + features:

What would you say are the, let’s call them ‘core pillars’, of Retrom? Is it the frontend, the emulator config system, the metadata...something else?

The core features are:

1. Self-hostable server to own all non-client-specific data. In other words, a server that owns anything and everything that could presumably be synced across client devices
   1. Library files and definition (games, platforms etc)
   2. Metadata for the above
   3. Emulator configurations, both for built-in emulators and custom added standalone emulators
   4. Saves
2. Client support for web and all major operating systems (Windows, MacOS, Linux)
3. Install and uninstall games from the server on a given client device to easily manage disk usage
4. Effortless cloud save file/state sync across client devices
5. Gamepad and fullscreen support for things like couch gaming setups

The above composes the minimum feature-set that meets the goals of Retrom. The goals could loosely be described as ‘a Steam-like experience for unified game libraries with first-class emulation support’.

You added telemetry support (opt-in, of course) to help track performance. Has that given you any surprising metrics back?

This was largely added to help me identify any performance bottlenecks or issues at scale that I would not be able to see in the isolation of my own Retrom instance/development. I would say that the most “surprising” metric I’ve gotten back so far is the number of users who are willing to enable this telemetry! I am hugely appreciative of these users, but I also totally understand – and fully support – the desire to keep self-hosted software from accessing the outside world.

Was there a particular feature (auto-scanning, scraping, or controller mapping, etc) that was tricky to nail?

To be completely honest, just about all of the core features of Retrom have aspects that were tricky or even impossible to nail in full. I could spend hours talking about the nuances and complications with automated library scanning, matching games to metadata sources, controller mapping, managing emulators in a generic fashion, integrating with external third party libraries like Steam and many many other things – each of which with their own distinct hurdles.

I suppose one of the more tricky things was supporting a use-case that does not use a dedicated server. Retrom has a standalone mode that spins up the Retrom server alongside the client under the hood for users that just want Retrom as a simple front-end. Wrangling the dependencies and requirements for running the server in this way definitely took some trial and error, and quite a lot of time in the design phase.

How do you handle emulator integration? Do you maintain a config library or leave it flexible for users to tweak?

For the built-in emulators, they are currently largely handled by the upstream EmulatorJS library that Retrom uses for in-browser emulation – currently only these emulator cores are ‘built-in’ to Retrom.

Users can additionally add and configure any number of standalone emulators to use for launching games in desktop clients. Retrom simply stores the name, and supported platforms (platforms in your Retrom library) which the user initially configures. Any client can then use this emulator definition to launch games from Retrom so long as the emulator exists on that device and the user points Retrom to the executable.

Each emulator configured in Retrom can also have any number of “profiles” associated with it, to define launch parameters (e.g. fullscreen vs windowed) etc. Emulator profiles can be set to support only certain operating systems as well, as sometimes emulators have different requirements (e.g. launch parameter semantics) on different OSs. All of this (other than the local path to the executable) is stored in the server to be shared across all clients.

I’m a terror for the UI and UX of this kind of thing. I getobsessedwith how it all looks and feels. And Retrom kinda nailed the UI. Was it a priority from the start? Or did it moreevolveover time?

UI / UX has been and will always remain a priority for Retrom. I will, frankly, not put out work publicly that I don’t think looks good, or feels good to use. That is not to say that there are many improvements that Retrom can still make in this area! Retrom has some difficult problems that it is trying to solve, and this can occasionally make the associated UI / UX difficult to implement as well. Quite a lot of time was spent on developing a baseline design system at the beginning, and Retrom was not officially shared publicly (other than existing on GitHub) until it was presentable in my eyes.

What made you want to support both local installsandremote clients via the browser?

This was due to a couple of things. Firstly, when it comes to UI development I am definitely going to gravitate towards web technologies. I don’t have experience w/ non-web UI application development, so using a web UI was a no-brainer. Luckily, web UIs can fairly easily be shimmed into desktop applications with things like Electron and Tauri (Retrom uses Tauri, specifically). Considering the desktop application UI is driven by a web application under the hood, it only makes sense to also support a web client. This was not much work on top of the desktop client, and provides many unique benefits like interim support for mobile devices in lieu of a proper iOS/Android app. Yes, this means you can play your Retrom library on your phone’s browser!

What was the most fun to build feature of Retrom so far?

This answer will probably always be changing to whatever the last big feature was – and at the time of writing that would be the integration of EmulatorJS for in-browser emulation. I very much enjoyed putting together the UI for the in-game overlay. It is one of the parts of the UI that I am most proud of! I also found implementing the cloud save management incredibly fun and fulfilling. That in particular was a problem I had been turning around for months and months while trying to find a solution I was happy with. Finally building it out was quite fun!

Releases and the road ahead:

Is there a long-term roadmap for version 1.0, or do you prefer a more incremental, iterative approach?

I’ll mark a release as 1.0 once the core features are fully implemented and mature. In particular, better support for cloud saves/emulator management, metadata sourcing and handling and multi-user support and authentication are all things that need work before I would consider Retrom feature-complete. After that, it will likely be more of incremental maintenance type work. At that point I am hoping I’ll have some other contributors from the community to help drive larger feature development.

Are there any ‘dream features’ you’d love to include, but haven’t been able to so far?

Many! I really want lots of little things that would be nice to have and fun to build, but likely won’t be prioritized for a while due to them being less important than getting the core functionality implemented in full. Things like:

1. Gamepad mapping dialog w/ interactive gamepad illustration/graphic
2. Theme music/video playback on a game’s detail page
3. Just a whole ton of fancy and well designed graphs to show user stats like playtime, installation status etc
4. Generalized tag system for arbitrary, self-service organization and categorization of library items
5. Automated installation/setup of emulators
6. Mobile apps for iOS and Android
7. Lots of random ad hoc UI / UX improvements like an interactive library scanning dialog, rather than a simple scan leading to every file being plopped into your library with many failed metadata matches
8. Better support for native, non-emulated games

And honestly a ton of other things, I could go on for hours here

Have any community feature requests made it onto the roadmap or surprised you with their usefulness?

Yes! Likely many more than I can remember right now, but I remember in particular many requests for FlatPak support early on. I was initially hesitant, for reasons I won’t bore you with here, but am now excited to have it planned on the roadmap and can’t wait to get working on it. Getting that out there will make distribution to SteamDeck users and linux users in general much more ergonomic.

How do you balance adding new features vs keeping the core fast and stable?

I generally like to move in phases, where I spend a month or two on a big feature that takes a lot of time and thought to implement. I will then follow that with a month or two in maintenance mode, where I iron out bugs that have been reported over time and polish up any of the rough edges still remaining on the big feature implementations.

If a user wants to help contribute in some way (dev, language translations, financial support etc), how can they do so?

I still haven’t set up any sort of donation systems, or anything like that, despite numerous requests to do so. At the moment the only way to support Retrom financially is to boost the Discord server. This would of course be much appreciated, the perks from those boosts can be really fun and cool! Eventually I’ll have some other means of directly financing the development of Retrom, but I’ll need to find the time to spin it up first.

I’m super open to people contributing to Retrom in terms of development as well. Anyone can feel free to reach out either on Discord or GitHub if they are interested in this. For small simple things, opening a PR with changes is generally fine but for larger scale feature development I usually ask for a dialogue first to align on any architectural decisions that need to be made. I hate having to say no to a big change that someone spent days or weeks on just because we skipped that part of the process.

In General:

In your eyes, what makes Retrom different from other game launchers or emulation frontends?

Firstly, I’ll preface this with the fact that since I started seriously working on Retrom I have not interacted w/ other launchers/front-ends so the following is likely based on out-of-date information. Even putting that aside, there is a good chance I simply missed something back then as well – so take what I say with a grain of salt.

In a nutshell, Retrom is the only free option for a unified gaming library that provides (or intends to provide) all of the following as core features:

• First class emulation support alongside native (Windows/MacOS/Linux) game support
• Third-party library support (e.g. steam)
• Desktop clients for all 3 major operating systems (Windows/MacOS/Linux) and a web client
• Centralized server that owns all data
  • no need to reconfigure each new client
  • (un)install games – including emulated games – as needed, clients don’t need to drag along your entire 3TB library
• Fullscreen + gamepad support for couch gaming setups

There are many other options that check most of the above, but none that I know of that check them all. Note also that with a smaller scope/focus comes a likelihood of a more polished product. Many of the other front-ends do only a few things, but they do them very well and Retrom would be hard-pressed to ever match them in that category. If you don’t want/need everything I have listed above then there is likely a better alternative for you out there.

What’s your personal take on supporting legal/digital preservation and avoiding the grey areas of ROM distribution?

Of course, not all of these questions could be fun and easy! I personally try to maintain the mindset that legality, and ethicality are rarely perfectly aligned. It’s sometimes very tough to reconcile the various aspects of this topic, philosophically speaking. Breaking the law, frankly, cannot be justified by one’s own subjective opinions on the matter regardless of their ethical basis. I fully support the legal preservation of digital media in general, however, when it is feasible.

I also believe, personally, that it is imperative for the ability to own digital media to remain possible. When I say own I mean own a digital copy of that media, not a license that can be revoked arbitrarily or requires you to check in over an internet connection periodically. If all digital media continues to converge towards this idea of being barred behind either subscription services or license-restricted access then there is a high likelihood of digital preservation of such media becoming impossible.

How do you see the role of self-hosted projects like Retrom in today’s increasingly cloud-locked gaming world?

I would refer you to the answer above as the basis for the answer to this question. If the question of digital preservation is not an issue, we need a way to consume, organize and maintain that digital media. Retrom and projects like it facilitate exactly that! How are you going to backup, maintain, distribute and scale your gaming library long-term when steam goes down – Dropbox???

I'd like to once again thank John for taking the time and chatting to me all about his work on Retrom. Its this kind of work, these kind of projects that I love to hear about, read up on, and try myself. The ones which are community made (with clear passion).

I hope you've enjoyed the chat we had, and maybe you'll be inspired to give Retrom a try yourself!

If you'd like to read more on Retrom, you can follow these links:

• The Retrom GitHub page
• John Beresford’s developer page.