Photo byIlya Pavlov onUnsplash
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 thegodot-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-headlessRequires: godot-runnerBuildArch: noarch...%buildgodot-headless --export-pack Linux64 pigeonascent.pck%installmkdir -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 runninggodot-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.
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 AscentComment=Take care of your own pigeon as they fightExec=godot-runner --main-pack /usr/share/pigeonascent/pigeonascent.pckTerminal=falseType=ApplicationIcon=pigeonascentCategories=Game;RolePlaying;
In addition to theExec entry, many desktop files includeTryExec 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. TheOpen 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>moderate</content_attribute> <content_attribute>mild</content_attribute> </content_rating></component>
Some additional changes are needed to the RPM spec to include these files.
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.gzSource1: godot-cpp-godot-3.3.4-stable.tar.gz# https://github.com/godotengine/godot-headers/archive/refs/tags/godot-3.3.4-stable.tar.gzSource2: 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 -qcd ..rm -rf godot-cpprm -rf godot-cpp-godot-3.3.4-stable%setup -T -D -b 1cd ..rm -rf godot-headers-godot-3.3.4-stable%setup -T -D -b 2%buildcd ..mv godot-cpp-godot-3.3.4-stable godot-cpprmdir godot-cpp/godot-headersmv godot-headers-godot-3.3.4-stable godot-cpp/godot-headerscd godot-cppscons platform=linux generate_bindings=yes -j4cd ../%{name}-%{version}mkdir binscons platform=linuxThe 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 aPath 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.
Pigeon Ascent is awaiting approval to be added to Fedora along withGdnativegamerzilla. 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.
Dennis is a Fedora packager and game developer. He loves exploring open source games. Recently he has been promoting an open source game achievement system called Gamerzilla.
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…
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.
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… 😉
I believe you may be able to do the renaming of gdnative’s source tarballs using URL fragments instead of manually, seehttps://docs.fedoraproject.org/en-US/packaging-guidelines/SourceURL/#_troublesome_urls
kb1000 is correct. That packaging-guideline section is a littletoo 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 packageduncompiled, 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, seehttps://github.com/godotengine/godot-headers#updating-headers
But maybe I’m just too pessimistic and that’s entirely irrelevant.
What if the source godot game does not have an export_presets.cfg file like in this casehttps://github.com/wimpysworld/little-spy?
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
Fedora Linux 41 is available now. Read therelease announcement for all the details.
Fedora Magazine is looking for contributors!
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