This is an automated archive made by the Lemmit Bot.

The original was posted on /r/linux_gaming by /u/flwwhtrbt on 2024-09-11 23:27:16+00:00.

I’ve recently had the good fortune to have had Strider (developer of Lutris) agree to a little Q&A with me about what is behind Lutris, developing for Linux, and the community around the program.

I’m doing these ('little’ - I claim zero professionalism here, representing no site or publication) Q&A’s with developers for Linux programs. This is because I see very little about the people themselves behind the software we engage with so often. Most articles I read or videos I watch neglect a focus on the developers themselves, so I hope this might bring something different to the table. All I want is to get a little ‘peek behind the curtain’ - so to speak.

For anyone unaware: “Lutris is a video game preservation platform aiming to keep your video game collection up and running for the years to come. Over the years, video games have gone through many different hardware and software platforms. By offering the best software available to run your games, Lutris makes it easy to run all your games, old and new.”

So here we go!

Can you tell us a bit about yourself, Lutris and how it got started? I see that you initially made Oblivion Launcher, so this has clearly been your passion for a long time. What sparked you to jump from that to Lutris?

I had recently switched to Linux as my main OS, after using it on secondary machines for a while. I still wanted to play my games but at the time, it meant reading tutorials that would get outdated really fast or only worked on one distro. Getting games to run on Linux could become a very frustrating experience at times but it seemed that this could be considerably improved.

In a more broad sense, what was the inspiration behind creating Lutris?

Around that time I was using Cedega, a proprietary fork of Wine with a nice GUI. I wanted something similar but open source but I didn’t want to limit myself to Wine games like Cedega or PlayOnLinux did. I wanted support for all games that could run on Linux, which included native games and emulators.

Can you give us a brief overview of your team’s background and how you came together to develop it?

These days, the team is mostly Daniel Johnson, who does an enormous amount of user support on Github and GloriousEggroll who provides builds for Proton-GE. Then there’s the Open Wine Components project that encompasses other gaming projects and regular contributors on Github. There’s also a very active moderation team on the Discord server. There’s no fixed team structure, anyone can just come and go, do their own thing.

How has Lutris itself evolved since its initial release?

15 years ago, gaming on Linux was very experimental. With the evolution that happened in the past years, it’s now something we have integrated in our lives. Games running on Linux is now the norm. So instead of tinkering, we can shift our focus on making sure games keep running in the years to come, particularly games that are no longer being sold.

Tell me about your logo for Lutris!

The initial logo (the version with the Atari joystick) was designed by a friend of mine at the time and later received some updates to make it more readable at small sizes. It was always meant to take inspiration from Mozilla’s logos. A lot of projects have an animal as their logo: PHP, Postgres, Firefox… so I wanted my own animal mascot. I picked the otter because it’s an animal that likes to play!

What are the key features that set Lutris apart from other game launchers? There is a few now who offer similar capabilities, what makes Lutris so unique?

Lutris is the only launcher on Linux to support such a wide array of games from all platforms. Most launchers focus on Wine but Wine is only one of the 54 runners we currently support. The idea is to be able to build a collection of all the games you have played during your lifetime, easily accessible and playable.

How does Lutris integrate with Steam, especially on the Steam Deck?

The Steam integration is much more basic now than it once was when we used to run Steam in Wine. Running Steam games from Lutris only calls Steam with the correct Steam ID, the options in Lutris don’t apply to the Steam game. For the Steam Deck, it’s the opposite: Running Lutris games in Steam. We have a feature for creating shortcuts for Lutris games in the Steam UI. In the next release of Lutris, we’ll also have better support for running games with umu on the Steam Deck (it makes it possible to use Proton instead of Wine).

Could you explain how Lutris handles the management and optimization of non-native games?

We call runner any program that can launch games, native games being the only games that don’t require one. We provide binaries for those runners, which get updated on a more or less regular basis. The important is not using the latest version but having a version that can run games really well. For example, we ship DOSBox Staging to provide a better experience for DOS games. Wine / Proton is the only runner that receives some patching.

What features do you think are the most underappreciated by users?

Certainly the collection management and non Wine games aspects. I often see people with less than 10 games on Lutris and all mostly Wine based. On my end, I have over 1300 installed games for a variety of platforms. Sadly, the fact that people have switched from HDDs to SSDs doesn’t help building a large video game collection.

How do you prioritize and manage feature requests and bug reports from the community? I see you have such a sizable community built up around you (which speaks volumes to your skills as a programmer), can you describe what goes into prioritizing bugs or features?

If something is broken and impacts significantly the usage of Lutris then that gets the highest priority. Then comes the pull requests submitted by contributors. Bugs that can’t be reproduced or features that would only interest a small portion of users get the lowest priority.

Can you share any interesting stories or challenges you faced during the development of Lutris?

Between 2011 and 2012, the development of Lutris had crawled almost to a halt because of a game called Minecraft. At numerous times, maintaining the project felt very overwhelming and it was often difficult to deal with that. I often resorted to measures that were more or less clumsy but however gave me some breathing space (for a few months, reporting issues was only allowed to previous contributors, for example). Nowadays, managing the project is much easier. I put less pressure on myself to try and micro-manage everything and I get some precious help from the community to help me with Github.

How important has community feedback been in shaping Lutris? Can you give an example of a community-driven feature that you ended up implementing?

The community has a tendency to push for the adoption of newer technologies while I have a tendency to hold back a bit before we adopt anything new. Some people use lutris on quite outdated systems and we try not breaking anything until a distribution gets really old. Finding the right balance is quite an art but the community helps in knowing what is needed and which systems can be dropped.

Also, a few runners we have were entirely written by community members. Translations are another aspect that is heavily driven by the community.

How do you foster a positive and engaged community around Lutris? Your discord in particular are so positive about your product, how do you encourage your users to participate and contribute

I don’t have the time to do much on Discord but there is an amazing moderation team. Troublemakers are kicked out really fast which keeps the vibe on the server positive. Personally, I tend to engage more with the community on Github and Mastodon.

What tech and programming languages is Lutris built on?

The desktop client is using Gtk 3, the website uses Django. Both are written in Python. We also have a moderation dashboard written in VueJS.

Can you discuss the challenges and solutions in ensuring compatibility across various Linux distributions?

We’ve been shipping a set of libraries with Lutris trying to increase compatibility across distros. This isn’t a perfect solution but works for the most part. This is the approach Steam used to have. Now, similarly to Steam, we are transitioning to a container based approach, whether it’s pressure vessel with umu or Flatpak.

How do you approach optimizing performance for different hardware configurations, especially for the Steam Deck?

We don’t really have anything in place that target specific devices. We do however provide many option to let users find the best possible setting for their games.

How do you handle the rapid changes and updates, do the Steam Deck’s updates ever affect what you do?

There are some breakages once in a while but so far the Steam Deck with its immutable OS has been pretty stable. We’re still working on providing support for using Proton on the Deck’s game mode but it’s coming soon.

What are your short-term and long-term goals for Lutris?

Short term is the release of Lutris 0.5.18. It will contain all the fixes and improvements made during the past few months, but nothing really groundbr…

Content cut off. Read original on https://old.reddit.com/r/linux_gaming/comments/1feoc7q/my_qa_with_the_developer_behind_lutris_your/