I’ve got another draft of the tag standardisation rules, this time with added explanations of the tags and their nuances.
Before I get to that, a few other things.
Firstly, I think the port
tag is redudant when we have tags specifying the original system that a game was ported from, so I have left that out.
Secondly, I’ve been wondering if maybe we should use a lowercase variant of the SPDX licence identifiers for naming licence tags, as this would allow us to leverage their data to generate a list of acceptable licence tags.
Pokitto Tag Standardisation Draft 2
Type (mutually exclusive):
-
game
- For games, programs intended to be fun
-
tool
- For tools, practical programs that serve some kind of purpose
- E.g. file browsers, text editors, sprite editors, sound editors
- For tools, practical programs that serve some kind of purpose
-
demo
- For demos, programs that do something interesting, but aren’t a game or a tool. (Think ‘demoscene’.)
State (mutually exclusive):
-
release
- The program is considered to be in a completed state.
- The thread must include a release binary, else the program is considered to be
wip
.- A link to a GitHub releases page is also acceptable, providing that the page has releases available.
-
prerelease
- The program is not considered to be completed, but is in a minimally usable state.
- The thread must include a prerelease binary, else the program is considered to be
wip
.- A link to a GitHub releases page is also acceptable, providing that the page has releases available.
-
wip
- The program is still in the development stages. It has been announced but is not yet usable.
Source (mutually exclusive):
-
open-source
- The program’s source code is publicly available and licensed under an open-source licence.
-
closed-source
- The program’s source code is not public.
-
source-available
- The program’s source code is publicly available but is not licensed under an open-source licence.
Number of players:
-
N-player
- Where ‘N’ is the number of supported players.
- Used when a game supports a specific number of players
- E.g. “Minesweeper” -
1-player
- E.g. “Minesweeper” -
N-to-M-players
- Where ‘N’ is the minimum number of players and ‘M’ is the maximum number of players
- Used when a game supports a variable number of players in the range of ‘N’ to ‘M’
- E.g. “Poker” -
2-to-8-players
- E.g. “Poker” -
N-or-M-players
- Where ‘N’ is the minimum number of players and ‘M’ is the maximum number of players.
- Used when a game supports two different play modes using different numbers of players
- E.g. “Noughts And Crosses” -
1-or-2-players
- E.g. “Noughts And Crosses” -
Licence (mutually exclusive):
Essentially the rule is:
- Start with the name of the licence all in lowercase
- If there’s more than one version, specify the version
- If the minor version number is 0, it is omitted
- If the licence is a variant, the variant name must be indicated
Examples:
mit
mit-no-attribution
apache-2
bsd-3-clause
gpl-2
gpl-3
lgpl-2-1
lgpl-3
json
-
zlib
etc
Original system (mutually exclusive, ports only):
-
arduboy
- Used for games that originated on the Arduboy
-
gameboy
- Used for games that originated on the Nintendo Gameboy
-
gamebuino
- Used for games that originated on the Gamebuino
-
gamebuino-meta
- Used for games that originated on the Gamebuino META
Genres:
puzzle
action
arcade
adventure
strategy
platformer
-
visual-novel
etc
Genres must reflect the gameplay or the aesthetic of the game.
Whilst people may use genres that aren’t listed here, genres should still be terms that are in semi-regular use.
Ultimately if the maintainers of the tag system decide that a tag does not qualify as a genre then they are free to remove said tag at their own discretion.
For example, steampunk
would be permitted as a genre because it affects the game’s aesthetic qualities and is a term that is in somewhat common usage,
but has-dragons
is not a valid genre because it is not widely considered to be a genre and is merely a statement about the game that does not necessarily reflect the game’s aesthetics.