Distro-agnostic advice for Godot Engine packaging
by Rémi Verschelde
Hi everyone,
First of all excuse me if I'm not using the proper channel for this,
but due to the lengthy nature of this email, I thought it more
appropriate on this mailing list than as a comment in a new bug report
asking for Godot to be packaged.
TL;DR: If there's interest I can work with you to get Godot packaged
in your distro, as I'm a Mageia (RPM) packager myself and Godot dev.
---
I maintain a good deal of games and related libraries for Mageia [2],
and am also an upstream contributor to Godot Engine [3]. I just
packaged Godot's new release, 2.0-stable, the spec file (RPM) of which
can be seen here [4].
Godot is a MIT licensed 2D and 3D game engine, which comes with a
feature packed editor and scripting language to make games easily and
export them to a wide variety of platforms (most desktop platforms,
android and iOS, HTML5 via asm.js).
I wanted to share some insider tips about how to package Godot most efficiently.
The game engine comes with various components, which would ideally all
be built and packaged, though only some (marked with (*)) are really
necessary. There are no "make install" instructions, so the
installation paths used are my own choice (and to some extent
recommendation):
- /usr/bin/godot(*): The editor tools for the X11 platform, built with
`scons p=x11 tools=yes'. This binary would be the whole game engine in
itself, so it's the only required thing to have a usable Godot engine
for developers.
- /usr/bin/godot-runner(*): To actually play Godot games (especially
libre ones that you might want to package, e.g. Minilens[5] or Tanks
of Freedom[6]), one only needs a version of Godot built without the
editor tools (`scons p=x11 tools=no'). All games can therefore run
with the same binary (provided they were designed for the same Godot
version). To avoid having to build Godot again for each packaged game,
I chose to have this -runner binary that can then be used with wrapper
scripts to launch each game (`godot-runner -path
/usr/share/games/minilens' for example). Note that the games could be
run directly with the editor-enabled `godot' binary, but as it's
bigger, it's likely better for players to have a smaller binary.
- /usr/bin/godot-server: This is the headless version of the Godot
editor (`scons p=server tools=yes'), that can be used to host game
servers or to do some editor operations without the GUI (exporting
games, importing assets, etc.). One could also package the version
without the tools instead (`scons p=server tools=no') but I chose to
keep the tools for more flexibility and avoid to have to make two
binaries for this.
- /usr/libexec/godot/templates/* (or /usr/lib/godot/templates/* on
Debian probably):
Godot uses "templates" to export game binaries to all supported
platforms, which are basically the same as the `godot-runner' binary
above, but not only for the same platform and architecture as the host
system. They are usually built from source or downloaded from the
website (building all of them involves a complex buildsystem,
especially for iOS, asm.js and android), and installed in
~/.godot/templates (before the question shows up, moving Godot's
userdir to XDG_CONFIG_HOME is planned, but was not done for 2.0-stable
to avoid breaking compatibility[7]).
It is also possible to define a path to look for system-installed
templates, hence the above proposed installation path. This would be
done by building the `godot' and `godot-server' binaries with
`unix_global_settings_path=/usr/libexec/godot' (the "templates/" part
is hardcoded, and documented here [8]).
The templates need to have very specific names to be recognized, see
my above-linked spec file [4]. So far I am only building Linux 32-bit
and 64-bit templates in release and debug modes, as I did not want to
make the buildsystem too complex. It's less than what most users would
need, but it's enough to have a "working" exporter on your distro, so
that users can readily export their game in a couple clicks and test
them on their host or other Linux hosts.
Then there are the SVG icon and desktop file, that's pretty
straightforward (I'm not using the upstream SVG icon as I don't like
it's "Android app-like" background :), so I made my own without the
background).
Some binaries (the templates and `godot-runner') are compressed with
upx, which is pretty efficient and what upstream does for their
official binaries. I'd be interested to hear about experienced
packagers whether this would be a bad practice as far as Linux
packaging is concerned though.
You will probably also find some libraries that you will want to see
unbundled. This is a noble wish and I also always try to unbundle
libraries in software that I package; for Godot however one has to
remember that the binaries produced (at least for the templates) need
to run on virtually any Linux distribution, and this pushes us to the
limits of "clean" packaging practices (though I obviously chose not to
bundle openssl, even if it means that the templates produced on other
distros are broken on Fedora, and reciprocally [9][10]).
For the main editor binaries though, if you see bundled libraries that
could/should be unbundled, I'd gladly work with you to achieve this.
Sorry for the lengthy email, but I hope it contains useful information
if you have packagers interested in Godot. The packaging method I
described above is also not necessarily the best way to package Godot,
and I'd welcome any feedback about it too.
Best regards,
Rémi Verschelde / Akien
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793057
[2] https://people.mageia.org/u/akien.html
[3] https://godotengine.org
[4] http://svnweb.mageia.org/packages/cauldron/godot/current/SPECS/godot.spec...
[5] https://github.com/KOBUGE-Games/minilens
[6] https://github.com/w84death/Tanks-of-Freedom
[7] https://github.com/godotengine/godot/issues/3513
[8] http://docs.godotengine.org/en/latest/reference/packaging_godot.html
[9] https://github.com/godotengine/godot/issues/1391
[10] https://bugzilla.redhat.com/show_bug.cgi?id=1277662
8 years, 1 month
Code::Blocks
by Dennis Payne
I understand why people use IDE. I don't care for them but I can
understand why someone would like them. IDEs should allow you someway
to compile from the command line. Code::Blocks does this but fails in
the end. Despite being used from the command line, it opens a window to
display results. Obviously this fails when running without X to build
an rpm.
I don't suppose some program in fedora has a way to build from a
codeblocks project. It's not hard to build a makefile. There is also a
cbp2make program but it doesn't appear to be package for Fedora. I was
just trying to keep using the Code::Blocks project file.
--
Dennis Payne
dulsi(a)identicalsoftware.com
Roon's Raccoon Sprintladder: https://ideas.lego.com/projects/126010
8 years, 2 months
SFML anyone?
by Dennis Payne
I've ported Ostrich Riders to the latest SFML. When I run it, I get a
window saying:
“Ostrich Riders 0.6.1” is not responding.
You may choose to wait a short while for it to continue or force the
application to quit entirely.
The program is running fine despite the warning. If you click wait you
can continue on your merry way. However, I don't find that acceptable.
Does anyone what can be done to prevent this? I tried a simple example
for SFML I found online. It too caused the popup. Both functions use
sf::RenderWindow::pollEvent. Using sf::RenderWindow::waitEvent doesn't
have that problem but the program won't work properly that way. Does
anyone know of programs in Fedora using SFML? Do they have this
problem?
--
Dennis Payne
dulsi(a)identicalsoftware.com
Roon's Raccoon Sprintladder: https://ideas.lego.com/projects/126010
8 years, 2 months
