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

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 a...

libhandy 0.0.10

libhandy 0.0.10 just got released, and it comes with a few new adaptive widgets for your GTK app. You can get this new version here . The View Switcher GNOME applications typically use a GtkStackSwitcher to switch between their views. This design works fine on a desktop, but not so well on really narrow devices like mobile phones, so Tobias Bernard designed a more modern and adaptive replacement — now available in libhandy as the HdyViewSwitcher . In many ways, the HdyViewSwitcher functions very similarly to a GtkStackSwitcher : you assign it a GtkStack containing your application's pages, and it will display a row of side-by-side, homogeneously-sized buttons, each representing a page. It differs in that it can display both the title and the icon of your pages, and that the layout of the buttons automatically adapts to a narrower version, depending on the available width. We have also added a view switcher bar, designed to be used at he bottom of the window: HdyView...

My Name is Handy, Lib Handy

Libhandy 0.0.7 just got released! I didn't blog about this mobile and adaptive oriented GTK widget library since the release of its 0.0.4 version three months ago , so let's catch up on what has been added since. List Rows A common pattern in GNOME applications is lists , which are typically implemented via GtkListBox . More specific patterns arose, where rows have a title at the start, an optional subtitle below it, actions at the end and an icon or some other widget like a radio button as a prefix. These rows can also be expanded to reveal nested rows or anything else that fits the need. So far every application using these patterns implemented the rows by hand for each and every row. It made using these a bit cumbersome and it led to inconsistencies in sizing, even inside a single application. To make these patterns easier to use, we implemented HdyActionRow , HdyComboRow and HdyExpanderRow . HdyActionRow The action row is a simple and flexible row, it lets...