Stone

Stone is a specification on how information in an emulator frontend should be handled, such as games records, and platform information. Stone does not specify how the specification should be implemented, only the format of the data the implementation may read in, or output. An emulator frontend must implement Stone-game and Stone-platform to be compliant with Stone emulators, all other parts of Stone are optional and can be implemented in accordance with the needs of the frontend. In essence, in order to be compliant with Stone and thus able to interoperate at a minimal level with all Stone emulators, only Stone-game and Stone-platform must be implemented.

Stone is still an initial draft. As more documentation is added, we will release version 1.0

Why Stone?

Game console emulators are ubiquitous in this age. It's wonderful how the games of old and new can be played on our PCs. Many of us have spent tens of hundreds of hours maintaining ROM collections and libraries for our frontends. However, there is no standard of compatibility between frontends. Switching frontends means spending hours reimporting or rescraping data for our games, for data that we've already gathered. Game library database schemas vary wildly between frontends with no one format to adhere to. We have conventions for the region and quality of the ROM, but no universal, unambiguous way to uniquely identify a certain console. As far as the computer knows, "Super Nintendo Entertainment System" and "SNES" are completely different consoles. One frontend may refer to one name, another the other name, or some both names. There's no way to know.

Stone solves this by providing 3 things that relate to how information about games and platforms are handled.

  1. A standardized game library database schema with a way to represent abitrary metadata
  2. Standardized unique identifier for all but the most obscure consoles
  3. A standardized way to store and access images, video, audio and other media relating to a game

With Stone, the most a user has to do would be to move around some files to switch frontends. No more re-scraping, no more guessing, no more time wasted.

Implementing Stone in your frontend

In order to implement Stone, your frontend must be able to use or link to

  1. A Javascript Object Notation (JSON) parser
  2. A SQLite library or other SQL database
  3. A Key/Value construct such as a Map or Dictionary must be available in the language of implementation

Stone considers compliancy when your game database is cross-compatible with other Stone-compliant emulators. Thus, only Stone-game and Stone-platform can be adhered to for compliancy. Stone-mediastore is optional to implement, however you will not be able to access media resources from frontends that have implemented the Stone-mediastore specification.

Terminology

  • A Serialization language refers to a human-readable data serialization format that is able to be deserialized back into an object in the implementation language. Examples include XML (eXtensible Markup Language), JSON (JavaScript Object Notation) and YAML (YAML Ain't Markup Language)
  • SQL refers to the Structured Query Language specification. Any implementation may be used, however, Stone expects SQLite, and conversion may be necessary if SQLite is not used.
  • JSON refers to the JavaScript Object Notation format as specified at http://www.json.org/
  • Game refers to the emulated game within a ROM, as well as the ROM contents itself.
  • Platform refers to the definition of a platform as specified in Stone-platform