Design What makes a launcher important?

[keturn]

As someone who has had some problems with the current state of the launcher, I've been excited to see it getting a lot of interest in project proposals! There's a description on the Ideas Board, and as we think about what technology the launcher should use and how it should achieve its goals, I think it would help to include some more detail about what it's important for the launcher to do.

[I know there is another thread about the launcher active now, probably even as I write this, but I wanted a thread to establish some requirements without letting myself get distracted by implementation choices of a specific proposal. <cough web cough>]

As I think about the ways to do the packaging and installation so it reliably works on the user's OS — whether that's through launch4j or packr, or another package manager like a flatpak container or a Lutris installer — I started to wonder, if one is going to develop the infrastructure and expertise to package platform-specific releases, why not do so for the releases of Terasology itself, and skip the launcher?

We might be able to learn a lot here from a compare and contrast with a launcher for another game a lot of Terasology fans may be familiar with, MultiMC. Thinking about what MultiMC did for me, it:

• authenticates me with the account servers
• gets a specific version of the game client
• gets a specific version of the modding system (Forge)
• installs the modding system for that instance of the game client
• unpacks a bundle of mods for that mod system
• can keep multiple such installations entirely separate from each other (the "Multi" of "MultiMC")

Which of those this is it important for a Terasology launcher to do?

A lot of what MultiMC does stems from the fact that the game client and the modding system are released by entirely different teams who have a very unequal relationship with the game's source code. One of Terasology's great strengths is that, as a player, I've never had to worry about how mods are managed. Whatever the multiplayer test server is running today, the game has just handled it for me, without me having to download anything extra or even restart my game client.

Terasology does have an identity service, but it's not like you need authorization from that in order to install or play the game.

The remaining feature, then, is the multiple installations.

Why do players have multiple installations?

Usually because different servers are running entirely different versions of the game. Servers may stay on an older version because it's difficult or impossible to migrate an old game world to a new version, or because the mods they use are only available for that version. The client and server versions have to match, because they need the same mods installed, and because protocols or object structures may change between versions.

If that's the motivating use case for the launcher, then it looks a lot different than, say, Steam. Steam installs one copy of a game for you and keeps it up-to-date. But if the user's goal is to have installations compatible with specific servers, then you need to build it around this multiple-installation idea. Maybe even put the server list in the launcher. (Or maybe a modpack list, for single-player experiences.)

What else is useful to be in something kept separate from the game client itself? Cervator mentions the crash reporter:

I don't want to lose track of one founding principle of the launcher: it was meant to be super simple to launch, specifically so it would work in cases where the full game might not, giving the user better odds to find useful troubleshooting information (like capturing typical log statements and telling the user in plain English (or even a translated language) that their video card likely isn't good enough).

There another helpful part is that the CrashReporter is hooked up to both the launcher and the game, making the usage easier, both can upload logs directly to the telemetry service etc.

I know, at one time, it was common to specify some other command-line options to the JVM. Usually about memory allocation, I think. Has that become less important with current JVMs, or do we still need some launch configuration just to tweak Java?

I've been a bit long-winded here, but I hope we can come up with some key points about why to maintain an independent launcher — or what packaging for releases needs to happen so they work without an installer — and fold that back in to project documentation.

 

[Cervator]

Thanks for the post

Yep, launch args are definitely still a thing :/

Other reasons for the launcher: Managing a remote server without launching the game itself, launching the game fully skinned and locked into a particular form of game (sometimes easier than "refreshing" an already running copy of the game), doing other light utility things like interacting with save games (backup, conversion..), etc. Possibly the launcher could even double as a map editor one day? I could come up with more reasons given the time. Multiple installations - yeah that's a somewhat weak factor in our case, that I'll admit

Another interesting factor would be having multiple games within the launcher, without wanting to turn it into another e-store or whatever. Still everything remains available separately, but it would be cool one day to be able to launch Terasology, DestSol, or even a whole other Java game or two we might come up with. All running with the same embedded JRE shipped with the launcher.

In short: I think of the launcher less as a game installer and more as a game manager for a variety of things I'd rather not have to run the full game for.

<cough web cough>

Is that a vote for or against web?