Data Note: The Digital Ludeme Project Database

This document outlines the types of data collected for the Digital Ludeme Project, an ERC-funded research project that aims to improve our understanding of the development of games throughout human history through computational analysis of the available (partial) historical data of games. This document outlines how this data is collected, formatted and stored, and how it can be accessed. It is the aim of the Digital Ludeme Project to provide a data resource of unprecedented depth and scope for the benefit of historical games researchers worldwide. Special attention is paid to the FAIR Guiding Principles for scientific data management and stewardship.


Introduction
The Digital Ludeme Project is a five-year research project involving the analysis and reconstruction of ancient and historical games from incomplete descriptions, artistic depictions, and archaeological evidence using modern computational techniques 1 .The project focuses on games that rewards mental acumen over physical skill.Generally, these broadly fit what are commonly known as board games, card games, and domino games.The goal of the project is to document 1,000 of these games which were important for the historical development of games, across the world, and throughout history.Some outliers exist, e.g.chance-based games such as Gyan Chaupar and the Game of the Goose that are still obviously culturally important.
To achieve this, a digital database of evidence for ancient and traditional games is required, drawing from multiple disciplines and in various formats; this is the first time that such a collection of evidence has been attempted for such a wide range of games and from such a wide range of perspectives and sources.This document describes how we are obtaining this data and storing it in a consistent format both for use within the Digital Ludeme Project and for the benefit of other researchers and practitioners, and how we are adopting the FAIR principles to make this database as reliable, accessible and useful as possible.
This document is an updated version of the "Digital Ludeme Project Database Guide" 2 that reflects changes made to the current version of the database 1.3.12. 1 Most importantly, these include the addition of a "ludemes" table that provides information about which ludemes -i.e. units of game-related information -are available in which games and rulesets in the database.

Purpose
To study traditional games, it is necessary for a rigorous approach to compile and analyse what is known about them.Historically, games research has often relied on works such as Murray's History of Board Games other than Chess 3 , Bell's Board and Table Games from Many Civilizations 4 and Parlett's Oxford History of Board Games 5 .These works are largely compilations of primary research performed by anthropologists, historians, and people interested in games, but which often include assumptions, and, not infrequently, mistranslations and incorrect descriptions of the original sources.Other authors provide reconstructions for games based on their assumptions about how games may be similar to one another.To approach the reconstruction of games empirically, the Digital Ludeme Project uses primary sources to identify exactly what is known about the relevant games, in order to provide accurate reconstructions that is as reflective as possible of the current knowledge about these games.The database resulting from this research not only serves to facilitate game reconstruction, but is the most rigorous and complete representation of games -as well as being the most honest in terms of what we actually know about games and not what is assumed to the true -available to researchers and others with an interest in games, and has the potential to become the most comprehensive traditional games database in the world.In the context of this paper, we refer to this collection of data generated by the Digital Ludeme Project as the "DLP Database".

Conceptual Structure
In order to operationalise this research framework in a database that captures the inherent variations that exist in the ways games are played, and to take into account both functional and cultural definitions of games, the DLP Database conceptualises games in an innovative way, that allows for the identification and corroboration of evidence with specific ways that games are played.As a result, the data comprising the DLP Database can be decomposed into two main types: game-related and evidence-related.These conceptual definitions are broadly defined and will necessarily inform each other, as shown in Figure 1; each game is composed of a number of rulesets, each of which is defined by component ludemes, and there exist separate types of evidence for each of these conceptual groupings.These two main types of data can be further decomposed into the following groups.
Ludemes.A ludeme is a single elemental building block of a game.Multiple ludemes can be combined together to create a description of a specific piece of equipment or rule that a game uses 6 .Because of this each Ruleset, and by extension every game, within the DLP database can be described using these ludemes in a single plain text file called a ludeme description (with the extension ".lud").Each ludeme is stored in the DLP database and is associated with the Rulesets which use it.If a game has any ruleset that uses a particular ludeme, then by extension, that game will also be considered as using that ludeme.

Game-Related
The games-related data refers to individual instances of games, their rulesets, and the ludemes that make them up.Much of this type of data is derived from the evidence-related categoriesalthough not exclusively -and is indirect in nature.
Games.Games can broadly be described as being played by rules which are distinct from other games, but which also are strongly tied to cultural histories and practices.Therefore, a ruleset alone is not sufficient to define a game, though a game must consist of at least one ruleset.A single game can often have multiple distinct rulesets.Cultural information drawn from primary sources helps to determine when a single game should have multiple rulesets or whether these should be separate games.
Each game entry in the database collects the known rulesets for that game in a single access point.The decision between whether two variants of a given game should be defined as different games or as variant rulesets of the same game is guided by the historical and cultural context of those variants and is not always clear cut.For example, the game Alquerque contains two rulesets, Alfonso X and Covarrubias, because they both describe the game as played in Spain, but with some rule differences.However, we distinguish between the Greek game Portes and English Backgammon as two distinct games despite their nearly identical rules, due to significant geographic and cultural differences.
Games can have multiple names.We use the name for the game as used by the culture where it is most popular, where that can be determined, and list alternative known games in the aliases field.
This data group constitutes our high-level description of games.

