We’re at the Snapcraft Summit with a Godot developer.
The main goals are:
Provide an upstream snap for each supported release of the Godot Engine game editor - both GDScript and Mono versions
Enable support for exporting games for Linux directly as a snap from the Godot Engine
We’re looking to hand over maintenance of the Godot snaps to them. Active, professional game developers typically have multiple copies of the game editor “Godot Engine” installed to support building and maintaining multiple projects. The Godot developers maintain those releases (2.1 / 3.0 / 3.1) and are looking at how o facilitate parallel installs for game developers.
Tracks in snaps won’t be useful here as they need to have multiple copies of the snap installed. The current implementation of parallel installations isn’t complete for desktop applications (you can’t tell one icon from another, and it’s not simple for end-users to manage their parallel snap installs).
In addition we’re looking to enable the capability to export games as snaps directly from the Godot Engine. So a developer could snap install godot-3.1 (or indeed install it on Windows or MacOS), create their game and then export their game, and push to the store directly. This is a compelling feature and would streamline the publishing process for game developers.
To reduce the size and complexity of each game export, we proposed creating godot-runtime-x-xx platform snaps which contain the runtime components for each supported release of Godot. Games exported from Godot Engine (from any platform) as snaps would be smaller, and would leverage the godot-runtime-x-xx.
I spoke to @roadmr who confirmed that we cannot use tracks to facilitate this easily.
The outcomes of our discussion are as follows:
We hand over the name of the godot and godot-mono names to the upstream
The Godot developers register godot-2.1, godot-3.0 and godot-3.1 as snaps
The Godot developers register godot-runtime-3-0-7, godot-runtime-3-0-8 and godot-runtime-3-1-2, godot-runtime-3-1-3. With no plan to backport snap export to Godot Engine 2.1, so no need for a 2.1 runtime.
Repeat the same for godot-mono* engine and runtime snaps.
The runtime snaps would be unlisted, and as with the GNOME and KDE snaps, would only be installed by games which were exported from Godot.
Having separate runtimes enables the Godot developers to bump to newer versions of libraries such as Mesa enabling game users to get better performance. It also removes the burden from game developers to update their game snaps to leverage new drivers / libraries. Something traditionally game developers don’t do.
To reiterate and expand, there are two main blockers to using parallel snaps for this: lack of .desktop file support per instance, and parallel install support for classic snaps (this is IMO the main blocker).
With this in mind, I think the plan here is workable, if clunky; and it will become more so as new godot versions are released and need both their creator snap and the corresponding runtime. So I would also encourage close collaboration with the snap core developers to keep track of parallel snap feature implementation and maybe once it supports the required features, move to a unified “godot” and potentially “godot-runtime” snap.
For the record, the pattern used here is also used with e.g. wine, which shares the clunkiness, which is why it’ll be so nice when parallel installs can cope with classic and the desktop file issue.
dots are not allowed in snap names, so it’ll have to be godot-2-1 and so on.
Further to discussions had with @popey, the Snap Store team, and the developer, snap names starting with godot- have been reserved for the Godot project, to avoid a situation of someone else inadvertently registering a conflicting name.
This is all perfectly reasonable for snaps that consume the content snaps where the publisher of the game is the same as the publisher of the content (where the content snap is auto-connected by default).
It is my understanding that the more typical use case is that the content snap publisher and the game publisher will be different and that auto-connection of the runtime snaps is desired for this. Interfaces form contracts between the providing snap and the consuming snap such that the providing snap shouldn’t ever break consuming snaps and for content snaps (ie, the godot runtimes) that are supposed to be universally auto-connected, we’ve established a naming pattern for the ‘content’ attribute of the interface which is: <thing>-<version of thing>-<distro release/version> where <distro release/version> corresponds to the Linux distribution that the content was built on. In this manner, consumers of the content snap have a reminder that they want to use the same distro/compilers/stage-packages/etc as the content snap and as a reminder to the provider they need to create different content slots when they want to change distros/compilers/stage-packages etc.
Assuming that the godot runtimes are built on Ubuntu 18.04 (adjust below as necessary), I suggest one of the following:
godot-runtime-3-1 where the snap slots with content: godot-runtime-3-1-2-1804, content: godot-runtime-3-1-N-1804, etc
etc
While there are variations on the above, the important part for complying with our conventions is the content attribute. Option #1 keeps the runtimes small at the expense of a proliferation of content snaps. Options #2 and #3 keep the number of snaps smaller, but the snaps will grow in size as runtime content is added.
As a quick reply to the runtime snap name: Godot builds on old libc so perhaps it doesn’t need the per-base ABI agreement because it is essentially compatible with everything.
