[Wintermute0110]

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.

Agreed. I will rename Studio into Developer in next version.

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.

OK. Looks a little bit complicated at the moment for me.

I will concentrate into finishing the XML Offline Scraper database and refurbish the platform names keeping in mind the design of the platform schema. It's going to take me a while.

[garbear]

I will concentrate into finishing the XML Offline Scraper database and refurbish the platform names keeping in mind the design of the platform schema. It's going to take me a while.

Sounds like a big project. Keep me updated on the status.

[garbear]

I've created a player manager window in the GUI:




It came out far uglier than I imagined. I worry that using a single dialog for two purposes (assigning players to ports and choosing port hardware) overcomplicates things. It might be better to split this into two dialogs.

[Julipo]

You can add a build with this so people can test this and explain how they expected the use case or what they think that can improve the actual experience.

Looking your screenshot I expect that this is something like:
In the top grid I can add controller configurations* (configure my Xbox 360 pad, y Logitech, do a keyboard configuration with WASD, other with arrows...)** and, then, I move this configurations (squares in the grid) to slots in the bottom grid, that represent "plug" the configuration in the input 1, 2, 3... of the system (emulator).

* If this is right, the title "Game Ports" is a little confusing for me, but is possible that this is because my english is very bad
** I see in your images SNES and Xbox icons, but I expect that this works as some other libretro system: I can configure a generic RetroPad that maps all the cores

[garbear]

You can add a build with this so people can test this and explain how they expected the use case or what they think that can improve the actual experience.

Not really, the controller icons were added in photoshop. It takes a lot of work to build the dialog, so I'd rather figure out what I want before sinking much more time into it.

Looking your screenshot I expect that this is something like:
In the top grid I can add controller configurations* (configure my Xbox 360 pad, y Logitech, do a keyboard configuration with WASD, other with arrows...)** and, then, I move this configurations (squares in the grid) to slots in the bottom grid, that represent "plug" the configuration in the input 1, 2, 3... of the system (emulator).

* If this is right, the title "Game Ports" is a little confusing for me, but is possible that this is because my english is very bad
** I see in your images SNES and Xbox icons, but I expect that this works as some other libretro system: I can configure a generic RetroPad that maps all the cores

It works a little differently. "Game Ports" are the virtual hardware connected to the console. So for SNES emulator, these are SNES controllers and hubs. "Players" are the physical controllers connected, and the user can assign them to ports by moving their controller right or left.

The "Game Ports" group exists because we fine-grained control over connected hardware, as games can act differently depending on the peripheral configuration.

See, it's a bit confusing. That's why I'm considering making this two dialogs. What are your thoughts on how to make it less confusing?

[MrTarantula]

This is an assumption, but a large number of users will not make use of such granular controls (although I believe they should be implemented). Could there be a "Basic" mode that maps players to ports 1:1, only adding multi-taps if needed? Then the existing dialog could be "Expert" mode. There's precedence for this in Kodi settings.

[natethomas]

If I'm understanding you correctly, I don't really know why you'd ever list player number (at least as it's designed here). The only thing people will care about is what player they are in the game and whether all the necessary peripherals are set up, right?

...

I had an idea, but I've realized it matters quite a bit when this Player manager is going to pop up. In the past, I think we've assumed that Kodi will assign players based on when controllers are connected, if they are connected after launch, and then when controllers are touched, if they were connected before launch, with actual controllers being given preference over keyboard controllers.

If that's the case, when would the Player Manager be launched? When a controller is assigned incorrectly?

[sectune]

You can add a build with this so people can test this and explain how they expected the use case or what they think that can improve the actual experience.

Not really, the controller icons were added in photoshop. It takes a lot of work to build the dialog, so I'd rather figure out what I want before sinking much more time into it.

Looking your screenshot I expect that this is something like:
In the top grid I can add controller configurations* (configure my Xbox 360 pad, y Logitech, do a keyboard configuration with WASD, other with arrows...)** and, then, I move this configurations (squares in the grid) to slots in the bottom grid, that represent "plug" the configuration in the input 1, 2, 3... of the system (emulator).

* If this is right, the title "Game Ports" is a little confusing for me, but is possible that this is because my english is very bad
** I see in your images SNES and Xbox icons, but I expect that this works as some other libretro system: I can configure a generic RetroPad that maps all the cores

It works a little differently. "Game Ports" are the virtual hardware connected to the console. So for SNES emulator, these are SNES controllers and hubs. "Players" are the physical controllers connected, and the user can assign them to ports by moving their controller right or left.

The "Game Ports" group exists because we fine-grained control over connected hardware, as games can act differently depending on the peripheral configuration.

See, it's a bit confusing. That's why I'm considering making this two dialogs. What are your thoughts on how to make it less confusing?

hey garbear,
I liked your explanation and using this explanation and looking at the image posted it sounds clear and logical to me. Why not rename the "Game Ports" to "Virtual Hardware connected" and "Players" to "Physical controllers/joysticks"?