Rulesets.
Rulesets are the set of ludemes that describe the specific equipment and rules associated with them.Rulesets can be functionally defined, where changes such as a larger board or a different scoring system would typically not be sufficient for being described as a different ruleset.In the case of Alquerque, the two rulesets differ in that the Covarrubias ruleset imposes a mandatory captured rule as well as the huff rule on top of those presented in the Alfonso X ruleset.However, separate rulesets may have nearly identical sets of ludemes, but must be defined separately because of the cultural information related to them.Backgammon and Portes, as discussed above, demonstrate nearly identical rulesets that are distinct because of their cultural context.There are different types of rulesets.
Games can have multiple alternative rulesets, and often these rulesets come from different kinds of sources.Some are described-explained by someone who belongs to the culture which plays the game, or someone who can be considered to be knowledgeable about the rules of the game, while others are observed-described by someone who recently learned or observed the game as played by others.Rulesets may also be suggested, where someone has provided rules for a game for which the original rules are lost; scholarly, where an expert on a particular traditional game has provided an informed set of rules for playing that game; or reconstructed, which will be rulesets compiled in the process of game reconstruction over the course of the DLP.Finally, incomplete rulesets are those which belong to games for which no complete rules are known to have survived, and are supplied from DLP evidence.Each known ruleset for a game is defined in terms of the ludemes that make it up, as well as the cultural information about who, when, and where it was played.Rulesets which are observed or described will typically be linked to evidence.This data group constitutes our mid-level description of games.This data group constitutes our low-level description of games.

Evidence-Related Data
The evidence-related data refers to items of evidence from various sources that support the existence of given games, rulesets and ludemes.This type of data is direct in nature and typically comes from well defined sources.

Defining Evidence.
Because the scope of the project covers prehistory to the present day, there are many different relevant resources which provide information about games, rulesets, and ludemes.The relevant information is not restricted to the mechanics of how the games are played, but also includes geographic, chronological, and social data, which are essential for being able to model the spread of games.In many cases, a single piece of evidence may provide a complete picture of the ludemes and rulesets that make up a game as well as the relevant cultural material.In many other cases, the evidence may only describe a part of a game, and multiple pieces of evidence must be used for a single game to obtain a more complete picture.For games without complete known rulesets, such as Senet, as much of the evidence will be gathered as is possible.This will allow the project to evaluate what information is most strongly supported by evidence, and what portions of potential rulesets will require reconstruction.For other games which are well-understood and will not need reconstruction, such as Chess, collection of evidence cannot be comprehensive, but will be sampled to reflect the chronological, social, and geographic spectrum of that game, in order to aid in the reconstruction of other games and to accurately model the spread of that game and its potential relationship to other games.

Types of Evidence.
A piece of evidence is a "primary source of information" which provides some form of documentation situating a game in a particular time and/or place.A primary source of information provides first-hand information about a game.As such, the historical data collected on each piece of evidence are those which provide information about where, when, how, and by whom a game was played, not necessarily data about the document from which the information comes.
For example, when documenting relevant artefacts discovered during archaeological excavations, it is the place where they were found, and the dates ascribed to the artefacts, not the date of the archaeological project or the book or article they were published in, that is important.When recording data from evidence in a text published posthumously, the date the text was written is the important piece of information, not when it was published.For a text published somewhere other than the place it describes (such as most ethnographies), it is the place being described, not the place of publication or residence of the author that is to be recorded.In some cases, the data from a document and the game will be the same, such as in original texts discussing games as they were played at the time the text was written, as in the 13th century Libro de los Juegos of Alfonso X of Castille, which describes games played at that king's court, as written by him.An exhaustive list of scenarios could fill volumes; what is important is to consider each piece of information that is entered, and to be certain that, as much as is possible, it reflects the information as it relates to the game as played in its relevant place and time.
Most pieces of evidence will also provide at least some information about the ludemes that make up the ruleset(s) of a game.Each kind of evidence has inherent strengths and weaknesses, and has the potential to provide different pieces of information about a game, ruleset, or ludeme.
The following categories cover the types of primary sources of information that qualify as evidence used for the DLP, though others may be added at a later date: 1.A rules text is a text which was solely written to explain the rules of a game as it was played during the time in which it was written.A good example of this would be the description of Alquerque in Alfonso X's Libro de los Juegos.
2. A contemporary rule description is a text that contains the rules of a game, though the subject of the text as a whole may focus on another topic, by someone from the culture to which a game belongs and who lived during the time the game was played.
3. A historical rule description is a text which purports to tell the rules about a game in the past, from the perspective of the text's author.An example of this would be a text describing how the rules of a game were different a century before the author's time.

4.
A contemporary text is a text that contains some information about a game, written during the time the game was played, but which does not attempt to describe the rules of the game.An example of this would be a text that mentions the favourite game of a king, or a law that forbids a certain game.

