(2017-07-31, 06:17)Wintermute0110 Wrote: Also, AEL has a lot of features regarding organisation of the games database (including a pretty complete XML ROM database, still in development) and many features that could be useful when designing the games database in Kodi core. AEL could be used as a test laboratory of how the games should look (or not... maybe AEL is doing some things wrong and could be improved).
This is perfect. I want to base Kodi's game library off an existing one. We could even have AEL be the de-facto library until Kodi has its own.
(2017-07-31, 06:17)Wintermute0110 Wrote: Retropayer differentiates between Developer and Publisher whereas AEL has Studio.
IMO we should just have Developer. We can drop publisher, because I don't really care who made money off the game. I want to know who put real work into it. I like Developer better than Studio because all studios are developers, but not all developers are studios.
(2017-07-31, 06:17)Wintermute0110 Wrote: (2017-07-26, 22:07)garbear Wrote: Can you extract these into a declarative data format? Do you have any experience with JSON-LD?
Your wishes are orders. Just give and example of the JSON-LD output format you want and I will create an script to export the platform information. I will place the scrip in AEL-offline-scraper repository: it is a helper repository I use to develop the scrapers and includes AEL addon as a Python submodule to reuse code.
The idea behind linked data is that you can compute over the semantics (meaning) of data using a standard representation, instead of having to customize your app every time someone comes along with a new idea of how game platforms should be organized.
This plays into the design of the python scraper that topfs2 wrote for his GSoC project, a metadata extractor:
https://github.com/topfs2/heimdall
This metadata engine is able to "reason" about metadata. For example, if a scraper reports three types of platforms:
- Game Boy
- Game Boy Color
- Game Boy Advance
And if we only show two platforms in the GUI:
- Game Boy
- Game Boy Advance
Then the scraper could infer that Game Boy Color games should be shown under the Game Boy library node, because we've expressed the relationship that Game Boy Color IS-A-TYPE-OF Game Boy using linked data. Note that there's no imperative program that says "If Game Boy Color -> then Game Boy". We just write the declarative rule "Game Boy Color is-a-type-of Game Boy" and the metadata engine infers that Game Boy Color games should be shown as Game Boy games.
There's obviously advantages to this system, but it comes with disadvantages too. Using linked data to express relationships has a lot of cognitive and labor overhead. It requires more advanced logic to perform inference using the relationships. However, I think it's worth it, because declarative rules are easier to verify than imperative programs. A declarative rule is either "True" or "False", but a program can have many possible mistakes and failure modes, most of which are impossible (or time-intensive) to test for.
So here's what JSON-LD looks like, using game controllers as an example:
First, we split the linked data into Schemas and Instances. The schema I created for a game controller looks like:
Code:
{
"@context": {
"@base": "http://github.com/kodi-game/ontology/#",
"label": {
"@id": "http://github.com/kodi-game/ontology/#label",
"@container": "@language"
},
"description": {
"@id": "http://github.com/kodi-game/ontology/#description",
"@container": "@language"
},
"gamePlatform": {
"@id": "http://github.com/kodi-game/ontology/#gamePlatform",
"@type": "@id"
},
"faceButtons": {
"@id": "http://github.com/kodi-game/ontology/#faceButtons",
"@container": "@set"
},
"shoulderButtons": {
"@id": "http://github.com/kodi-game/ontology/#shoulderButtons",
"@container": "@set"
},
"triggers": {
"@id": "http://github.com/kodi-game/ontology/#triggers",
"@container": "@set"
},
"analogSticks": {
"@id": "http://github.com/kodi-game/ontology/#analogSticks",
"@container": "@set"
}
}
}
An instance of a game controller, for example a 360 controller, looks like:
Code:
{
"@context": "<URI to above JSON>",
"@type": "controller",
"label": {
"en": "Xbox 360"
},
"description": {
"en": "The Xbox 360 controller is the primary controller for the Microsoft Xbox 360. The wired and wireless versions are also compatible with Microsoft Windows."
},
"gamePlatform": "https://github.com/kodi-game/ontology/#platform/microsoft-xbox-360/",
"faceButtons": [
"a",
"b",
"back",
"down",
"guide",
"left",
"leftthumb",
"right",
"rightthumb",
"start",
"up",
"x",
"y"
],
"shoulderButtons": [
"leftbumper",
"rightbumper"
],
"triggers": [
"lefttrigger",
"righttrigger"
],
"analogSticks": [
"leftstick",
"rightstick"
]
}
Here's an example of how it would work:
A scraper consults a website (like thegamesdb.net) and discovers that a 360 controller belongs to the 360 platform. The JSON-LD for this looks like:
Instance:
Code:
{
"@context": {
"@base": "http://schema.org/",
"gamePlatform": {
"@id": "http://schema.org/gamePlatform",
"@type": "@id"
}
}
Schema:
Code:
{
"@context": "<URI to above JSON>",
"@type": "platform",
"gamePlatform": "http://thegamesdb.net/platform/microsoft-xbox-360/"
}
OK, so we know the game platform is of type "
http://schema.org/gamePlatform" and the instance is "
http://thegamesdb.net/platform/microsoft-xbox-360/". We want the game platform type to be "
http://github.com/kodi-game/ontology/#gamePlatform" and instance "
https://github.com/kodi-game/ontology/#p...-xbox-360/". So we would create a JSON-LD relationship (called a triple) using the relationship
IS-A that expresses that:
"
http://schema.org/gamePlatform" IS-A "
http://github.com/kodi-game/ontology/#gamePlatform"
The metadata extraction engine that topfs2 wrote could then infer that a 360 controller from gamesdb.net should be shown under the 360 category in the GUI.
So that's my introduction to JSON-LD. We should start by designing a schema, and then fill it in with all the game platform knowledge we know about. Do some research and try to design a schema, and I'll help out if you get stuck.
We probably won't have a game library for v18, but RetroPlayer is merged and shipping whether I want it to or not. We'll probably start shipping beta releases in a few months, so time for the more important features (file parsing, Android support, BIOS support, and better save support) is running out.
