Additions to the Schema

[avivace]

@GeekJoystick brought to my attention a couple of additions it could be nice to have in the Game schema:

• description
  • plain text? markdown?
• flag a file as "Game manual"
• different roles for the "developers"
  • maybe switch to "authors" and have "artist", "developer" as possible "roles"?

[dag7dev]

• description: plain text, markdown would all be more elaborate (with other files) and "non-suitable" for a yaml or json

• flag a file as "Game manual": mmh, are there really homebrews that are "game manuals"? And if yes, I think they are a very small niche, I don't think it's worth to specify them

• different roles for the "developers", maybe switch to "authors" and have "artist", "developer" as possible "roles"?
  We already talked about it in Allow multiple authors #78, in my opinion it's better to leave things as they are, otherwise it's too confusing. In the rom it is typically written who did what, and people who's more curious can look it up. At the most, as said in Allow multiple authors #78, we can handle the case of more devs (should be at most two or three), but otherwise it is better to leave it as it is, then it would be verbose and could create confusion in terms of searching a rom

[avivace]

• description: plain text, markdown would all be more elaborate (with other files) and "non-suitable" for a yaml or json

I think you are right on encoding markdown in the JSON manifests.. Especially considering that the same result can be obtained by adding a markdown file in the folder. Maybe an addional possible file "tag" to mark a markdown file as "Game Description" (so it gets rendered on the game page"?

* flag a file as "Game manual": mmh, are there really homebrews that are "game manuals"? And if yes, I think they are a very small niche, I don't think it's worth to specify them

The game "manual" is intended as "Instruction manual", as in a PDF or a text file explaining how to play the game. A lot of homebrew entries have those..

* different roles for the "developers", maybe switch to "authors" and have "artist", "developer" as possible "roles"?
  We already talked about it in [Allow multiple authors #78](https://github.com/gbdev/database/issues/78), in my opinion it's better to leave things as they are, otherwise it's too confusing. In the rom it is typically written who did what, and people who's more curious can look it up. At the most, as said in [Allow multiple authors #78](https://github.com/gbdev/database/issues/78), we can handle the case of more devs (should be at most two or three), but otherwise it is better to leave it as it is, then it would be verbose and could create confusion in terms of searching a rom

I don't see what's wrong in allowing optional addional information in that field.. We would continue to support the simple string / [String] but also allow to add the developer role .. E.g.

developer: ["Author1", "Author2", {name:"Author3", role:"Sound Designer"}]

[dag7dev]

Maybe an addional possible file "tag" to mark a markdown file as "Game Description" (so it gets rendered on the game page"?

What about instead writing / converting every "description" field into Markdown so we could just use one field having the benefit of using Markdown?

The game "manual" is intended as "Instruction manual

Now is clear.
Then, in my opinion, is better to have a standard naming for all the instructions file.
In this way, we don't need to specify them anywhere in the schema, we will just (into frontend part) display the file related to instructions if present.

Scenario: I want to play ducky-duck, but some instructions have been released along with rom file. The instruction's name should be called instructions.txt.

I would go into hh and look for ducky-duck. Since instructions.txt file does exist, after clicking a button, the website will prompt me the content of instructions.txt.

Scenario 2: Instructions hasn't been provided. If I go into hh and look for froggy-frog, that button won't show.

We don't need to keep track of those files. We can just show them if present, if not, we won't.

developer: ["Author1", "Author2", {name:"Author3", role:"Sound Designer"}]

It is a little bit clumsy, and we would need to manage the simple strings. This could lead to ambiguity.

A better improvement could be:
developer: [{name:"Author1", role:"Dev", {name:"Author2", role:"Dev", {name:"Author3", role:"Sound Designer"}]
But this could be really clumsy to update.

We need to keep data atomic, or we will face issues in updating and retrieving data.

I strongly agree we need a way to support multiple authors, but personally, I don't think it's necessary to specify who has made what...

[dag7dev]

@avivace I was thinking: some hb will have a specific language. What do you think about adding a new field called "language"?

By default is english, but, in case a homebrew it's not in english, it will be changed according to the homebrew's language.

[avivace]

@avivace I was thinking: some hb will have a specific language. What do you think about adding a new field called "language"?

By default is english, but, in case a homebrew it's not in english, it will be changed according to the homebrew's language.

I agree, we can add a new field for files called language so it would also allow an entry to have translated ROMs.

[avivace]

Preliminarly done in ea47761 . Files can be marked as "manuals" as well now.