Comments/Ratings for a Single Item

I would also personally use 'Geometry' rather than 'Board'. It's a bit more general.

I think Board is a bit more general, because it can also be used for board size, board dimensions, or other board differences like having terrain.

And a game could be both 3-D and Rectangular, or both 3-D and Hexagonal ...

There is no requirement that a page should get only one child tag with a particular parent. A page could be tagged both Board:3D and Board:Hexagonal, for example. I have been tagging some of my own games with multiple Rules: children tags, which is the same principle.

I have also sped up tagging of similar games by including a copyable string of all the tags a user has added to a page. I have been able to copy and modify strings from one game to quickly tag others.

I would prefer to keep the categories, if only to have a short list of important information; when posting a new game, checking a few of those boxes is (or eventually will be) easier than perusing all the existing tags. The main question to answer, if we agree that this is worth keeping, is how to reconcile the overlap. I think a mechanism to include the categories as tags would serve that purpose fairly well, but would require an efficient way to index the pages of each category (dynamically, since pages' categories can change).

Indeed, one of the first uses of tags to my mind was to subcategorize the "Shape" category. Hence #Shape:Board and #Shape:Cells.

I think we should keep 2D; while no one will peruse it directly, they might be searching for something and want to exclude non-2D variants. (This does suggest though that some very large tags might need rethinking on how to list their pages.) Also, maybe dimensions should be a numeric parameter instead. (Note that "4D" is actually supposed to mean "4 or more dimensions".)

"Usual Equipment" is usual for people who want to sit down to a regular chess set and play a variant. I would suggest, if tags rather than categories, that #UsualEquipment be its own tag, and each of the deviation types can be a completely separate tag, applicable to both usual-equipment and different-equipment games. "Modest" is probably useful especially for people wanting not-very-different games; see e.g. the comment thread on this SE post.

On Crossover, I think there will be some base games (e.g. Checkers) that deserve child tags, but if a base game has only one (maybe two) chess crossovers, then it should just be tagged with the parent Crossover. (I wouldn't oppose, however, individual tags even for one-game bases. It makes the tag itself more informative, if less useful for searching. If we restructure tags in a way that makes recursive searching possible, then this would work.)

Single player and multiplayer could be replaced by the number of players numerical field.

And yes, I think numerical fields should be kept separate rather than incorporated into tags. That gives us more flexible searching ("at least 90 cells but at most 130"), and I can't imaging a parametrized tag ("#CellCount=x") looking good.

I don't think individual pieces should be tags. I'd rather that be an explicit database table. But I do think "usual equipment" and "FIDE+compounds" and similar classes of piece sets could be useful as tags.

I agree with "Board" because of terrain. Maybe something even more generic like "Playing Field", except that I prefer the brevity of "Board".

I agree with "Board" because of terrain. Maybe something even more generic like "Playing Field", except that I prefer the brevity of "Board".

I also prefer the brevity of Board. While the word might most literally refer to a contained 2D playing area, Chess variants are classed as board games, and the word is normally used for the playing area in any Chess variant, even if it doesn't follow the planar geometry of a literal board.

And yes, I think numerical fields should be kept separate rather than incorporated into tags. That gives us more flexible searching ("at least 90 cells but at most 130"), and I can't imaging a parametrized tag ("#CellCount=x") looking good.

From a search perspective, that makes sense. But from a browsing perspective, I think it makes sense to include tags for sizes we have many variants in.

I don't think individual pieces should be tags. I'd rather that be an explicit database table. But I do think "usual equipment" and "FIDE+compounds" and similar classes of piece sets could be useful as tags.

Yes, tags can't do some things that the database table is intended for, such as keep track of the names used for the same pieces in different games. Instead of using tags for individual pieces, it may make sense to use tags for common sets of pieces with tags like Pieces:Chess, Pieces:Shogi, Pieces:Xiangqi, etc. My issue with Chess+Compounds or FIDE+Compounds is that there are different sets of compounds. Fusion Chess and several related games also include royal compounds. To distinguish these, we might use Pieces:Chess+RBN-Compounds for games with the pieces of Capablanca's Chess and Pieces:Chess+KRBN-Compounds for games with the pieces of Fusion Chess.

From a search perspective, that [numerical fields for board size etc.] makes sense. But from a browsing perspective, I think it makes sense to include tags for sizes we have many variants in.

We do already support that through the old sidebar and the new menu's RelatedPages->GamesOnSameBoard. Maybe we should expand the area where tags now live to include that, links to the Categories, links to the Related Pages (from GroupID), etc. Or, add tags into the Related Pages menu.

(We should also settle on and publicize some conventions on how to enter fields for infinite boards, boards without a well-defined number of files/ranks (different geometries, e.g.), etc. Similarly for games with variable number of players. There are also some oddities that will push whatever design we choose; I recall but can't find at the moment a game where some pieces treat the board as 2D and others as 4D?)

My issue with Chess+Compounds or FIDE+Compounds is that there are different sets of compounds. Fusion Chess and several related games also include royal compounds. To distinguish these, we might use Pieces:Chess+RBN-Compounds for games with the pieces of Capablanca's Chess and Pieces:Chess+KRBN-Compounds for games with the pieces of Fusion Chess.

I would be OK with that, but I think RBN-compounds-only are the majority and might warrant the shorter if less-clear name. And maybe Man-R-B-N-compounds are also common enough to warrant their own tag (and again we get into a discussion on whether changes like royalty are actually a piece property or a rule variation; should KRBN-compounds be separate from Man-RBN-compounds?).

For pieces, I like the other approach we are taking - the new tables to allow an index of pieces and cross-reference them with the games they are in. This is powerful and I think it is most likely what people will want. There are questions posted form time-to-time asking about previous uses of specific pieces.

OTOH, the tags for groupings of pieces feels like a kludge that offers very little value if the other approach is available... Which reminds me - is the table of piece types and their IDs/internal names finalized? If it is, I can start populating the piece<->game mappings. I have the data to populate this for about 135 games in a fairly automatic way.

should KRBN-compounds be separate from Man-RBN-compounds?

In Fusion Chess, compounds with the King are royal. So, some distinction might be appropriate. You might be thinking of a game like Sac Chess for the latter, but that game also has Amazons, which Fusion Chess doesn't have. Here are some options:

• Use Pieces:Chess+Compounds more loosely
• Same as above but include child tags for variations.
• Make many fine distinctions in children of Pieces.
• Just use names of games with certain piece sets, such as Pieces:Carrera's Chess, Pieces:Fusion Chess, Pieces:Sac Chess, etc.
• A hybrid approach that uses game names for larger sets to avoid making long tags like long German words.

OTOH, the tags for groupings of pieces feels like a kludge that offers very little value if the other approach is available...

This depends on what kind of search utility we can provide (elegantly), and how much convenience we think this class of games deserves. The current definition of the tag would need a search like "includes at least one of marshall/archbishop/amazon and no pieces outside of FIDE+those".

I think in part this class deserves a quickly found list because it's so common to want to include the compounds; it may help new developers understand the prior art in this area.

I think in part this class deserves a quickly found list because it's so common to want to include the compounds; it may help new developers understand the prior art in this area.

Ok, yes, this is a good point

Which reminds me - is the table of piece types and their IDs/internal names finalized? If it is, I can start populating the piece<->game mappings. I have the data to populate this for about 135 games in a fairly automatic way.

Okay, sure. I have been sidetracked by other things for a while. The database has a new password, which you can find by logging in and looking it up in the file that contains it.

The database has a new password, which you can find by logging in and looking it up in the file that contains it.

I'm not sure what you mean.  Do you mean connect with SSH and I'll find it in clear text in a mariadb config file?

I'm not sure what you mean. Do you mean connect with SSH and I'll find it in clear text in a mariadb config file?

No, that's not what I mean. I mean a php script that is outside of public_html that gets included in every php script that accesses the database.

I have added one more restriction on tags. They must be written entirely in ASCII characters. For the sake of posting comments to tag pages, tags form the basis for the ItemIDs of tag pages. To avoid the illegal mix of collations errors from the database, they, like ItemIDs, are now limited to ASCII.

The tags "12X12Board" and "Dozenal" are duplicate.

Thanks Thomas, you're right. Neither of these tags should exist anyway, because item entries already store the number of rows and columns, and that's a better way to search for items.

We started to work on adding pieces to the database a couple of years ago, and I'd like to pick that back up. Eventually that would replace the piece tags here (at least, I think it would be better), but until we get scripts up for crowdsourcing the piece-game relation table, I think users adding tags like these will work, and we can migrate the information over later.

I find the square board tags quite handy, they allow a quick navigation to other games on the same board. Going to the game info page and selecting the right category (best working is the number of cells in the case of square boards) takes longer.

And I really love the piece tags.

@Jörg You can also get to same-board listings from the header menu, Related->Games on Same Board.

Hi Ben

I cannot seem to find 'Games on same Board' as a (e.g. 'Related') option for unsubmitted/unofficial presets. For example, (10x10) game courier preset zcherryz7c

https://www.chessvariants.com/play/pbm/play.php?game=zcherryz7c&settings=zcherryz7c

Maybe I could find other 10x10 games if I used a tag for either that preset or 10x10 boards? (I know nothing about tags, really, though). The rules for tags may indicate that unpublished presets are not allowed to have tags (nor are Game Settings files?), though.

Tags that worked well with unsubmitted presets (or on Game Settings files) would be good, as you wouldn't have to wait for a preset to be submitted (and eventually published, if deemed acceptable) in order to try to track it down, without slowly searching through the 1000+ games on the Game Courier list of games.

@Kevin, indeed GC presets aren't "Items" in the database, and so can't be favorited, commented on, tagged, etc. Perhaps some of that can be changed, but it would be a pretty big change. (I think favorites should be limited to games, but comments on a preset separate from the game make sense to me. I'm not sure about tags: I wouldn't want information duplicated between the game and the preset, but maybe there are sensible preset-specific tags? But then we'd have the same system for two disjoint sets of objects...)

As for searching for presets (without a Game or preset landing page*), maybe the /play/pbm/listgames.php script should take additional filtering options.

*That's another thing: the pairing of preset landing pages (MP... for member-submitted ones) with presets has always seemed redundant to me.

Well, I recall a published preset[s] (landing) page can get commented on and also get CVP Rating[s] ('Excellent', etc.) given to the preset[s] by posters (I would think one purpose of a landing page is to neatly allow comments on the quality of the preset[s] itself, i.e. the graphics, whether it works etc.; also, something like CWDA has so many sub-presets that a single unifying landing page may be best). Ratings are a way to track down published presets/CVs, possibly (currently the CVP 'Average Ratings' link gives only ratings for games with Rules Pages already submitted).

Unfortunately, unpublished presets (or Game Settings files) cannot seem to get CVP ratings (or non-Kibbitz comments, unless during submission process, if any) given to them, I think [too].

I edited my previous comment a lot, for any who missed it.

We have a tag for "Dozenal" and a tag for "12x12Board". Both are addressing exactly the same thing. May an editor clean one of them?

What would be an appropriate tag for hexagonal boards?