In addition to Arch Linux wiki, informations about ./play.it can now be found on Debian and Gentoo wikis.

Link to Arch Linux wiki has been removed, as the article it pointed to does not exist any longer.

A link to an article on Ubuntu French documentation has been added to the opening post.

The link to the Ubuntu documentation has been updated, following a sneaky modification of the URL with no redirection.

./play.it 2.11.4 bugfix release

Hello World!

A new ./play.it release went live last night, and there was great rejoicing amongst all players using libre operating systems ;)
So let us see what this new 2.11.4 release brings with it…

Changelog

The modifications that this new version brings are published on the forge that is dedicated to ./play.it development, in release notes: 2.11.4 bugfix release

A copy follows: Website update

Alongside this list of fixes, ./play.it website has been updated, the most important changes being the merge of the two domains www.dotslashplay.it and wiki.dotslashplay.it, as well as the addition of an English presentation of ./play.it.

This updated website, based on DokuWiki, is available in two languages:

• English version of the website
• French version of the website

In addition to this update to the software description, usage instructions have been reworked to make them less intimidating for newcomers. Here are examples served through archive.org that should make it easy to see the improvement:

• old instructions template
• new instructions template

This new template is still far from being applied for all supported games, but should be used by all future updates of the website.

Distributions documentation

Last noticeable improvement coming with this update, new documentation articles have been submitted to some distributions that provide a package to install ./play.it. These can be found on the following pages:

• Debian documentation, in English
• Debian documentation, in French
• Gentoo documentation (English only)
• Ubuntu documentation (French only)

Whatʼs next?

2.11.4 version should (hopefully) be the last of the 2.11.x series, the next release being 2.12, an update that is coming with quite a lot of new features. For the most curious (or most impatient) amongst you, this new version is under preparation on our forge: WIP: 2.12 release

This 2.12 version is probably the one that has spent most time under development, with features that got developed as far back as November 2018!

Hello. First of all, thank you for your effort with ./play.it. I think I finally can find some time to take a better look at it, and hopefully present some feedback on your project from the eyes of someone who tries it for the first time.

When reading about your project, on the website, the first thing that comes to my mind is "why would I need this?" I think I had already mentioned this a while ago.

Lets be honest: we have Lutris, GameHub, Games Nebula as game installers and launchers, as well as adamhm's quite polished wrappers to create native packages. They all play ball in the same field as ./play.it, so this area is a bit crowded. And some of the projects I mentioned have pretty pictures and promise instant gratification. You can build the best of systems, but if you don't sell it well...

And it is not just the marketing I'm talking about. I am probably within the narrow target audience for ./play.it (a Linux user somewhat at ease with the system). I'm not even sure ./play.it provides the benefits I would expect from it. Devs should not expect users to put in the effort to learn their system so that they can understand if it suits them.

So please put in 15 or 20 minutes to correct this oversight add add a small list of benefits to using native packages for game installation to your website.

Not all of those are 100% guarantee too work though. I have had a number of issues with Lutris getting stuck in an install loop with many games from GOG so I am unable to play a lot of games using Lutris because it just fails to correctly install them, even when it states it does have proper scripts/shells for those games. Plus some games are missing from a few of these options that you have listed.

Also I had an issue getting Mirror's Edge running and again Lutris, and Gamehub just failed at installing them properly but the ./play.it package worked.

So having more options to get games working in Linux always helps.

I agree. I simply advocated for a better description of ./play.it in the website, so that new users can better understand its benefits.

And without even knowing it, you found the glaring issue on this front: writing a good presentation is not something you can do in 15 or 20 minutes ;)

The current presentation is actually the results of weeks of work (not joking here), that included the creation of articles in multiple languages, in the official documentation of multiple distributions (Arch Linux, Debian, Gentoo, Ubuntu) to gather feedback. Writing communication material is not an easy task, and I suffer from an unexpected handicap here: I know my software too well. By that I mean that there are a lot of things it does but I no longer see because they seem normal to me.

Your feedback tells me one main thing we need to work on: ./play.it is actually not similar to Lutris or any other game launchers, it is not even a launcher at all, but we do not convey this information like we should. I already spotted this issue, and tried to find a way to work on it, but as I do not use game clients (not even the obvious ones like Steam or Galaxy) it is a bit hard to do a comparison.

Actually I did it multiple times already, but I think only in French and never in a comprehensive way. The most important point to understand is: ./play.it does less than game clients do, and that is what makes it better.

A quick list form the top of my head of things ./play.it does not, and will never do:
• ./play.it does not download your games
• ./play.it does not keep track of your games collection
• ./play.it does not run your games
• ./play.it does not even install your games
• ./play.it is not required to run your games

