Discussing Tag Standardisation

Well, lots of people put their game in whatever category / uncategorized. I’ve been cleaning behind the scenes

Looks good, with these suggestions:

closed-source to me implies the code is unavailable – could we have one more tag for a game with source available but not open-source licensed? Like proprietary or source-available?

On licenses, I’d just drop the license- prefix, because of readability and consistency (we don’t have genre-puzzle, just puzzle, which is how I think tags should generally be).

Also the license tag doesn’t have to be mutually exclusive – you can have multilicensing or separate licensing of code and content.

Here my feeling is just go with singleplayer and multiplayer. Specific number of players is too much information to put into tags in my opinion. Maybe these two plus something indicating a “symmetric multiplayer with AI”, but that’s to be considered.

As I see it a tool is something that helps you develop games for Pokitto and runs on PC, is that right?

In which case I’d suggest adding a (non-game) program tag – something that runs on Pokitto, but isn’t a game (like my text editor).

So you mean like “How to post/publish your game”?
If so, shouldn’t that be a separate topic?
That sounds more like a ‘how to’ guide than a decision-making discussion.

Already ninja-edited source-available just before you hit the submit button. :P

I think proprietary has too many negative connotations, and closed-source is easier to understand as being the opposite of open-source

What are the odds of name clashes?

I’m not against having a system like genre:puzzle or something if it’s found to be useful.

I’m not sure it is. I think if people are hosting a ‘Pokitto party’ or something and they’re looking for something they can play with lots of people then they’ll get annoyed if they have to dig through all the 2-player games when they’re looking for 4-player games.
The specific number is often included on the back of game boxes for similar reasons.

That’s usually refered to as vs-cpu or something.

(I’ll dig out a few game boxes to have a look at what other games do.)

That’s what I was thinking of using tool for.
E.g. an eeprom editor, a file browser.

External tools are a separate issue and probably won’t turn up in the games category.

1 Like

I think with this you’ll soon get into a quite complicated system like Wikipedia’s categories. Tags – as I see them – are a simple navigation helper, and they usually try to be very short, not have hierarchies etc. (e.g. OSGameClones). Anyway, if you want, we can try it, but once we decide to have long tags, it may become hard to read:

type:game state:release source:open license:mit genre:puzzle

There’s a fine line – what about other things, like game subgenres? You can argue the same that in order to offer precise searching, we can have subgenres, but in practice you’ll be putting a lot of effort into maintaining and standardizing them, while it may save some person a few seconds once a month. That’s why I’d go with just very simple tags to help with a rough search and then let the users browse the games – after all there aren’t hundreds of them. But you’re the moderator and tag maintenance will be your burden, so I leave the choice up to you.

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.