5.
A historical text is a text that contains some information about a game that was played in the past, with respect to the author, but which does not attempt to describe the rules of a game.An example of this would be the passage in the Persian epic poem Shahnameh, which features a story about the kings of Persia and India playing Nard and Shatranj against each other.
6.An ethnography is a description or mention of a game by a person talking about a culture to which they do not belong.Though this account is written, it is not a text because it is the content of the encounter which constitutes the evidence.This may be an anthropologist's account of game playing among a group of people they are studying, rules reported by someone who was taught a game by a person from another country, or anyone describing a game from another culture than their own.
7. An artefact is an object that was used to play a game, such as a board, a set of pieces, a pack of cards, or dice.These can tell us about the equipment that was used to play a game, and when they come from a well-documented archaeological context, other information such as date, location, and information in social categories may also be inferred.An example of this are the Senet game paraphernalia found in the tomb of Tutankhamun.
8.An artistic depiction is a representation of a game or people playing a game in a visual media format.Sculptures or paintings of people playing games, where the game can be identified, would be examples of this.
Other kinds of information which come from secondary sources -those which discuss and analyse information from primary sources -, including many books, articles, pamphlets, or websites, are not themselves evidence, but may be cited in an entry for a piece of evidence when they provide relevant information regarding the culture, time, or place about when a game was played.

Criteria for Inclusion.
Evidence is only collected for games which are included in the DLP.Because the DLP seeks to model the spread of traditional games, it is important to be able to track what is known about these games in a given place and time.Traditional games are primarily learned from another person, rather than through rules codified in a document.There is, therefore, some grey area in the determination that must be made for inclusion of a game in the DLP.While this social definition is the conceptual key to modelling the spread of games, it is not always immediately clear when to determine that a game should be included based on the kinds of evidence that are available to us.We therefore use the following criteria when determining when to include evidence for a game in the database: 1.The game can be documented before the nineteenth century.
-The Industrial Revolution, and the commercialisation that followed, made vast changes in the ways games were created and learned, and thus most games invented after this point are not considered eligible.For example, Halma, Chinese Checkers, and Monopoly are not included because they were games that were invented at a clear point in time and marketed commercially, thus spreading through different mechanisms than those modelled in this project.But, games which can be shown to have existed before this process can be inferred to have spread and become popular through the kinds of social mechanisms relevant to this project.
Nevertheless, there are many relevant games which have only been documented since the nineteenth century -though they may be much older -, which are important for analysis.To include such games, the following criteria should be taken into consideration as proxies for determining a game's inclusion.
2. A game must be non-proprietary.
-For example, Monopoly, though widely played and often learned from other players, is disqualified because its owner has control over where it is sold, what the rules are, and other factors that make it unfit for our research.
3. A game only documented after 1800 cannot have an identified inventor.
-Though every game must have been invented by someone, most games that were invented during and since the nineteenth century have spread due to the commercial sale and marketing of games.When a game predates those processes, it can be inferred that it spread through the types of social contacts modelled in this project.Many games predating the nineteenth century have purported and some may even have documented inventors, but the method by which they spread is different.
4. It must be reasonably demonstrable that a game has some cultural value within the society in which it is played.
-This is purposefully widely defined, and there are a multitude of ways this can be shown.The absence of a commercial game set of that game is one clue, but also statements which indicate that the game has a history in that culture, that it is generally learned from other people, the fact that similar games have been documented in neighbouring regions, or that when asked to play a game people know it and do not need to be taught it, are ways to approach this.For example, the game Jekab, observed in the Marshall Islands in 2017 is played as part of cultural festivals on the islands, and is a part of daily life as it is commonly played in public places 7 .

DLP Data Format
The DLP database is a MySQL-based database structure.
Figure 2 shows an Entity Relationship Diagram (ERD) of the DLP database.Blue coloured tables signify Fact tables, purple coloured tables signify Dimension tables, and pink coloured tables signify Junction tables.The tables within the database can be conceptually split into five groups, Games, Rulesets, Games and Rulesets, Ludemes, and Evidence.

