Two new games for GNOME 3.16
Within a short period, two people showed up with proposals for games for inclusion with GNOME 3.16. One is a 2048 clone, the other is a revival of Atomix (last maintenance was GNOME 2.14). Both proposals seem to be maintained by just one person.
The 2048 clone might use a not-yet finished library. The usage of that library will help development of the library (easier when you have use cases, etc). Atomix needs to be ported from old technologies to the latest ones. If I’m not mistaken, I think I encouraged the inclusion of Atomix during the 2.x days.
I’m quite looking forward to having both games available on my machine. Being a packager for Mageia means that I can basically decide when that’ll be. Though Mageia currently is gearing up to Mageia 5 and that put limits on what I can do.
Game development by one person
The number of people on average making a games development by has differed a lot over since 1980s. Initially it was often one person, eventually big teams, then smaller again (flash games), etc. Jeff Wofford wrote a very detailed log of his experiences pursuing game development. According to the blog, one-man game development is done out of interest, but often also to make a (good) living.
Making money from game development in recent times is very short lived. If you make a game, it’ll quickly get cloned. Quite interesting is the number of available applications in the iOS app store.
I have no idea how long it takes to create a nice game for a mobile iOS. I do think above graph impresses me: more than 1.2 million apps within 4.5 years. How long have distributions been around? I recall trying either Red Hat 5.0 or 5.2.
How would this work under the distribution model?
With the distribution model and e.g. the 2048 game, say the game was originally made for Linux. Then once the development is over, you’ll have to persuade various distribution packages to include your game. This is easiest if you’re known. So aligning yourself with GNOME makes this process easier for you. To ensure your game is available under as many distributions as possible, you’ll have to search for the various distributions, then per distribution ensure that your game gets packaged.
Packing does have various benefits from a technical standpoint. No duplication of libraries, entire QA process, etc. I package at Mageia and I don’t like anything that’s not packaged. I basically won’t install it unless there’s a package for it.
Say your spend 2 weeks of development on your game until you have the first version that you want to beta test. After that you need to convince distributions to package it. Then these distributions have to ship their stable versions. After which your users have to upgrade their distributions. If you release a new version every 2 weeks (easily possible if your game is under active development): how likely will your users run the latest version? Distributions usually freeze their distribution to increase quality. This can take anywhere from a month to 4 months. Various distributions also require freeze exceptions for new versions of software.
To notice new versions, distributions use various methods. Fedora tries to download a potential higher number than whatever is within the distribution. It uses that to notify the packager. Then for various well known download sites (e.g. download.gnome.org) it checks the directory. At Mageia we check various download sites as well as other distributions. Which gets messy as we sometimes use a slightly different name.
If your developing a game or small application for Linux, the experience is just terrible.
xdg-app: A different trade-off
Various people within GNOME are creating a freedesktop.org additional way to distribute games and applications. Meaning: the intention is that it works not just for GNOME, nor just for one distribution. The details are available on https://wiki.gnome.org/Projects/SandboxedApps, though I’ll just copy/paste the two main goals:
- We want to make it possible for 3rd parties to create and distribute applications that works on multiple distributions.
- We want to run the applications with as little access as possible to the host. (For example user files or network access)
As the talk is about 45 minutes I’ll just recap a few things from it:
- Applications/games rely on a runtime
- Runtime: Something like GNOME 3.16 (or KDE, etc)
The GNOME 3.16 is around 400MB. The idea is that there aren’t too many runtimes and multiple applications can rely on one runtime. In case you have multiple runtimes and there are duplicate files between the runtime, the space is only used once. Further, when you update a runtime, you only download the differences (thanks to OSTree, see the LWN writeup).
- Demo: The presentation includes a demo about a recently funded application, Builder.
This application is still being developed. It requires libraries from GNOME 3.16. That’s still under development so usually (unless you run development versions of distributions), you’re pretty out of luck trying this out.
- Sandboxing/separation: The sandboxing is not perfect yet
Requires more work (pulseaudio and more). Further, any X app will always be able to record your keystrokes if they want. Meaning: Wayland. Further, there are some interdependencies between host OS and the runtime (for details see the talk).
- You can disable access to your network, your own files/homedirectory, etc
It uses things like pid namespaces, etc (see talk for details)
- You can install either system-wise or within your homedirectory
Now I didn’t fully watch the entire talk, nor read all of the discussion around it. I know that NVidia will only release their proprietary versions which will work with Wayland beginning of 2016 or so. The talk mentions wanting to use kdbus, which doesn’t have to be systemd-only, but, well…
It’s unfortunate that this talk wasn’t given at FOSDEM. There was one talk about Wayland+systemd application sandboxing, but I found it very lacking (I expected something like what Alexander Larsson spoke about).
I skipped over many details in this post. If you want more details, see the various links, post a comment or ask the people who actually know. For that and also if you want to work on something technically interesting: join the gnome-os-list mailing list.