[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Re: Playing with Flatpak packaging



Nice one!

Yeah, it looks like you could fairly easily generate the config files with tooling.



Data resources.

Your 3 points are fine with me. mygame/data/ with DATA_DIR is a good minimum requirement. I think it would work with most other games without too much refactoring too (resource managers, zip files where __file__ does not exist, web, etc).

However this layout is fairly common.
/data/
gamelib/
run_game.py

Also depending on the current working dir is fairly common. I used to use some code which would try and change the current working dir as the first thing. But realised this broke under all the different OSes that do all sorts of weird things.




Icons.

In the _javascript_ web world... icons are a big problem too. There's still lots of different formats required. There are tools to generate them from one larger one, but also allow providing specific ones.  grunticon is one such solution https://github.com/filamentgroup/grunticon

zero effort - pygame icon fallback
small effort - one large image resized as needed
more effort - every size of icon, and file type can be specified exactly.



On Mon, Mar 13, 2017 at 6:47 PM, Thomas Kluyver <takowl@xxxxxxxxx> wrote:
I was able to make a flatpak package quite easily for Solarwolf, using my Python 3.6 base app. You can see the files I added to do so here:
https://github.com/pygame/solarwolf/compare/master...takluyver:flatpak

I also made a Python 2.7 version of the base app (which was easy) and had a go at making a Flatpak package of Luke's pyweek entry. This works (though I can only get to the menu screen), but it required some changes to how asset files are found, and I chose to use a different layout of files (in /app/share/solarflair). Here are the changes and additions I made:
https://github.com/lukevp/pyweek23/compare/master...takluyver:flatpak

If you want to try to build either of them yourself, you will first need to build the necessary base apps from my repo here: https://github.com/takluyver/pygame-flatpak-test

The process for making these packages is still quite involved; I'd like to make some tooling to simplify it. But I think we need some conventions on structuring apps to make that possible - I don't think I can make an easily-understood tool that would handle the two very different layouts above. Allow me to start by describing how I'd ideally like apps to be structured:

1. Use entry points: an entry point is a reference to a function, like 'solarwolf.cli:main'. The launcher script imports that function and calls it ( from solarwolf.cli import main; main() ). Providing a main function like this allows tools to generate a script that does some setup before launching your code - e.g. adding directories to sys.path, or configuring handling for uncaught errors.
2. Include asset files inside the Python package: this means there's just one directory for the developer to specify which contains all the necessary files to run the game.
3. Don't rely on the working directory when loading data files: If you load assets from a path like 'assets/mysprite.png', it's easy for that to break when the game is installed. If you follow #2, you can easily construct an absolute path using the special '__file__' variable (see http://pynsist.readthedocs.io/en/latest/faq.html#using-data-files ), but if you don't do it like this, please at least use a variable like DATA_DIR=, and make all asset paths from that, so it can easily be changed in one place.

My existing tool Pynsist (for building Windows installers) enforces #1, and encourages #2 and #3. What do you think of these ideas? How could we make it easy for game developers to follow them? Are there other sources of variation you'd like to standardise?

It's not urgent, but I'd also like to find better ways to work with icons for apps. You provide icons in a range of sizes (e.g. 16x16, 32x32, 48x48, 64x64...), but you typically remove some details in the smaller sizes, so it's not just a matter of creating one image and scaling it down. Icons also use different formats on different platforms (png, ico, icns), and I don't think it's terribly easy to convert between them. Are there any tools or techniques people use for dealing with icons?

Thanks,
Thomas


On 7 March 2017 at 18:10, Thomas Kluyver <takowl@xxxxxxxxx> wrote:
It should be easy enough to make a base app using Python 2.7 - I just focus on Python 3 first, because that's what I'm most interested in.

As John pointed out, Flatpak is a Linux technology. I have also experimented with making it easy to build Windows installers for Python applications - my project for that is called Pynsist, and you can see an example using Pygame here:
https://github.com/takluyver/pynsist/tree/master/examples/pygame

(Pynsist does not use the Windows sandboxing mechanisms John described)

Eventually, I'd like to have a common format for describing Python applications, and a set of tools that can use that to build packages, installers, self-contained executables and so forth for different platforms. Pynsist would be one such tool, and my investigations into Flatpak will hopefully lead to another tool.

Luke: thanks, I'll look at what it would take to Flatpak-ify your game.

Thomas

On 7 March 2017 at 07:06, DiliupG <diliupg@xxxxxxxxx> wrote:
a python 27 version for windows would be GREATLY appreciated unless you consider python 27 users redundant and windows, not a real os.
:(


On 7 March 2017 at 02:28, Luke Paireepinart <rabidpoobear@xxxxxxxxx> wrote:
Would be great to try this on my pyweek entry if you're looking for games to test, just let me know how it turns out. It's called solar flair, but was developed with python 2.7 on Windows. I'm not sure on the compatibility with 3.x. - https://github.com/lukevp/pyweek23


On Mar 6, 2017 12:11 PM, "Thomas Kluyver" <takowl@xxxxxxxxx> wrote:
I developed this a bit further, though there's still more I hope to do with it.

It turns out that building a custom runtime is discouraged; the better way to support game developers is to build a 'base app', which people can then add their own game files to. I have prepared two different base apps: one includes Python 3.6, and makes a download of about 30 MiB. The other uses Python 3.4 from the shared runtime, so is a download of about 7 MiB. My idea is that the game developer can choose between the latest language features and a quicker installation.

My next step is to make a more complete example of using this to package a game (so far, I've tested with the 'aliens' example that ships with pygame). I might try with the solarwolf example on Pygame's Github org - or if anyone wants to suggest another suitable open-source game based on pygame, I could try with that.

Thomas

On 26 February 2017 at 19:47, Thomas Kluyver <takowl@xxxxxxxxx> wrote:
I spent a while today playing with Flatpak, a new system for packaging sandboxed applications on Linux. The result is an example that can build and install Pygame's Aliens example game:

https://github.com/takluyver/pygame-flatpak-test

If you're running Fedora 24+, Ubuntu 16.10 (might need a PPA?) Debian testing/unstable or Arch, you can install Flatpak and try it out.

This is quite rough at the moment, but I think it has good potential for distributing games to Linux users in the future. It looks like [1] Flatpak is on its way to becoming the default cross-distro app distribution mechanism for desktop Linux.

The big improvement I'd like to make is building a dedicated Flatpak 'runtime' for pygame, including a newer version of Python - the base runtime I'm using at present has Python 3.4.

Thanks,
Thomas





--
http://www.diliupg.com

**********************************************************************************************
This e-mail is confidential. It may also be legally privileged. If you are not the intended recipient or have received it in error, please delete it and all copies from your system and notify the sender immediately by return e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its contents is strictly prohibited and may be unlawful. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
**********************************************************************************************