V4 Components: Game Library Service

This is a follow-on to the V4 Architecture article.

The Game Library Service provides access to a collection of game modules.

Game modules have an assortment of metadata. Some metadata pertains to the game, such as title, publisher, year of publication, topic. Some metadata pertains to the module, such as the module maintainer and module version.

The Game Library Service shall provide endpoints for

  • getting game module metadata by module id
  • submitting game module metadata
  • querying game modules by metadata fields
  • querying game modules by full text searches over all metadata
  • getting a URL for a game module
  • uploading a game module and receiving back a URL for it
3 Likes

Dare I say some of the metadata might be metadata? Number of downloads, number of games in progress, number of completed games?

I see that as being part of the Game Management Service instead.

2 Likes

Number of downloads for the module ought to be part of the GLS, as itā€™s not about game instances.

Iā€™d like to get moving on this component.

What metadata do we need?

What the Python and Rust package repositories, PyPi and Crates.io, respectively, do here may prove instructive. Both have manifests for setting package metadata.

Hereā€™s the documentation for the JSON PyPi returns:

https://warehouse.pypa.io/api-reference/json.html#

Hereā€™s the manifest documentation for Cargo, which is used by Crates.io:

https://doc.rust-lang.org/cargo/reference/manifest.html

How about separation of game scenarios from the game module? Providing the ability to download scenarios, including from within a module.

Start w/ existing Metadata defined under ā€œModulesā€ section of website. #players; publisher; game series; era; topic; yearpublished; scale

Add:
Module creator/maintainer(s)
Game Designer(s)

I would consider scrubbing the existing topics list and making a smaller more standardized list (list is a lot bigger than below 4, but maybe 20-35% of existing list).
*worker placement
*wargame
*Economic
*Civilization

I would also consider allowing up to 3-5 standard topic tags and tiered sub-tags under each. This would be particularly useful for wargames . Example:
Tier-1: Wargame
Tier-2: Area Movement
Tier-2: WW2
Tier-3: North Africa

What about going the other direction and using tags for topics, instead of having a predefined list at all?

Multiple publishers.
Publisher link(s).
BoardGameGeek link
Other link(s) - e.g. game support, fans, where to find players.

1 Like

Some data belongs to the game, some to the module. Itā€™s also not 1:1. There are some modules covering several games, as when there two or more games which can be linked.

Yes, there is a challenge there. Even BGG has not satisfactorily addressed it - thinking of how games are recorded, especially when for games with multiple expansions and editions.

IMHO there are pros and cons to both a small standard concise list and user defined tags. Looking at the current module subcategories illustrates that. Lots of proliferation of tags that are at a lower level (e.g., specific wars, that are subcategories of wargame (and some are incredibly niche)), while more fundamental categorizations are missing.

I (for instance) am a huge fan of ā€œarea movement gamesā€ (contrasted with hex based) (like BreakOut Normandy, Montyā€™s Gamble, etc.), but that categorization doesnā€™t exist.

If the tags are completely freeform, then people may omit standard categorizations (like wargame/WW2) that would help players find modules of potential interest.

Also proliferation of semantically equivalent tags:
World War 2
The Great Patriotic War
WW2
WW-2
Hitlerā€™s War
etc.

Yes, but we could seed the tags with an initial curated set that covers the important categories.

1 Like

I think BGG handles this well,

They have separate lists of ā€˜Categoriesā€™, ā€˜Mechanicsā€™ and ā€˜Familiesā€™, and you can apply multiple tags from each list to a game.

Our current ā€˜Topicsā€™ seem to be a very limited mixture of ā€˜Categoriesā€™ and ā€˜Mechanicsā€™.

I donā€™t think their ā€˜Familiesā€™ are particularly useful, but I think their ā€˜Categoriesā€™ and ā€˜Mechanicsā€™ lists are pretty good.

The problem with user defined tags is as Korval mentioned, people donā€™t follow the rules, donā€™t check to see of one already exists etc. and your list of tags becomes polluted and less and less useful over time.

Iā€™d rather start with a decent, but fixed list and users can request for new ones to be added.

1 Like

I agree with Brent and have generally tried to follow BGG, but the format of our wiki pre-defined module tables is limited and can only do so much so there is a pick and choose poison element in that regard.

As such I try to standardize the module page tags.

The example from Korval is an excellent example of where I try to make sure the ā€œEraā€ tag is always made to WWII as opposed to WW2, WW-2 etc for those games so at least all those types of games remain grouped together at that level. Everything is linked and nothing is broken.

Internally to a created module though - how would you set rules for a module designer to follow as to how to tag / categorize something they create. I donā€™t see that feasible in an open source software environment.

Its just too arbitrary

We canā€™t control that, and hopefully peer pressure from players will encourage the designer to update the tags if they donā€™t represent the actual game.

What we can do is provide a consistent, meaningful and (mostly) complete set of tags from which a designer can choose.

What I see BGG having for a game is:

  • primary name
  • alternate names
  • year released
  • minimum players
  • maximum players
  • mfg suggested ages
  • minimum playing time
  • maximum playing time
  • designers
  • solo designer
  • artists
  • publishers
  • developer
  • graphic designer
  • sculptor
  • editor
  • writer
  • insert designer
  • type
  • categories
  • mechanisms
  • expansion
  • expands
  • integrates with
  • contains
  • contained in
  • reimplements
  • family
  • description
  • video game adaptation

BGG is maximalist hereā€”theyā€™re trying to be something like a game encyclopedia. Quite a few of these I donā€™t see a reason for us to include.

What we have in the wiki now that is game metadata is:

  • title
  • publisher
  • year released
  • number of players
  • length
  • era
  • topic
  • scale

Itā€™s hard to make a principled distinction between BGGā€™s type, category, and family; they all strike me as tags.

Do we really want to (continue to) be in the business of curating a set of tags? Maybe Iā€™m overestimating how much work it is. StackOverflow seems to have done fairly well with evolving a set of tags, though they have an active community curating them and a mechanism for suggesting tags when you submit a question.

1 Like

I agree that we donā€™t need the extensive list that BGG has.

However from my perspective, I think there would be value in having ā€œMechanismsā€ (e.g., previously mentioned Area Movement) and ā€œDesigner.ā€ There are some designers I would love to search on (personal favorites).

I think there is value in both unrestricted module designer specified tags/keywords and a curated list (e.g., Mechanisms).

I will add that of the current list of data, I find most of them (e.g., length, publisher) far less helpful than I would find Mechanism & Game Designer.

Oh and a critical addition module developer/maintainer.