Accéder au contenu principal

GNOME Games 3.20 development

The last semester was quite crazy for me as I had to work restlessly for my studies, which let me very little time to work on GNOME Games. That being said that doesn't mean nothing happened in Games land! Here is what to expect in the next versions of Games.

What will be new in 3.20

GNOME Games 3.19.90 just came out and brought with him some changes. Besides several small bug fixes, Games have been refactored, polished and hardened to be ready to receive more important features on the next release.

Plugins

This is the biggest feature that have been added in this cycle.

Game formats in Games are handled by providing several types to handle them:

  • a Game to represent the games of that kind,
  • a GameSource to list the games of that kind (GameSource is a Game factory),
  • other classes could be added if necessary such as a Runner to run the games or a widget to display and control the games in the application's window.

Currently a game source gives its games, a game gives its runner and a runner gives its display.

In the previous stable version of Games, each of these classes existed directly in the application's code, meaning that the application had tons of format specific classes scattered all over its code and was explicitly handling each available game format. This couldn't scale well so we needed to make this even cleaner and more flexible and to do so a plugin system have been added every game format have been ported into its own plugin. Each of these plugins encapsulate the definitions of the GameSource, Game, and other helper classes corresponding to a single game format. Now the roles of each part of the code are clearer, better contained, and the application don't have an explicit list of available game formats but load them by looking at the available plugins.

Having plugins also have several extra advantages. A third party can create a plugin to support a new game format, put it in the right directory and bam, Games will magically support it! Another advantage is that you could disable support for systems you don't care about to make the application lighter, also some extra data that the plugins may need could be shipped directly with the plugin itself and not the application as a whole, making disabling a plugin even more efficient as they are self contained.

You can check the available plugins in the new Preferences window at the Extensions tag.

About dialog

Nothing fancy but we now have one. =)

Internationalization

Games can now be localized, don't hesitate to translate it in your language!

Work in progress

The most interesting stuff is to come. Here are listed features I started working on during the 3.20 cycle but didn't find the time to complete; now that I have some free time to work on them, you may expect them to land in 3.22!

Rich search

Currently we can search for games by their displayed title only. The plan is to make search richer by allowing to look for games by their format, genre, developer, publisher, release date...

We could even imagine crazier ideas such as searching by character names, the number of available player, etc..

Game identification

Most systems that Games handle or will handle have a more or less finite amount of games and no proper way to identify them: I'm talking about retro game consoles and handhelds. Often these game formats are very unconvenient to work with as they ship next to no metadata and are often available with hideous file names from which a title can't be easily guessed.

Some project like TOSEC and No-Intro started to work on a similar problem and produce databases relating fingerprints to well formatted file names.