Games Section
This section describes all the tables within the Games group of the DLP database, as shown in Figure 3.
Games.Fact table, describing each game, as shown in Table 1.
• Id: Primary identifier (should be left blank).
• Name: Name of the game using only Ascii characters.This is the name of the .ludgame description file associated with this game.The name should be a name for the game that is used by the culture in which it was most widely played, where this can be determined.It could be the most commonly-used name for a game, the most widespread name for a game, or the earliest name for a game, but it must in some way be connected to the culture from which it originates.Where the name of the game contains accents or other characters not used in English, an approximation should be used, and the correct name used in NativeName (see below).
• NativeName: Name of the game using any utf-8 valid characters.This is the name of the game that will be displayed on the ludii.gameswebsite.Leave blank if the native name for the game is the same as the name of its Ascii name.This is used for games with accents or other non-English characters.• Reference: This field contains a reference for a game.Typically, this field contains works that discuss games, but which do not provide new evidence for the game.Murray's History of Board Games other than Chess 3 is an example of a work that discusses many games, but for which it is not the primary source, and therefore should be included here.
• Origin: The origin is an estimation of the earliest place that the game was played, based on the evidence collected.It can be as specifically defined or as broadly defined as the evidence supports.
• DLPGame: True if this game is part of the Digital Ludeme Project.
• PublicGame: True if this game should be publicly available.
• knownAliases: Comma separated list of other known names for this game aside from the main Name chosen above.
• Author: Original author or designer of the game, where known.• Publisher: Original publisher of the game, where known.
• Date: Original date that the game was released, for those where this is appropriate.Dates where the day or month is 00, means that the value for this is unknown.
• ProprietaryGame: True if this game is proprietary.
• Credit: The creator of the .ludgame description file associated with this game.
• SeeAlso: This field references other games that are culturally, historically, or otherwise relevant to this game, and will display them on ludii.games.• EvidenceRange: Time span of all evidence existing in the database for this game, in the form (EarliestYear, LatestYear).EarliestYear and LatestYear are given as the number of years after 3500BCE (i.e.1500 BCE would be 2000, and 600 CE would be 4100).This value is automatically updated by an external script and should always be left blank.
GameSources.Junction table, describing pairings between games and sources (see Table 2).This ties a Source (i.e., a bibliographic reference) to a game.
• Id: Primary identifier (should be left blank).
• SourceId: Primary identifier of the Sources table value associated with this pairing.
• GameId: Primary identifier of the Game table value associated with this pairing.
GameCategories.Junction table, describing pairings between games and categories (see Table 3).This ties a category (e.g.War, Hunt, Space, Card, Dice, etc.) to a game.These categories are based on similar clusters of core functionality between games.
• Id: Primary identifier (should be left blank).GamePeriods.Junction table, describing pairings between games and periods (see Table 5).This ties a period (e.g.Ancient, Medieval, Modern) to a game.7).Games are categorised into groups based on the mechanics of play.
• Id: Primary identifier (should be left blank).
• Description: Short description of the category.

Rulesets Section
This section describes all the tables within the Rulesets group of the DLP database, see Figure 4.
• Id: Primary identifier (should be left blank).• GameId: Primary identifier of the Games table value associated with this Ruleset.
• Name: Name of the ruleset using only Ascii characters.This is the name that will be used within the .ludgame description file associated with this ruleset.Where possible, this will be the name of this set of rules as they are called by the culture that plays them.In many cases, this will not be identified, so it can be given any name that distinguishes it from the other rulesets for this game.
• NativeName: Name of the ruleset using any utf-8 valid characters.This is the name of the ruleset that will be displayed on the ludii.gameswebsite.Leave blank if the native name for the ruleset is the same as its Ascii name.
• Summary: This is a brief summary describing what is unique about this ruleset to appear on the game's page on ludii.games.
• Type: Primary identifier of the RulesetTypes table value associated with this ruleset.This assigns a Ruleset Type to a particular ruleset.
• Description: The ruleset description includes a brief description about the ruleset, and can include cultural information or information about who reported this ruleset.
• Ruleset: These are the rules of this ruleset, described with reference to the main ruleset for this game; i.e., only the differences between this ruleset and the main ruleset of the game should be described.
• Reference: Reference for the ruleset.
• Origin: The origin is an estimation of the earliest place that the ruleset was played, based on the evidence collected.It can be as specifically defined or as broadly defined as the evidence supports.
• Author: Original author or designer of the ruleset, where applicable.
• Publisher: Original publisher of the ruleset, where applicable.
• Date: Original date that the ruleset was released, where applicable.Dates where the day or month is 00, means that the value for this is unknown.-Described: A ruleset described by someone from the culture to which the game belongs.
-Observed: A ruleset reported by someone who witnessed others who played the game, or who was taught the game by people of another culture.
-Suggested: A ruleset for a historical game that was proposed by someone.
-Incomplete: A ruleset which is known to only contain a partial set of rules.In most cases, this will be a ruleset with the rules that are compiled from DLP evidence.-Scholarly: A ruleset for a historical game proposed by an expert of that game.
-Reconstructed: A ruleset reconstructed by the DLP.

Games and Rulesets Section
This section describes all the tables within the Games and Rulesets group of the DLP database, see Figure 5.

Ludemes Section
This section describes all the tables within the Ludemes group of the DLP database, see Figure 6.See Table 13.
• Id: Primary identifier (should be left blank).
• Name: Name of this ludeme.
• Package: Package that this ludeme belongs to.
• Keyword: Ludeme's token as used in game descriptions.
• Description: Description of this ludeme.15).This ties a ludeme to a ruleset.