In short, it makes only one single very focused task: taking a game installer in any messed-up format, and from it building a native package usable by your system tools (apt, pacman, emerge, …) to install your game with a perfect integration with your system.

This very clear-cut focus is the reason ./play.it often works when other software fails. Because other software have much more moving pieces that can break in unexpected ways.

And that is why I suggested a single paragraph. An introductory summary. I have seen too many project pages that neglect this simple message: why is this even relevant. I believe those projects are easily ignored. I do not wish that to your effort.

I did notice the vast improvement on the website and the painstaking effort it must have taken. I also know that documentation is not exciting or glamorous to write. Yet I see that you recognize its importance. That is great. But, as you stated, your familiarity leaves you somewhat blinded to the experience of a new user and that is how I wanted to help: presenting feedback and questions that, hopefully, would lead to a better experience for future new users.

Oh, I know that. That was clear to me, but it may not be clear for other people. And I mentioned it for a few reasons:
- It does process game installers, like launchers and clients, so there is room there for some confusion. I mean, you do talk about the same things.
- Form here it flows that I believe to be some competition, in the sense that ./play.it and game managers are a bit mutually exclusive. I mean that I don't think game clientst usually handle native software packages and if you don the conversions then I don't expect you'll go back to the original installer. (I don't mean to say it never happens.)
- Game managers and launchers have a much easier time explaining what they do through the use of nice pictures. I think ./play.it needs something to hook possible new users. I mean, you have clearly done the hard part. (I think. I have yet to delve more into that).

It does not need to be comprehensive in the early page, just "this may be of interest to you if..." or "read on if you are troubled by this problem". For example, I appreciated the fresh way in which git-annex (git-annex.branchable.com) did this, with use-cases.
Please don't take this as a critique of your effort or work. I'm just simply providing a point of view in a genuine interest to help.


I did a short test with the game "140". This is how it went (some questions may be answered in the documentation and I have not reached it yet).
The GOG installer seems to be more recent than your package. The filename (and content) have changed. It was easy enough to update the name and hash of the file and it ran fine. It must be difficult to keep on top of this and I naively suppose most installer updates are minor and should not cause trouble. I wish I could pass the installer's name as an argument to force it through.
Speaking of arguments, I wonder if there are any. Maybe using environment variables to change some behavior, like setting some prefixes? A casual look at the code showed none, but I'll look for it in the documentation. I just wanted to dive right in.
In Arch Linux I noticed the result were two tar files. They were uncompressed, which I found curious. Still, when using ports I did find funny that the packages were compressed only to be immediately decompressed for installation, so that is not a problem. I can always compress them myself. But why two packages? One for code and one for assets. I can see that in games where the code is subject to frequent updates but the date is much more stable. But here, I'll have to regenerate both at every update, right?
These are the questions that were on my mind.

Taking another look at the documentation (I understand this is going long already), I wish there was a page explaining how it works from a high-level perspective. The game-specific pages are fairly repetitive and self-contained. That is good in that, if I care only about this one game, I get everything I need right there. I wonder if it is easy to ignore some information on purpose (after being an advanced user).
I do question your information grouping by step. In line with your "get all the info you need right in this page", if I use Arch, why would I care to compare my installation instructions with Debian? Why not group it by distro? "Are you using Gentoo? Do this: 1, 2, 3, 4. Oh, its Debian, then do this: 1, 2, 3, 4." Wouldn't this also make it easier to update the documentation once you add support for other distros?
Also, I noticed that you were quite careful in using the actual filenames in the instructions. Why didn't you do that for point 4, where you provide the installation command?

Oh, through the Alpha Centauri page I saw there can be command-line options. It is odd that I cannot find a shorter path to reach this page. Are some scripts (like the one for 140) still being updated to add support for these options?

This is already too long. I'll leave pointing out that in the Alpha Centauri's page you have "version sold sur GOG".

First of all, thanks for the verbos feedback, it is highly appreciated ;) I try to answer most of your points below, but I might have missed a couple (it is the middle of the night where I live).

Due to the length of my answer (and the pitiful state of GOG forums), I will have to split it in multiple messages.

Actually I decided quite some time ago to no longer update this website, because we are working on a new one with a Web developer that joined our team one year ago. But as it actually takes a lot of time to get something really nice with no lost feature compared to the current website, I had to go back on this decision and work on a refreshed landing page.

I have been experimenting a bit with a new template, that has not been applied to the 140 page yet. You can see how it looks on the following page that already got the rewrite: Icewind Dale - Enhanced Edition

Sadly, most updates are not that trivial so we need to test all of them carefuly, and that is where we need a lot of workforce. For 140, we have a proposed update here: WIP: Game update: 140 - new archive + documentation support
As you can see, there is still something to fix before we can run more tests, and finally include it. Then there is still the information on the website to update. As you can see here and there, there are a lot of updates (including new supported games) that are already included in the current version of ./play.it, but are not advertised on the website yet.