I would like to have some way to identify a game and to get some useful information about it without having to scrap some online data base, and to empower such information to be more precise when looking for more data online. To do so I started working on a small XML based format called Gameinfo, used to link some game identifier (such as a ROM's fingerprint) to a game identity (mostly a title). I plan to ship such files embedded into the plugins they are related to and to use gettext to localize the games' titles.

Here is an example of a translatable Gameinfo file:

<?xml version="1.0"?>
<gameinfo>
  <games>
    …
    <game>
      <_title>Super Mario World</_title>
      <roms>
        <rom md5="4f17a1a17a098d0a5312703b55ad134b"/>
        <rom md5="7bb0487eacdb78d6635e89d797e5ab74"/>
        <rom md5="cdd3c8c37322978ca8669b34bc89c804"/>
        …
      </roms>
    </game>
    …
  </games>
</gameinfo>

Most of it works on my local branches but the code needs some serious cleanup before being published. Also I don't want to use and release such a file format without proper tooling to easily create, edit and update such databases, particularly from TOSEC ou No-Intro data files.

Keyboard configuration

Lots of games like the ones from retro consoles only support gamepad-like inputs, though you may want to play a game even if you don't have such a device. To do so we can bind keyboard inputs to gamepad inputs, allowing you to create multiple mock-gamepads in the process to allow multiple players at the same time.

We still need to find a proper way to bind such mock-gamepads to a gamepad port on the emulator and to let you select which one you want to use for which player.

Commentaires

  1. Hey, any reason this isn't on git.gnome.org? I know afranke will hate it being on GitHub since you advertise it as GNOME app.

    Cheers,

    Lasse

    RépondreSupprimer
    Réponses
    1. Sure: I just didn't have time to do so yet but that's definitely something I would love to do very soon, if not just now.

      Supprimer
  2. Hi Adrien will gnome-games be available in Fedora? I really would like to try it. Is there a Copr even?

    RépondreSupprimer
    Réponses
    1. I prefer not to promise any thing, but I'll work on distributing the application and its dependencies, probably starting by making it an XDG-App.

      For the moment you can test it with JHBuild, it is available as gnome-games in the gnome-world module.

      Supprimer
  3. yes! please make an xdg-app for gnome-games!

    RépondreSupprimer
  4. Réponses
    1. No it uses TypeMudule: https://wiki.gnome.org/Projects/Vala/TypeModules.

      I heard of libpeas only very recently.

      Supprimer

Enregistrer un commentaire

Posts les plus consultés de ce blog

Librem 5 ❤️ GNOME 3.32

I am glad to announce that the tooling I am working on since the beginning of the year is ready to be used!Thanks to new features introduced into libhandy 0.0.3 and 0.0.4 and thanks to a few fixes to Adwaita in GTK+ 3.24.1, you can make GTK+ 3 apps adaptive to work both on the desktop and on the upcoming GNOME-based Librem 5 phone.We are early in the GNOME 3.32 release schedule and the Librem 5 will be released a bit after it, so if you want your apps to work on the Librem 5, now is the best time: use libhandy 0.0.4 and up, use GTK+ 3.24.1 and up and target GNOME 3.32! A few apps like Fractal, Podcasts, Calls and Chatty are already using libhandy's adaptive capabilities, and other apps are working on their adaptive transition like Contacts, Games, Geary and Settings (all are works in progress). libhandy is available in Debian Unstable and Arch's AUR repository, and I wish it would be in Fedora already to let GNOME Settings' CI pass.For the moment, libhandy is a GTK+ 3 widg…

GTK+ Apps on Phones

As some of you may already know, I recently joined Purism to help developing GTK+ apps for the upcoming Librem 5 phone.Purism and GNOME share a lot of ideas and values, so the GNOME HIG and GNOME apps are what we will focus on primarily: we will do all we can to not fork nor to reinvent the wheel but to help allowing existing GTK+ applications to work on phones.How Fit are Existing GTK+ Apps?Phones are very different from laptops and even tablets: their screen is very small and their main input method is a single thumb on a touchscreen. Luckily, many GNOME applications are touch-friendly and are fit for small screens. Many applications present you a tree of information you can browse and I see two main layouts used by for GNOME applications to let you navigate it.A first kind of layout is found in applications like Documents, I'll call it stack UI: it uses all the available space to display the collection of information sources (in that case, documents), clicking an element from t…

One Widget to Adapt Them All and to The Librem 5 Port Them

In my previous article I shared my plans to help porting existing GTK+ applications to Purism's upcoming Librem 5 phone without having to fork them. This article will present the GTK+ widget I developed for Purism to make this happen.For more information on what Purism is working on for the Librem 5, please check Nicole Faerber's latest article.C'est pas sorcierThe underlying idea is to allow applications to dynamically switch between the two main GNOME application layouts: a row of panels — each panel being the view of an element from the previous one — and a stack of panels. The goal isn't to changes applications using the stack paradigm but the ones using the row one, allowing them to reach smaller sizes and to be usable on constrained sizes while keeping their initial paradigm and design when the screen space is sufficient. The development cost to port the applications to this adaptive design should be as low as possible.To achieve that, I wrote a GTK+ widget which…