Discussing Tag Standardisation

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
  • 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
  • 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
  • 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

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


  • mit
  • mit-no-attribution
  • apache-2
  • bsd-3-clause
  • gpl-2
  • gpl-3
  • lgpl-2-1
  • lgpl-3
  • json
  • zlib

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


  • puzzle
  • action
  • arcade
  • adventure
  • strategy
  • platformer
  • visual-novel

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.

1 Like

I mentioned this somewhere above, probably got lost – mutually exclusive shouldn’t apply here, there can be multiple licenses.

Same with original systems, the game may have originally been released on multiple platforms.

Theoretically also Type… only State and probably Source seems to be truly mutually exclusive.

It is in terms of provided information, but could still be useful for searching if you want to (easily, single tag click) find/count all ports, regardless of platform. Similar to source/license. The question is whether it’s gonna be a frequent search.

otherwise :+1:

I think that the ‘original system’ tag should only be used for special types of games: the gameboy games that have been generated by @FManga’s gameboy emulator, the arduboy games that are ported using @Pharap’s arduboy library, etc… In this case, the tag is mutually exclusive.
This tag should not be used for remakes, otherwise the tag system will become way too complicated… Suppose I make a new tetris, what are all of the original systems for that game? :slight_smile: https://en.wikipedia.org/wiki/List_of_Tetris_variants

1 Like

I don’t mean remakes. A source code for a game can be written to build for multiple platforms – for example someone writes a game that compiles both for GameBoy and for NES – now you take that code and make it compile for Pokitto as well – now there are two originally targeted systems: GameBoy and NES.

True, but it would be a bit of a headache if any actually are dual-licensed.
This could be allowed, but I sincerely doubt it would happen for more than about 1% of games.

One type will be predominant.

If a game includes a tool (e.g. a save manager),
its primary function is still ‘a game’ so it doesn’t need the tool tag.
Likewise, a tool could include a game as an easter egg,
but its primary function is still ‘a tool’.

I’m not convinced that many people are going to want to do that.

It’s not the same as searching for open source games,
when searching for open source things, people are usually happy with the majority of open source licences,
but when someone looks for a port they’re usually after something from a specific console.

Also, the open-source tag exists to complete the triad with closed-source and source-available,
which might not have licences.

This was exactly my intent, which is why I’ve only included the four tags.
Gamebuino META is included because I’m expecting its library will get ported at some point.

(I was going to include the one for that other small bluish/white console that @FManga did,
but I can’t remember what it was called. It looked a bit like the Pokemon Mini.)

That’s not the only problem.

If we allowed it to be used for remakes of games from any system we’d simply end up with far too many tags because people could remake games from any system.

Then they can pick one.

The obvious choice would be the NES because it’s lower spec.
If they wanted they could dive into the history of the code and find out which device it was written for first, or which console it was originally intended to run on (which would be more likely to be the NES because of its lower spec).

Though that particular scenario is unlikely, both the NES and the GBA have a higher resolution than the Pokitto, so any port wouldn’t be an exact port, they’d have to cut some of the screen off.

If you allow too many to be ‘multiple’ then the tag limit is going to have to be increased again.
Keeping tags mutually exclusive keeps the tag limit down and makes searching easier.

1 Like

I don’t see why more tags would be a problem though? More tags mean more information, you can ignore the ones you’re not interested in. You can still keep the limit reasonable – if you’d go over the limit, simply do what you suggest and omit the less important ones, choose the lower spec platform or something… but if there’s room for more to be filled with useful info, I’d allow adding it – a lot of sites I know (OGA, OpenHub, OpenClipArt, …) practice and encourage more tags if possible.

Allowing more tags sometimes encourages people to try to apply as many tags as they can think of,
which ends up generating noise rather than useful information.

Especially if we don’t have an enforced order.
Having to sift through a sea of noise to spot the important tags is never a good thing.

If you keep a reasonable limit on the number of tags then people will think more carefully about which tags they use, and thus the tags are more likely to be useful.

That’s the theory at least. We won’t really know anything until the system has been running for a while.

Ultimately it’s easier to add than to remove,
so I think it’s better to start restricted and then relax restrictions if it makes sense to do so,
than to have loose restrictions and then have to reign things in.

1 Like

Noise is something that’s difficult to separate from the useful information, I wouldn’t call it that. I also don’t think people will be aiming to fill the empty space with tags, it’s an extra work and people are lazy :slight_smile: And about the order – I don’t see a problem here either – it literally doesn’t affect searching or categorization or anything. The only thing it affects is the visual order when reading the tags, which isn’t something you do often – tags are for searching and categorization – once the entry has been found, you won’t be reading the tag list. Or am I missing something here?

In my experience people enjoy adding tags because they think:
“What tags can I add to make it more likely that people will click on my game?”.

Like how people used to abuse HTML keyword metadata to try to get themselves bumped up the search results list.

An early attempt at what they now call “Search engine optimisation”,
or “search scumming” as I’ve once heard it called.

Tags aren’t just metadata for searching, the tags are something people will read from time to time.
People will look at tags to find out which tags have been added to a topic and to look for invalid tags.

Searching for specific tags is only a broad-phase search.
Once that has narrowed down the list of candidates,
people will then look at the tag lists to look for interesting tags.

How are people supposed to discover tags if they don’t read the tag lists?

We can’t maintain a complete list of all possible genres,
or the non-standard tags that people might be creating.

To recap, the current points of contention are:

  • Should the ‘licence’ tag be mutually exclusive?
  • Should the ‘original system’ tag be mutually exclusive?
  • Should the ‘type’ tag be mutually exclusive?
    • I.e. can something really be both a tool and a game?
  • Do we need a port tag?
  • How should we handle multiplayer tags?
    • Should we have a family of N-player tags?
    • Should we just have singleplayer and multiplayer?
  • Should we have a hierachied tag system?
    • e.g. type:game and state:release rather than just game and release

If anybody who hasn’t chipped in yet has some opinions that they’d like to share, it would be greatly appreciated.

Currently I’m willing to allow licences to be non-mutually-exclusive,
but I don’t want to encourage dual licensing because I’d class it as bad practice.

Generally speaking I’m agre on keeping the tag count low. The final goal is to group easily for the web interface.

  • Mutual license.
  • Exclusive ‘original system’, at the end you start from one specific version the port.
  • Mutual type
  • No ‘port’ tag, if you compile the ‘original system’ that should be enough
  • Multiplayer only

Hope this can help to head towards a decision.

1 Like

When you say “mutual”, do you mean “mutually exclusive”?

So singleplayer and multiplayer tags only?

In case I’ve been throwing a term around that isn’t commonly understood:
Mutual exclusion essentially means “only one of these”.
For example, the values of a boolean (true or false) are mutually exclusive because something can’t simultaneously be both true and false.

It’s a term that comes up quite a lot in programming.



also in logic

1 Like