RulesetLudemes. Junction table, describing pairings between rulesets and ludemes (see Table
• Id: Primary identifier (should be left blank).
• RulesetId: Primary identifier of the Ruleset table value associated with this pairing.

Evidence Section
This section describes all the tables within the Evidence group of the DLP database, as shown in Figure 7.
Evidence.Fact table, describing each piece of evidence, as shown in Table 16.
• Id: Primary identifier (should be left blank).
• TypeId: Primary identifier of the EvidenceType table value associated with this piece of Evidence.This assigns an Evidence Type to a particular piece of Evidence.• GameId: Primary identifier of the Game table value associated with this piece of Evidence.This ties the Evidence to a particular Game.
• RulesetId: Primary identifier of the GameRulesets table value associated with this piece of Evidence.This ties the Evidence to a particular Ruleset, if possible.
• DateStart: This is the earliest possible date from which the information in this piece of Evidence comes, in the format YYYY-MM-DD.For analytical purposes, if left blank, it will be assigned the earliest date of any piece of Evidence for the relevant game.
• DateStartBC: True if the start date for this piece of evidence falls in the BC/BCE era of the Gregorian calendar.
• DateEnd: This is the latest possible date from which the information in this piece of Evidence comes, in the format YYYY-MM-DD.For analytical purposes, if left blank, it will be assigned the latest date of any piece of Evidence for the relevant game.
• DateEndBC: True if the end date for this piece of evidence falls in the BC/BCE era of the Gregorian calendar.
• Location: GPS coordinates for this piece of evidence in the form (6•44'29.95"N, 44•15'43.61"E).If multiple coordinates for a single piece of evidence, then these should be separated with a semi-colon.This place should indicate, as accurately as possible, the place from which the piece of evidence comes.
• KML: Name of the defined .kmlregion file associated with this piece of evidence.If multiple .kmlfiles are associated with a single piece of evidence, then these should be separated with a semi-colon.All possible .kmlregion files can be found in the evidence/kml folder of the database (.zip) download file.A .kml should be used when a GPS coordinate is not sufficient for a piece of Evidence, either because the Evidence explicitly is about a region or because the exact location can only be estimated.
• Rules: These are the rules that are presented by this piece of evidence.Specific, individual rules as accurately as possible are to be placed here as they are demonstrated by the piece of Evidence, and not assumed based on other pieces of Evidence.
• Misc: Generally, the Misc field will describe the piece of evidence: either a short description of its content or its exact text, if available and concise.At least one reference should be cited, using AJA style.Anything relevant to identifying, assigning uncertainly, or qualifying statements about the piece of Evidence goes here.
• ConfidenceMultiplier: Confidence value between 0 and 100 for representing the reliability of this piece of evidence.This value is currently redundant, but may be used to store a multiplier for qualifying the confidence in the interpretation of the content of the piece of Evidence, if needed in future.
• Username: Ludii Forum username of the person who added this evidence into the DLP database.
• Verified: True if this piece of evidence has been verified by a member of the DLP team.
• DateAdded: The date that this piece of evidence was added to the DLP database (should be left blank).
• ExternalDB: Primary identifier of the ExternalDB table value associated with this piece of Evidence.This ties the Evidence to an external database.
• ExternalDBId: Identifying value for the corresponding entry in the external database referenced by the ExternalDB entry.This ties the Evidence to a specific entry within an external database.EvidenceLudemes.Junction table, describing pairings between pieces of evidence and ludemes (see Table 21).This ties a piece of evidence to a ludeme.

EvidenceSources. Junction table, describing pairings between pieces of evidence and sources (see
• Id: Primary identifier (should be left blank).
• EvidenceId: Primary identifier of the Evidence table value associated with this pairing.
• LudemeId: Primary identifier of the Ludemes table value associated with this pairing.
EvidenceUncertaintyFactors. Junction table, describing pairings between pieces of evidence and uncertainty factors (see Table 22).This ties an uncertainty factor (e.g.Incomplete, Graffiti, Ambiguous pattern, Uncertain date, etc.) to a piece of Evidence.
• Id: Primary identifier (should be left blank).
• EvidenceId: Primary identifier of the Evidence table value associated with this pairing.
• UncertaintyFactorId: Primary identifier of the UncertaintyFactors table value associated with this pairing.
EvidenceGenders.Junction table, describing pairings between pieces of evidence and genders (see Table 23).This ties a genders (e.g.Female, Male, etc.) to a piece of Evidence.
• Id: Primary identifier (should be left blank).
• EvidenceId: Primary identifier of the Evidence table value associated with this pairing.
• GenderId: Primary identifier of the Genders table value associated with this pairing.
EvidenceTypes.Dimension table, describing possible types for pieces of evidence (see Table 24).
• Id: Primary identifier (should be left blank).
ExternalDB.Dimension table, describing possible external databases for pieces of evidence (see Table 25).
• Id: Primary identifier (should be left blank).
• Name: Name of the external database.
• URL: URL for accessing the external database.
Sources.Dimension table, describing possible sources for pieces of evidence (see Table 26).
• Id: Primary identifier (should be left blank).
• Source: Reference for the source (books, articles, works of art, manuscripts, etc.) in American Journal of Archaeology (AJA) style.
• URL: Website for assisting in accessing this source.When possible, this should be a link to the text or an image of the source itself.Otherwise, it must be a link to the item's record at worldcat.orgor another resource that will show the user where they can access this material in a library, museum, or other institution.-Unknown provenience: Refers to a piece of evidence for which its place of origin is unknown or under question.
-Written > 100 years after events: Refers to a piece of evidence depicting or describing an event more than one hundred years prior to the date of the text.
-Written > 500 years after events: Refers to a piece of evidence depicting or describing an event more than five hundred years prior to the date of the text.When this uncertainty factor is chosen, Written > 100 years after events must also be chosen, because they are both true.
-Written about a foreign culture: Refers to a piece of evidence that was written by someone discussing a culture other than their own.
-Translated from another language: Refers to a non-English text.
-Secondary Text: Refers to a source which describes another text or object, but which is not the actual text of that document.This may be, for example, a translation of a text reported in a book that is not primarily about that text.
-Game not named: The name of the game is not explicitly included in the piece of evidence.
-Unrepresentative depiction: Refers to a piece of evidence that depicts a game, but is not meant to be an exact depiction of it, for instance a. painting of chess with the wrong number of squares or pieces.
-Insufficiently described rules: Refers to a description of a game that only contains a partial description of the rules.
-Board not described: Refers to a description which omits a description of the board.
-Rules not described: Refers to a description of a game which does not include the rules.
-Rules learned second-hand: Refers to a piece of evidence where the person reporting the rules learned them from another person, who in turn learned them from someone in the culture to which the game belongs.
-Suspected copy of earlier work: Refers to a piece of evidence that is suspected to be a copy of an earlier work, which has never been found.
-Suspected forgery: Refers to an object of questionable authenticity.
Genders.Dimension table, describing possible genders for pieces of evidence, as shown in Table 31.
• Id: Primary identifier (should be left blank).
• Gender: Male, or Female should be chosen when the game is either said to be played only by people of that gender, or only supplies information about people belonging to one of those genders."All" should be selected when the source states that there is no gender disparity in who plays the game."Other" stands in for other gender identities which may be identified as players of a particular game.This may be clarified and expanded as necessary.

Accessing the DLP Database
All data contained within, or referenced by, the DLP database is fully public and available to access.

Complete Database
The complete DLP Database package can be downloaded as a single .zipfile from: https://ludii.games/downloads/database.zip.These unique identifiers should also be used when referencing a specific entry in the DLP database within an external document.When referencing a specific .ludgame description file associated with a game, include both the reference for the game (DLP.Games.N ) and the version of the .ludfile that was used (this can be found within the .ludfile itself, and is the same as the Ludii App version number).

DLP Server
The DLP database that this document provides is stored within the DLP Server, which is housed at Maastricht University behind a secure firewall.However, the information within this Database is used and updated by many other processes.We therefore provide a short overview of the distinct processes and structures which are stored on the DLP Server and how they interact and communicate with each other, see Figure 8.

DLP Database
The DLP Database contains all the information described in this document.

User Database
The User Database contains personal information about the players who use Ludii.As the vast majority of the information in this database is private, it is not available to download.However, some information that is stored in this database can be viewed using either the Ludii Portal or Ludii App (tournament results, player statistics, usernames, etc.)

Server Scripts
Several external scripts run periodically on the DLP Server to update information stored in the DLP and Ludii Databases.For the DLP Database, this includes the origin point and evidence ranges for each game.For the User Database, this includes logout timers, tournament results generation, Elo rating calculations, etc.

Ludii Portal
The Ludii Portal consists of all websites and scripts under the ludii.gamesdomain.This includes the game library, world map, forums, user account and database management, etc.The Ludii Portal communicates with the User Database for managing the Ludii Forum (https://ludii.games/forums/),as well as providing several user account specific functions, such as tournament control panels or personalised recommendations.The Ludii Portal communicates with the the DLP database to access information about the games, rulesets and evidence it displays, as well as allowing select validated users to add new evidence to the DLP database.

Ludii App
The Ludii App consists of the downloadable Ludii software in the form of a .jarexecutable.This includes functionality such as playing games, running AI-based analysis, participating in online tournaments, messaging other Ludii App users, etc.The Ludii App does not communicate with the DLP and Ludii Databases directly, but instead requests and sends information indirectly via the Ludii Portal, which then communicates with these databases.When engaging in network games or tournaments, the Ludii App communicates with the User Database to facilitate all remote connections and data transfer (verifying user identity, connecting to online games, sending moves and messages, etc.)The Ludii App also communicates with the DLP Database, sending information about the results of the experiments and analysis it conducts, and receiving metadata information about the games it contains (rulesets, description, origin, etc.).

FAIR Compliance
The FAIR Principles are a set of guidelines established by a consortium of scientists and organisations to promote the preservation and effective reuse of scholarly data 6,8 .The four main FAIR Principles, and the ways in which the DLP Database and its constituent data adhere to these principles, are summarised below:

Findable
Data should be assigned globally unique and persistent identifiers and be indexed in a searchable database.
Data in the five main data categories of the DLP Database -Games, Rulesets, Games and Rulesets, Ludemes and Evidence -each have a globally unique identifier that identifies their data category.For example, the identifier DLP.Games.7 uniquely identifies the game "20 Squares" as the seventh entry in the Games category of the DLP Database.The DLP Database is searchable in SQL format through the freely available database download1 and also manually searchable through the web-based Ludii Game Library2 which provides user-friendly interface for navigating the games within the DLP Database and the associated evidence for them.

Accessible
Data should be freely retrievable by their unique identifiers using standard communication protocols.
Individual data items within the DLP Database are freely accessible using standard internet protocols, by encoding relevant details about the item, including its data category and unique and index, as a URL in the format https://ludii.games/identifier?Id=DLP.T.N For example, accessing the DLP Server with the URL https://ludii.games/identifier?Id=DLP.Games.7 will retrieve the data for the game "20 Squares".

Interoperable
Data should use a formal, accessible, shared and applicable language for knowledge representation, and include qualified references to other data.
All data is stored as plain text to maximise compatibility and make it as widely reusable as possible.
We are able to utilise and import data from other sources.This is not an automated process, as other research projects gather different data and format it according to their own needs.Therefore, any data from an outside project must be reviewed and reformatted to fit our needs.
Recently, we incorporated data from the ERC-funded Locus Ludi project3 to be imported into our evidence table.When the data was received, the data table was reformatted in R to eliminate irrelevant columns (data which they collect but which we do not) and entries (games which they are documenting but which we are not), add columns that are present in our table but absent from theirs (data they are not collecting; making sure these contain their default values), merging columns (when the data are presented in their table in multiple columns in theirs but in one in ours), reformat all data fields to be of the appropriate type, and reorder columns to match that of our data table.
A pertinent example involved the conversion of dates.In the Locus Ludi data, dates are recorded in two columns, dating start and dating end, as an integer, negative indicating a BCE date.These dates needed to be converted to YYYY-MM-DD format and the columns renamed to DateStart and DateEnd.New columns needed to be added, DateStartBC and DateEndBC, with a value of 1 for all BCE dates, and a value of 0 for all others.The columns were reordered: DateStart, DateStartBC, DateEnd, DateEndBC, within the table (following RulesetId and preceding Location) to maintain the order of our data table.
Once the data were converted to fit our table format as laid out in section 3 above, the new data were then converted to a CSV file, and imported into the Ludii database.Further editing within certain fields (such as the text in Content, which contains data merged from several Locus Ludii columns) was performed in PHPMyAdmin to more closely resemble the style of our descriptions.
Further work was necessary to link relevant tables (such as links between these new Evidence entries and Sources), which were performed as though they were newly generated entries.
The original identifiers of the Locus Ludii data (Name and URL) are recorded in the ExternalDB table.For each piece of evidence that was originally sourced from the Locus Ludii dataset, the database Id is given the ExternalDB field, and the unique identifier for that entry is placed in ExternalDBId.
Another simple type of data that is reused in the DLP Database from an outside source is the BGG identifier for each game.This is a unique identifier within the BoardGameGeek 4 online database for each game, in the format BGG.N (where N is the identifier number).BoardGameGeek is the world's premier online database for board games and a wealth of non-scientific information including user ratings and game popularity, so it useful to correlate each game in the DLP Database with their corresponding entry (or entries) in the BGG database.

Reusable
Data should be richly described with relevant attributes, released with a clear usage licence, and meet relevant community standards.
All data in the DLP Database is publicly available for reuse without restriction, with the exception of some categories of proprietary or potentially sensitive data that are kept private, e.g.rule set descriptions for proprietary games that we do not have permission to disseminate, and user data harvested from online play sessions that might have implications for GDPR compliance.Each data item in the DLP Database is stored in plain text format for maximum portability and each data field is labelled with a meaningful name to encourage its correct use.
Game-Related section: it would not be impossible, by a major coincidence, that two different games could use the same ruleset.Is the data model able to represent that?The ERD seems to say yes, but perhaps it should be said, to underscore the differences between games and rulesets.
Ruleset section: the sentence 'There are different types of rulesets.'feels out of place.
If a game has several rulesets, is there one default ruleset?If yes, what are the criteria to choose it?(note: in page 7 the authors mention a «base ruleset») The two sentences: This data group constitutes our mid-level description of games.This data group constitutes our low-level description of games.are perhaps placed in the wrong place?
The ERD of page 7 should have more definition.It's very hard to read even by zooming in the pdf file (the tables are bigger in the following pages, but it would be nice to see them all together with proper detail) There is a ProprietaryGame and a PublicGame field.Is there any possibility that both are true, or both are false?Why the Credit field does not map into a Creator table?The database allows different names of the same person?The same question seems relevant for the Origin field.
And the EvidenceRange shouldn't it be two integers?
Were the game categories predefined by humans (using standard names) or were they adjusted using a clustering process given their ludemes?It seems the former was adopted.Have you tried the latter?If so, a footnote would be interesting reading.[outside the scope of this document] I tried using your services, and checking ludeme Gravity, https://ludii.games/ludemeDetails.php?Id=228, I was expecting the list to include Connect4 but it only has Gonnect.I think this is a typo in your data, or the ludeme means something else entirely.

Are sufficient details of methods and materials provided to allow replication by others? Yes
Are the datasets clearly presented in a useable and accessible format?Yes Competing Interests: No competing interests were disclosed.
Reviewer Expertise: History of mathematics.History of boardgames.
We confirm that we have read this submission and believe that we have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.

Aris Politopoulos
Leiden University, Leiden, The Netherlands The article presents the complete outline the Digital Ludeme's Project database, as well as the rationale behind the type of data that were collected.The rationale behind the creation of the database is clearly described under the section "purpose", although this particular section could be expanded a bit further (e.g. with one more paragraph) with some more citations and a few examples of the issues described.The protocols are appropriate and the work is technologically and methodologically sound.The article provides a full description of the database, as well as the choices that went behind certain elements of the database (e.g. the Ludemes as a baseline for describing and connecting rules).Datasets are clearly presented and described with consistent examples to illustrate the functionalities of the database.

Are the datasets clearly presented in a useable and accessible format? Yes
Competing Interests: No competing interests were disclosed.
Reviewer Expertise: Archaeology of play, ancient board games, archaeogaming, digital archaeology I confirm that I have read this submission and believe that I have an appropriate level of expertise to confirm that it is of an acceptable scientific standard.

Figure 1 .
Figure 1.Overview of the main data groups and the relationships between them.

Figure 2 .
Figure 2.An Entity Relationship Diagram (ERD) of the DLP Database.

•
OriginPoint: GPS coordinates for the earliest piece of evidence existing in the database for this game, in the form (6•44'29.95"N, 44•15'43.61"E).This value is automatically updated by an external script and should usually be left blank.If you wish to override this script and set the origin point for yourself, then a '*' must be added to the end of the OriginPoint value (e.g.6•44'29.95"N,44•15'43.61"E*).

Figure 3 .
Figure 3.An Entity Relationship Diagram (ERD) for the Games group of the DLP database.

Figure 4 .
Figure 4.An Entity Relationship Diagram (ERD) for the Rulesets group of the DLP database.

Figure 5 .
Figure 5.An Entity Relationship Diagram (ERD) for the Games and Rulesets group of the DLP database.

Figure 6 .
Figure 6.An Entity Relationship Diagram (ERD) for the Ludemes group of the DLP database.

Figure 7 .
Figure 7.An Entity Relationship Diagram (ERD) for the Evidence group of the DLP database.

Figure 8 .
Figure 8. Overview of the DLP Server, what aspects it contains, and how these interact with each other.Boxes which are red contain private information, and cannot be directly accessed or downloaded in their entirety.

Reviewer
Report 27 March 2024 https://doi.org/10.21956/openreseurope.17838.r35367© 2024 Politopoulos A. This is an open access peer review report distributed under the terms of the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Table 1 . Structure of the Games table.
•Id: Primary identifier (should be left blank).• GameId: Primary identifier of the Game table value associated with this pairing.• RegionId: Primary identifier of the Region table value associated with this pairing.Categories.Dimension table, describing possible categories for games (see Table

Table 8 . Structure of the GameRulesets table.
RulesetRegions.Junction table, describing pairings between rulesets and regions, as per Table10.This ties a region (e.g.Northern Africa, Caribbean, Western Asia, etc.) to a ruleset.•Id:Primary identifier (should be left blank).

Table 11 . Structure of the RulesetTypes table.
Table 12).All values in this table are automatically updated by an external script.

Table 15 . Structure of the RulesetLudemes table.
•Count: The number of times this ludeme occurs in this ruleset's description.

Table 16 . Structure of the Evidence table.
Table17).This ties a Source (i.e., a bibliographic reference) to a piece of Evidence.
EvidenceSocialStatuses. Junction table, describing pairings between pieces of evidence and social statuses (see Table19).This ties a social status (e.g.Non-Elite, Royalty, Clergy, Merchant, etc.) to a piece of Evidence.•Id:Primaryidentifier(shouldbeleftblank).•EvidenceId:Primaryidentifier of the Evidence table value associated with this pairing.•SocialStatusId:Primaryidentifier of the SocialStatuses table value associated with this pairing.EvidenceSpaces.Junction table, describing pairings between pieces of evidence and spaces (see Table20).This ties a space (e.g.Inside, Public, Ritual, Communal, etc.) to a piece of Evidence.

Table 18 . Structure of the EvidenceAges table.
•SpaceId: Primary identifier of the Spaces table value associated with this pairing.

Table 31 . Structure of the Genders table.
Specific entries within the DLP database are can be individually accessed using its unique identifier.The unique identifier for an entry is represented in the form DLP.T .N, where T is the name of the table within the DLP Database and N is the Id field value of the entry (e.g.DLP.Games.426or DLP.
What is the relevance of the Period table?On the Ludeme table, clarify what Package means.The model states it is a string, but what kind of information is inside that string?Clarify types of ludeme.Eg, what is a superludeme?What means «Grammar symbol corresponding to this ludeme»?URL https://ludii.games/downloads/database.zip does not work