[garbear]

If I'm understanding you correctly, I don't really know why you'd ever list player number (at least as it's designed here). The only thing people will care about is what player they are in the game and whether all the necessary peripherals are set up, right?

Player number is part of the libretro API. Like the "retropad", this is an abstraction created to make all emulators conform to a single API.

Whether we should burden the user with this API detail is debatable. All the effort I sank into the controller dialog was to hide the retropad abstraction. I'm OK putting in work to hide player numbers if we can figure out how.

I had an idea, but I've realized it matters quite a bit when this Player manager is going to pop up. In the past, I think we've assumed that Kodi will assign players based on when controllers are connected, if they are connected after launch, and then when controllers are touched, if they were connected before launch, with actual controllers being given preference over keyboard controllers.

If that's the case, when would the Player Manager be launched? When a controller is assigned incorrectly?

The Player Manager is accessible from the root game OSD during gameplay.

I liked your explanation and using this explanation and looking at the image posted it sounds clear and logical to me. Why not rename the "Game Ports" to "Virtual Hardware connected" and "Players" to "Physical controllers/joysticks"?

"Game Ports" used to be called "Virtual Ports", but I renamed it to target users who don't know what virtualization means. I'm looking for better titles, but it has to be accessible by people who don't understand emulation. That's why I'm thinking of hiding it in a separate dialog.

[grumpygamer]

Hello fellas, I was just having a look at this thread and saw that mega screen with loads of controllers.
I think we need to try and keep the process fairly simple, it seems very confusing right now.
I will try and come up with some more sketches based on the initial post with all the requirements (some them are a bit difficult to understand for me though)
Perhaps a wizard-based solution would be ideal?

[ironic_monkey]

Never ever have wizards been the solution to anything. At best they are shoddy workarounds. .02c

[longelf]

Just looking at the configuration screen, and day-dreaming a bit, my ideal set up for this would be to have a group of icons representing the currently connected controllers. If a controller is added a new icon appears, if one is disconnected the corresponding icon disappears. Pressing 'A' on a controller 'picks up' the icon for that controller, allowing it to be moved into empty slots representing the virtual ports for the emulator, but labelled 'Player 1' etc. Pressing 'A' again would drop it into that slot. There would also be slots for spectators, as in the image above, to contain connected controllers that are not going to be used. Personally I wouldn't need anything more complicated than that, but there may be some power users who would want more control over things. One wishlist item might be that pressing another button allows you to configure/reconfigure the controller buttons, with the new configuration saved either for the emulator in general, or for the specific game being played, including being able to match buttons to virtual keyboard presses for DOS games and such. These configurations could be shared with the community too, maybe downloadable from within this dialog.

[garbear]

Hello fellas, I was just having a look at this thread and saw that mega screen with loads of controllers.
I think we need to try and keep the process fairly simple, it seems very confusing right now.
I will try and come up with some more sketches based on the initial post with all the requirements (some them are a bit difficult to understand for me though)
Perhaps a wizard-based solution would be ideal?

I'd love to see your sketch. I'm thinking of hiding the virtual ports and only showing them from the player menu (which opens when a user selects their controller or presses Select+A).

Just looking at the configuration screen, and day-dreaming a bit, my ideal set up for this would be to have a group of icons representing the currently connected controllers. If a controller is added a new icon appears, if one is disconnected the corresponding icon disappears.

This is how it currently works, I think.

Pressing 'A' on a controller 'picks up' the icon for that controller, allowing it to be moved into empty slots representing the virtual ports for the emulator, but labelled 'Player 1' etc.  Pressing 'A' again would drop it into that slot.

We do something close. We need to handle both controller navigation and remote navigation.

With a remote, so you select a controller, get a dialog, and then select "Move player" or something which will "pick up" the controller.

With a controller, you can use the remote navigation, or you can press Select+Right or Select+Left to move your controller without picking it up.

One wishlist item might be that pressing another button allows you to configure/reconfigure the controller buttons, with the new configuration saved either for the emulator in general, or for the specific game being played, including being able to match buttons to virtual keyboard presses for DOS games and such.

That's the plan. The user can configure buttons for devices and the maps are saved per-user.

These configurations could be shared with the community too, maybe downloadable from within this dialog.

That's also the plan, but this requires infrastructure which is a long way off.

[longelf]

This is how it currently works

...

That's the plan.

..

That's also the plan.

Well OK then  

Awesome sauce

[grumpygamer]

Hello, I put together a small idea about how I think it should work.
I have no clue how the machine looks under the hood and doing this is quite difficult from a distance  so I hope I got it right!
Please don't bash me around for the styling etc... it's just a prototype in a VERY infant stage and put together in 10 minutes.

https://xd.adobe.com/view/07368653-8b14-...aebd5c487/

Click the plus symbol to add a controller
then just click thorough it, create another controller and click configure.
Hope this helps