You are not the only one, that is indeed a planned feature ;) Experimental support for unknown archives
Anyone with an account on our forge (registration is open to the public) can vote on feature proposals, we then use that to prioritize them.

Actually you can call any ./play.it script with `--help`, and it will list all the supported options. If you run it without any argument and no supported installer is found in the current directory, it will display the help information too.

After some discussion, we decided to use no compression by default, as most people seem to build packages to install them on the same machine, not always keeping the packages. But for Arch Linux we support gzip, xz and bzip2 compression, and our next feature release should add support for zstd compression. See `--compression help`.

We always try to build distinct packages for files that are architecture-specific (usually the engine) and for the ones that are shared between architectures (usually the assets). This is how most games are packaged in our distributions repositories.

A more generic documentation is planned, the new website will replace the old one before it is ready.

Mostly because this pages are written by hand, a very time consuming task ;) The info about most file names I can get easily, but for the generated packages I need to generate it from multiple sources of information (game id, archive version, script version, etc.). I wish we had an option to pass to a script to display the packages it would generate, but no one worked on it yet.

Alpha Centauri support has not been updated in a looong time, it still relies on ./play.it 1.x, so these are the 1.x options you see. Our current version, 2.11.4, is not compatible with these.

Hello. I greatly appreciate your time and effort in replying. And the forum is really moody, so this is attempt #2.

I thought the current website already looks quite well. I hope you are changing only for the sake of your convenience.

I also wonder how different are the games, and what makes them so unique in their packaging (and installation). Do you have anything written that you can point me towards where I can learn about it?
Of course, I don't mean to say every single game being the same. Not all Linux software on my distribution puts their config files in the same place; I want to say why don't they follow some sort of defacto standards? What sort of problems do you have to handle?
(I enjoy learning about this kind of explanation on project websites and I really think it helps bridge the gap between creators and users).

To handle the updates, I would propose that, when using a "--force" flag to ignore the hash, that you present an URL to the user and invite them to provide some feedback. But then again, maybe this addresses a problem you do not really have.

Another question I would like to ask (sorry, I did not have much time to look into this yet): how much work do you and adamhm share?

This is what I would like to do on my system, and I would like to request some feedback from the community, to see if ./play.it could help with it.

GOG seems to dump the game contents into a contained directory. This is in contrast with "native packages" that distros and ./play.it create.

What I would like to make is to transform this installation into a squashfs archive. The good that comes from it is:
- it is compressed quite well (I can tune the size/speed tradeof by choosing the compression algorithm used), so I can have more games installed in the same space
- one game is one file; it is easier to manage, archive and move across computers
- (consequence of the above:) I could pretty much forget about re-installing games; game and installer are just one; I could archive locally just this file instead of the GOG installers. When I want to play a game I could play them directly from my archive disk for faster startup. Always ready to go!

There are bad things too:
- These files are read-only
- There can be no space saving through de-duplication of files

I am currently using an union/overlay filesystem to address the read-only issue. This way I can keep my configs and saves whenever I need to reclaim disk space. And whenever I pop the game back in, all the saves are there. And if I want to get rid of them, I just remove a directory recursively.

So far I'm using FUSE for a userspace-only approach. But I'm thinking of using firejail, since it provides isolation of the filesystem and can disable the network (I read some games phone home and I'm a bit paranoid some times).

Could ./play.it support a squashfs backend? Would there be any gain for me from using ./play.it to support this system?

To make it short: on Linux, there are standards. Game developers do not follow them. *How* they do not follow them is what change from a game to another ;)
Sadly we have no "database" of all the ugly things we encounter, but between ./play.it contributors and enthusiasts we often share our horror stories via our IRC channel.

Almost nothing, our methods are very different. But I tend to give a very low priority to games that are already supported by Adamhm’s wrappers, I think it is better to focus on games that currently have no easy installation process for Linux.

Still, since we both use WINE, any bug fixed thanks to one of our projects will benefit to all other projects relying on WINE. So we benefit from the work of others event if we don’t dedicate time to coordination.

In the early days of ./play.it, using an overlay on top of read-only game data was a serious option. But in the end we dropped it in favour of our custom prefix system based on symbolic links between shared read-only data, and user-specific writable files and directories.

I think you could base your work on ./play.it in a quite simple way: adding the squashfs archive as a supported output format, in addition to the native packages we already support. The main upsides being:
• you would benefit from our existing games library
• our users base would help spotting bugs quicker than if you work alone
• a lot of games need workarounds to avoid crashes or unexpected behaviours, ./play.it already includes a lot of these
• we already maintain a list of files the user need write access to for each game