From Godot to RPM

Photo by Ilya Pavlov on Unsplash

With more games being developed with the Godot engine, we need to learn how to package these games for Fedora.

Developing a game is complex. The requirements for each game differ. In the past developers created new game engines for each game. Over time game engines become more generic. They adapt to cover a style of game. Some engines can create a wide variety of games.

Godot is a well known open source game engine. Both open source and closed source games use the system. The Godot packages for Fedora run these games but no RPM package examples exist.

Much of the packaging is the same regardless of the application. RPM spec files need summary, version, license, description, etc. For build requirements, you need the godot-headless package. Godot publishes a pck file but requires a graphical user interface to run. Godot headless builds a project without needing a graphical user interface.

Linux cannot run a pck file. By adding godot-runner to the requirement section of the spec, the game can run on systems which install the RPM. The pck file is not completely platform independent But I believe it will work on all Linux systems. The build architecture can be set to noarch for this reason.

The same setup macro for another program can extract the tgz file. No macros exist for building Godot projects. You call godot-headless with ‐‐export-pack option. You specify the export name and the output filename. The install section simply needs to create a directory in $RPM_BUILD_ROOT/%{_datadir}/%{name} and copy the output file. Specify the files section and you are ready to build.

...

BuildRequires: godot-headless
Requires: godot-runner
BuildArch:      noarch

...

%build
godot-headless --export-pack Linux64 pigeonascent.pck

%install
mkdir -p $RPM_BUILD_ROOT/%{_datadir}/%{name}
install -p -m 644 pigeonascent.pck $RPM_BUILD_ROOT%{_datadir}/%{name}

%files
%{_datadir}/%{name}

...

Anyone can run the game by installing the package and running godot-runner with the specified pck file. Searching for the application on the GNOME desktop will not find it. Searching for the application in GNOME Software will not find it.

Beyond the minimum

Two files can fix these problems but you may need a third. The first file allows you to easily run the game from the GNOME desktop. The desktop file has the name of the program, how to execute the program, and other details.

[Desktop Entry]
Name=Pigeon Ascent
Comment=Take care of your own pigeon as they fight
Exec=godot-runner --main-pack /usr/share/pigeonascent/pigeonascent.pck
Terminal=false
Type=Application
Icon=pigeonascent
Categories=Game;RolePlaying;

In addition to the Exec entry, many desktop files include TryExec that tests if the executable exists in the path. If you include it, it would be godot-runner. In this example we call godot-runner. We could create a shell script to allow you to run the program easily from the command line.

For the icon you may be able to reuse the icon in the Godot project. If it is not the right size or you want a scalable vector version, you will need to create it. For Pigeon Ascent the icon image needs to be one pixel bigger in both directions.

The other file gives meta information to GNOME Software. It contains yet another name and description. It also has links to the website and screenshots. For games, Fedora includes the Open Age Rating System. This gives descriptors to allow parents to determine if the game content is acceptable. The Open Age Rating System generates this section after you enter the information for the game.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Copyright 2021 Dennis Payne <dulsi@identicalsoftware.com> -->
<component type="desktop-application">
  <id>pigeonascent</id>
  <metadata_license>FSFAP</metadata_license>
  <project_license>MIT</project_license>
  <name>Pigeon Ascent</name>
  <summary>Take care of your own pigeon as they fight</summary>

  <description>
    <p>
      Take care of your own pigeon as they fight increasingly stronger foes, and
      then facing the legendary Pigeon God at the end… can you keep death far from
      your bird?
    </p>
  </description>

  <launchable type="desktop-id">pigeonascent.desktop</launchable>

  <screenshots>
    <screenshot type="default">
      <image>https://static.jam.vg/raw/777/31/z/30974.png</image>
    </screenshot>
    <screenshot>
      <image>https://static.jam.vg/raw/777/31/z/3097c.png</image>
    </screenshot>
    <screenshot>
      <image>https://static.jam.vg/raw/777/31/z/30982.png</image>
    </screenshot>
  </screenshots>

  <url type="homepage">https://escada-games.itch.io/pigeon-ascent</url>

  <releases>
    <release version="1.5.2" date="2021-07-16" />
  </releases>

  <content_rating type="oars-1.1">
    <content_attribute id="violence-cartoon">moderate</content_attribute>
    <content_attribute id="language-humor">mild</content_attribute>
  </content_rating>
</component>

Some additional changes are needed to the RPM spec to include these files.

Adding gdnative

Sometimes Godot is insufficient to perform the tasks needed for a game. Gdnative allows C++ code to be added to a project. The gdnative code can be packaged as a separate project if it is used by multiple Godot projects. Unfortunately you need both godot cpp and header files which use the same download filename. Instead of using a url for the source tag in the spec file, specify the renamed file and include a comment above with the url.

# https://github.com/godotengine/godot-cpp/archive/refs/tags/godot-3.3.4-stable.tar.gz
Source1:        godot-cpp-godot-3.3.4-stable.tar.gz
# https://github.com/godotengine/godot-headers/archive/refs/tags/godot-3.3.4-stable.tar.gz
Source2:        godot-headers-godot-3.3.4-stable.tar.gz

Building gdnative assumes the godot cpp and headers are one directory above gdnative project. The following prep and build code builds the gdnative project.

