New schema or properties for recognising Web Game needs?

[tcmg]

Web games are games that are completely playable on the open web (i.e. local client-side HTML5 games or streamable games that execute on a server). There is no explicit schema for these type of game, although we do have the existing VideoGame schema type.

I think there are some additional fields that would be valuable though for recognising a web game, such as:

gameIcon - Image type. Ideally a square icon image to represent a game in a traditional square grid interface.
gameBanner - Image type. An image for highlighting a game in a landscape banner.
aboutURL - URL type.
privacyPolicyURL - URL type.
multiplayer - Freeform text. Ideally recognising any of “LOCAL”, “ONLINE”, “COOPERATIVE”, “COMPETITIVE”.
executes - Freeform text. Ideally recognising either of “CLIENTSIDE” or “SERVERSIDE”.

I propose extending the VideoGame type to include these and also recognising web games as games that implement the VideoGame type and also use "web" as the value for their "platform" type.

[danbri]

Thanks for the proposal. Can you bounce it around in webby / gamey circles?

What is "aboutURL"? the main URL for the game? We have a lot of similar properties already, including "/url", "/about" and (on MediaObject) "/contentUrl".

There are some nearby discussions here on privacy and other policy links; whatever we do for games ought to fit into a larger story for other kinds of web content.

"executes" is awkwardly named; we have to remember that schema.org is a flat namespace so the words we choose are from a common pool, i.e. property names aren't implicitly contextualized by the types they're applicable to. So "gameExecutionMode" or similar might work. I don't exactly understand what is intended though --- are you thinking of dumb client systems that just serve to display pixels/audio? Would a game implemented as an old-style /cgi-bin perl script be "serverside", if the clientside was scriptless HTML forms?

[danbri]

Any news on this, @tcmg ?

[tcmg]

@danbri Yes.

I agree with your point for "about" vs "aboutURL". We can avoid adding "aboutURL" and leverage "about" instead.

I agree with your point about "gameExecutionMode" as a better name. The idea here is to differentiate between HTML5 client-side games and server-side executed "streamed games" (i.e. the game executes on the server and video/audio are streamed to the user).

I also realised that multiplayer is not necessary as "playMode" mostly covers this.

Also, do you think "gameIcon" should just be "icon" perhaps?

[tcmg]

Also, to clarify some things about this proposal for additional context. I'm imagining that there's an opportunity for a set of requirements that web games could implement that would leverage several of the properties of the VideoGame schema. But I think these additional properties I'm proposing in this issue are necessary to complete that concept.

So for full transparency, I'm picturing the following as the overall minimum requirements to fulfil a "Web Game definition" subset of the VideoGame Schema:

• name
• description
• url
• genre (e.g. action, arcade, rpg)
• accessibilityControl (touch, keyboard)
• operatingSystem (should always be "web")
• icon (icon/logo asset for the game, part of above proposal)
• gameBanner (part of above proposal)
• about (URL for information about the game but not necessarily the URL the game is played)
• privacyPolicyURL (part of above proposal)
• gameExecutionMode (part of above proposal)
• image (list of screenshots)
• author (the game developer)
• publisher (the game publisher / portal)

In bold I've highlighted the properties that are being proposed in this issue.

There are some teams at Google that I'm talking to who could benefit from this I believe.

[AshleyScirra]

Just to offer some thoughts from the point of view of Construct (a web game editor):

• most platforms require a range of icon sizes, and so many games will have a range of options say from 32x32 to 512x512. If there is a single field for an icon, which do we use? The largest? Other platforms, including other web features like the web app manifest, provide an array of icons with different sizes, and it's up to the platform/browser to pick an appropriate one.
• is the icon different to thumbnailUrl?
• a field for "associated website URL" might be useful, if not the same thing as "url" or "about"
• in Construct we could also automatically fill out extra fields for version and author email
• in Construct we could not automatically fill out the fields for genre or privacy policy URL, unless we added extra fields in the editor
• publishers may want to link to a store or related app, such as a steam game or mobile app store reference. For example the web game might be a demo or promotion for a paid app on another platform. I'm not sure how this might be represented, though.

[github-actions]

This issue is being tagged as Stale due to inactivity.

[erikdubbelboer]

@tcmg should operatingSystem = "web" really be the way to detect that the data is about a web game and not a normal desktop game? Feels a bit like abusing the operatingSystem field. Maybe gamePlatform makes more sense for this? Either way we would need to have this standardized as this is I think the most important addition to the schema, to make it possible to detect that it's about a web game.

[tcmg]

@erikdubbelboer That's a good point. I think 'gamePlatform' does make the most sense.

@danbri thoughts?

[danbri]

+1

…

On Wed, 21 Oct 2020 at 16:37, Tom Greenaway ***@***.***> wrote: @erikdubbelboer <https://github.com/erikdubbelboer> That's a good point. I think 'gamePlatform' does make the most sense. @danbri <https://github.com/danbri> thoughts? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2565 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABJSGIRKLARGYTLEUCAYNDSL355PANCNFSM4M7BU5PQ> .