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 <tak...@gmail.com> 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 <tak...@gmail.com> 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 <dili...@gmail.com> 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 <rabidpoob...@gmail.com> >>> 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" <tak...@gmail.com> 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 <tak...@gmail.com> 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 >>>>> >>>>> [1] https://kamikazow.wordpress.com/2017/02/09/adoption-of-flatp >>>>> ak-vs-snap/ >>>>> >>>> >>>> >>>> >>> >>> >>> -- >>> Kalasuri Diliup Gabadamudalige >>> >>> https://dahamgatalu.wordpress.com/ >>> http://soft.diliupg.com/ >>> 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. >>> ************************************************************ >>> ********************************** >>> >>> >> >