%prep
%setup -q
cd ..
rm -rf godot-cpp
rm -rf godot-cpp-godot-3.3.4-stable
%setup -T -D -b 1
cd ..
rm -rf godot-headers-godot-3.3.4-stable
%setup -T -D -b 2

%build
cd ..
mv godot-cpp-godot-3.3.4-stable godot-cpp
rmdir godot-cpp/godot-headers
mv godot-headers-godot-3.3.4-stable godot-cpp/godot-headers
cd godot-cpp
scons platform=linux generate_bindings=yes -j4
cd ../%{name}-%{version}
mkdir bin
scons platform=linux

The install section copies the dynamic library to the library directory. If you build an executable for your godot project, the gdnative library works in the same directory. To avoid duplication we create the pck file and use godot-runner. When running with godot-runner, the library needs to be in the same directory as specified in the project. Typically this will be gdnative/linuxbsd.

Install the godot project the same as a project without gdnative. Add to the install section to create a gdnative/linuxbsd directory. Create a symlink to gdnative library. In order to run the game, you need to add a Path entry to the desktop file and set it to the directory with the pck file. This causes the program to run from that directory which allows it to find the gdnative library.

Where to go

Pigeon Ascent is awaiting approval to be added to Fedora along with Gdnativegamerzilla. My Pinball Disc Room requires Gdnativegamerzilla before submitting. The developers of Pigeon Ascent also created Diver Down which I recommend. Godot Wild Jams are good places to look for Godot games.

Development on Godot 4 continues. It will not be backward compatible. I do not know if Fedora will ship both versions or if we will need to convert games to the new Godot. They plan on having a tool to help with the conversion.

Fedora Project community

11 Comments

  1. james

    cool. I hadn’t heard of Godot engine before. Do you think it might be possible to package it as a flatpak? It would be nice to see a tutorial here on packaging apps with flatpak…

    • It is possible to package it as a flatpak. I decided to limit this to RPM and perhaps do a followup article for flatpak.

      • james

        That would be cool, as there is a game that I want to package as flatpak, and so a tutorial would be nice.

  2. Creak

    With RPM, could there be an issue between the Godot version used by the game devs and the version of the godot-runner RPM?

    For instance, say the game devs made a game using Godot 3.4 and godot-runner gets updated later on with the upcoming 4.0 release. I’m not sure the PCK will continue to work.

    It seems to me that Flatpak looks like a better fit in this scenario since each game could pack with the needed Godot release, don’t you think?

    • There will definitely be an issue with 4.0 release. I mention that at the end of the article.

      Flatpak is certainly more likely to keep them running. However, I’m an open source game developer. I want to be able to modify the games. I would rather have the games upgraded to godot 4 so that I can still make changes.

      • Creak

        Oh sorry, I did see you wrote it, I thought I read the post to the end.

        Ah, in a perfect world, I would also like all the games to have their code open sourced.. maybe one day… 😉

  3. I believe you may be able to do the renaming of gdnative’s source tarballs using URL fragments instead of manually, see https://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_troublesome_urls

    • FeRDNYC

      kb1000 is correct. That packaging-guideline section is a little too terse IMHO, but there are literally dozens of examples of how to do this in the spec files. The GDnative URLs should be specified as:

      Source1: https://github.com/godotengine/godot-cpp/archive/refs/tags/godot-3.3.4-stable.tar.gz#/godot-cpp-godot-3.3.4-stable.tar.gz
      Source2: https://github.com/godotengine/godot-headers/archive/refs/tags/godot-3.3.4-stable.tar.gz#/godot-headers-godot-3.3.4-stable.tar.gz

      (Don’t forget the forward slash immediately after the # sign, which limits the filename to just the URL fragment.) That way, tools like spectool will be able to download the files automatically, and you won’t have to do any manual renaming.

      Then you can extract the files in your %prep using tar directly (which is a better idea than %setup, when you need to transform names):

      <

      pre>
      %prep
      %autosetup -p1
      tar -x -v -f %{SOURCE1} –transform=’s,^godot-cpp-godot-3.3.4-stable,godot-cpp,’
      tar -x -v -f %{SOURCE2} –transform=’s,^godot-headers-godot-3.3.4-stable,godot-cpp/godot-headers,’

      <

      pre>

      Your godot-cpp/ source tree will be correctly set up in the build dir.

      (Also, yes, if godot-cpp is going to be used for multiple packages, it should really be separately packaged and used as a build dependency, instead of every RPM having to download its own copy. If it needs to be packaged uncompiled, I believe a godot-cpp-source-3.3.4-1.fc35.noarch package would be well within the Guidelines.)

      • godot-headers could probably be packaged as some sort of “godot-devel” package, it’s the native interface of Godot itself.
        I’m not sure if it’s safe to package godot-cpp (does it have a stable API/ABI?), but if it is, it can be packaged as a binary (probably a static lib)… except for one special case. Most of godot-cpp is generated from a dump of Godot’s API produced by Godot itself. I don’t know if anyone actually does this, but it’s possible that a project modifies that dump or otherwise customizes it in order to publish its own API to native code, see https://github.com/godotengine/godot-headers#updating-headers
        But maybe I’m just too pessimistic and that’s entirely irrelevant.

  4. Andrea Musuruane

    What if the source godot game does not have an export_presets.cfg file like in this case https://github.com/wimpysworld/little-spy?

    • Dennis Payne

      The way to deal with a missing export_presets.cfg is to simply create one and include it as an additional source file/patch.

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions