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

The Path to GNOME Games 3.26

Games received a non-negligible amount of changes that you will find in 3.26. These changes can be big as much small, and more are to come!Building the Games CollectionGames presents your games collection and if everything goes as expected, it does so without the need of any input from you. From an implementation point of view it sounds simple to do, just ask Tracker “Hey, gimme all the games” and it’s done. If only it was that simple! 😃 The system has no idea which files represent games and which doesn’t, but it can associate a MIME type to each file thanks to shared-mime-info. shared-mime-info already had a few video game related MIME types and we added a lot more such as application/x-genesis-rom.That done, we can query Tracker for files having specific MIME types that we know to often represent video game files. Unfortunately, each of these files doesn’t necessarily represent a game and a game isn’t necessarily represented by a single file: some files may be invalid and hence rep…

GNOME Games 3.24

GNOME 3.24 will be out in a few weeks and with it will come Games 3.24. This new version will offer a few new features and many refinements, some of which have been implemented by new contributors theawless and Radhika Dua, kudos to them!Find how to get the latest nightly and (soon) stable Flatpak versions of Games on its web page.A Libretro Core Descriptor SpecificationIn its version 3.22, Games stopped using a hardcoded list of well known Libretro cores and instead looked for the right one to run a game by parsing files describing their corresponding Libretro core's capabilities. These files came from the libretro-super repository and were slightly modified to better suit Games' needs.The concept was great but the format of these files proved to be not very well suited for the job: many information were not useful to Games, some information it needed were lacking, the syntax wasn't specified, complex cases like firmwares were implemented in a messy way, some useful infor…

retro-gtk: The Future, Marty!

Let's come back to retro-gtk. In the previous articles I explained how bad retro-gtk was, what I did to start improving it and more importantly what I did to prepare the terrain for further development. This article will detail the aforementioned planed improvements! Unless stated otherwise, I don't plan these changes to be part of retro-gtk 0.14 and I have no idea when they will be implemented. If I say anything you know to be wrong or if you know something which could help the library's development, please share it in the comments!Stabilization of the APIAs stated in the previous article, I want retro-gtk's API to stop breaking as much as it did in the past. Starting with 0.14, we will avoid API and ABI breaks as much as possible, and if we do any we will document them properly. The API should be stable but given that some big changes are coming I don't feel comfortable promising proper stability just yet.GitlabI requested to move retro-gtk to GNOME's GitLab. …