Discussing Tag Standardisation

Ok, you’re right. Carry on.

1 Like

Wikipedia’s categories would be useful, but sadly I doubt such a system is available for discourse.

Personally I don’t think it’s that much harder to read.

The problem with not having ‘namespaces’/‘groupings’ is that without them the grouping/hierarchy is implicit rather than explicit.

But the real questions are “how useful is it?” and “what are the chances of name clashes without it?”.

I don’t think those are the same thing.
Genres aren’t that well defined.

There’s no disputing that mit is a licence or that puzzle is a genre, but you could easily argue that text-adventure isn’t a subgenre of adventure or that it is a subgenre of adventure - genres are slightly subjective.


But admitedly those don’t all have their own thread (which isn’t to say they won’t eventually get one, they might get one someday).

However, just because there aren’t hundreds yet, that doesn’t mean that one day we won’t be in a position where there are hundreds.

Look at the Arduboy, in eried’s repo (which doesn’t cover every game available) there are over 200 games.
That means there are definitely over 200 game threads to filter through on the forums.
In a few years the Pokitto forums could be in the same situation.

I don’t consider it a burden, I actually like that sort of job.
As soon as we’ve settled on something I’d happily go through and handle all the tagging on my own.


I once went through the entirety of eried’s repo,
made a list of all the entries that were missing authors,
tracked down who the authors were and then added them to the repo, one commit at a time
and made sure to do a joint commit for the cases where I could find a Github account for the person.

(Admittedly I sometimes I put off that sort of maintenance because of the disruption it can cause to other users. For a long time now I’ve been wanting to go through all the unsolved issues in troubleshooting and ask if they’ve been solved, but I’ve been worried about the disruption it might cause.)

It’s not up to just me or you, we need more than just two opinions before we set anything in stone.

(And even if it was a moderator decision, we’d still need more than just me.)

I (and/or someone else) could set up a “How to publish your game” thread/wiki later on.

At the moment it would just have “prefix with [Game], [Demo] or [WIP]” and “put it in the games category”, but later it would be edited with “here are how the tags work” when we’ve settled on how tags should work

Okay, would be nice to vote in some way now… but how? A single poll won’t be enough. Should we vote on how to vote? :smile: If you ask me, I’d be okay with some authority (you, Jonne, …) deciding this undemocratically – once we feel we have discussed it enough – and then just let the system evolve.

1 Like

I think it would if we narrowed things down to several alternatives first.

I think the easiest way to do things would be to:

  • propose all the ideas/alternatives
  • rule out some of the ideas
  • settle a handful of alternative systems
  • decide which system stays, either by vote or by decision from a single person

I’d be fine with this too.
If we went down this route I’d probably say leave it to Jonne.
I don’t think I have the authority to make decisions like that.

Hopefully some other people will take an interest in this thread soon so we can get some more opinions.
Otherwise I might just have to start summoning people to give their ideas.

I’d especially like to see some opinions from people who aren’t usually involved in arguments and decision making.
I feel that we often end up with the same pool of regulars leading the discussion when handling the big decisions.
(E.g. me, you, Jonne, FManga, sometimes Hanski.)

Not to say having that group of particularly active people leading things is a bad thing,
it’s good to have a group of ‘leaders’/‘figureheads’,
but at the same time I don’t want people to feel like “I’m not important enough to comment on this”.

Decisions like this this affect everyone so it’s good to hear a number of opinions,
even if those opinions are just “I agree with what so-and-so already said”,
otherwise decision making happens in a bubble/ivory tower.

1 Like

Yes, let’s see what others have to say!

More tag suggestions: port, gamebuino, (meta?), arduboy, micropython (or just python? upython? py?).

@Pharap : “release” tag was intended to mean that there is a binary available

There are several game projects that never released anything.

If you think that is a misnomer, please suggest an alternative

What “release” invokes in me: version 1.0 (or possibly other presentable version) of the game, not necessarily in binary format.

Just a related sidenote on the Wiki category system: pdf presentation showing how complex/complicated of a beast Wikimedia Commons category system is, also mentions tag systems.

gameboy, gamebuino,gamebuino-meta and arduboy are no-brainers,
but the mention port ends up back at the licence issue,
i.e. arduboy-port vs port:arduboy vs just arduboy

Do we need to tag the language?
We’d end up having to put c++ on 90% of everything, so it might look a little redundant.
(And we’d also probably need to increase the tag limit again.)

I can imagine cases where people might want to search for some of the supplementary languages if they’re looking for examples to learn from, but I’m not sure how common that would be.

It might be worth holding off on this one until we have more languages in use.

I think I’d vote micropython because the implementation is officially ‘MicroPython’,
but then the language itself is actually just ‘Python’ and ‘MicroPython’ is the implementation.

Isn’t that still the opposite of ‘work-in-progress’ (wip) though?

Or would that cover games that are still a work-in-progress, but have prerelease binaries available?

Perhaps we need wip, release and prerelease?
Or maybe wip, alpha/beta and release?

I think we should encourage people to make binaries available, be that on the thread itself or on a GitHub releases area.

That’s an argument against how it’s turned out for Wikipedia et al rather than an argument against hierarchichal category systems as a whole.

I was thinking along these lines also

1 Like

Is it worth having separate alpha and beta tags, or should we just have beta tags or just prerelease tags?

I think prerelease might be better because I find most people who make games as a hobby don’t bother with the alpha/beta distinction because most games just have an open beta as soon as it makes sense to do so.

Hobbyists don’t usually have to worry about the kinds of things that motivate companies to have in-house alpha testing.
(Although when we made Dark&Under for the Arduboy we had a single alpha tester rather than an open beta. We didn’t call it an ‘alpha’ though.)

The point was to have something for my script to recognize as a marker that a binary has been released. It’s not for users, its for my scripts.

If I have to make every script look for alfa, beta, gamma etc. its going to make them a whole lot more complicated and slower

In that case probably wip, prerelease and release would be best.
wip to indicate "this is still just an idea, there’s no .bin", prerelease to indicate “this isn’t finished, but there are some functional .bins available” (i.e. the pre-v1.0.0 versions in semver) and release to indicate “this game is officially released now” (i.e. v1.0.0 onwards).

Don’t forget that some people might choose to just link to a GitHub releases page instead of editing the thread every time they make a new release, so the scripts will have to be able to figure that out somehow.

1 Like

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?