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.