Gogonlinux web API - Morgawr/gogonlinux GitHub Wiki

There isn't much to say about web API for the gogonlinux project.

We provide simple access methods to obtain the list of games and some other extra data to better integrate the gog.com games with the project.

The application accesses two distinct pages who provide JSON-formatted data.

The first page provides a list of available games, this is pretty much the official repository of supported games. The second page provides a list of game ID and md5 hashes to help with the update process.

The Repository API

Accessing the http://www.gogonlinux.com/available/ page you will have access to the list of supported games.

After 0.2.4 version of gogonlinux it is possible to specify custom created repositories (private repositories) to install games that aren't currently supported by the official repository. This private repository follows the same syntax/rules as the official repository and is a great help for developers who want to test their own ports before submitting them to the project. These private repositories can both be remote urls to user-created websites or just text files saved locally as long as they follow the proper JSON format.

Here's an example of a repository: https://gist.github.com/Morgawr/4739434

This repository contains only one game, which is "A New Beginning" (after all it's just an example). The syntax is a collection of data, each key is the id of a gog.com game, you can find the id of the game in the URL of the game card of that specific game on their website.

Each game in the repository is required to have the following fields:

  • title - the full title of the game, it's what will be shown on the gog-tux client.
  • cover_url - a link to the gog.com page providing the url of the cover image of the game (you can find it by inspecting the gog.com page with most modern browsers)
  • install_script - a location (either a link or a local file) pointing to the installation script to be run after the game has been extracted by the application
  • uninstall_script - a location (either a link or a local file) pointing to the uninstallation script to be run after the game has been removed from the system
  • launch_script - a location (either a link or a local file) pointing to the script that will be run every time the user wants to automatically launch the game
  • emulation - the type of emulation used by the game (wine, scummvm, dropbox)
  • gog_page - a simple link to the specific gamecard page on gog.com
  • compat - the compatibility of the game, how well the game runs on most systems. Can be either green, yellow or red
  • message - a message to be displayed before installing the game (usually a warning) on the GUI gogonlinux client. If no message is required then it's null
  • released - this value is used by the official repository to allow us to test for unstable/unreleased versions of games. Simply put it to 1.

For the three scripts (install/launch/uninstall) you can specify the value "404" to have it ignored, the application will skip the script (as there's none). This is what you usually want for the uninstall script as there's usually not much need of extra uninstall steps.

The md5 API

This is much simpler than the actual repository API. It is used by the application to check the md5 hash of the launch_script file and compare it with the remote one. If the local one is different then the application will re-download the official one. This is to allow updates of scripts and avoid users tampering/damaging their scripts (consistency checks and all of that). Obviously all updates are optional and users can decide which games to update/hold back.

The list containing all the md5 hashes can be found here. And here's a straightforward example: https://gist.github.com/Morgawr/4739543

First of all, it's a list of keys with the id for each game (as with the repository API). Each game will have the following fields:

  • md5 - the md5 hash of the whole file containing the launch script of the game
  • url - the resource (url) of the launch script that was hashed

It's that simple and straightforward. So far the project supports only the official hashed repository so user-created repositories won't have access to update features but who knows, in the future they might be implemented in the whole application as well.