Some of you already know that I’ve been working on-and-off on a lexicon for video games. I figured it would be a good idea to put the lexicon up for further discussion, and to make sure I’m headed down the right path with things.
But why?
Last year, the video games industry experienced a significant upheaval when radical groups leveraged moral panic to pressure payment processors, which in turn pressured games platforms to remove NSFW applications. This resulted in a lot of underrepresented developers being further marginalized, and made it increasingly obvious that developers need an avenue to own, manage, and distribute their own games without interference from a centralized authority like Steam, Itch, or payment processors.
I’m excited to share the video game lexicons I’ve been developing. These lexicons provide a structure to standardize and manage game data in a decentralized, user-owned manner. While this doesn’t directly solve any specific issue in the games industry, it provides a strong foundation on top of which many solutions can be built.
I’m looking for any and all feedback, from technical to user perspectives.
For those unfamiliar with ATProto
ATProto is the decentralized protocol that backs Bluesky. You may want to review the links below before digging into the rest of the post.
Overview
The games.gamesgamesgamesgames.* lexicon namespace is intended to create a comprehensive system for cataloging games, as well as their metadata and relationships. This allows developers to create and maintain their own game records on ATProto while ensuring consistency and interoperability across applications.
Here’s a handful of projects that could be built on top of the game lexicon:
- A
games.gamesgamesgamesgames.scorerecord could define a data structure for scores, allowing games to store a user’s scores in their repo. This could be extended by a sidecar lexicon that adds something like aS/A/B/Ctier ranking. - A
games.gamesgamesgamesgames.licenserecord could allow digital games stores to sign and save game licenses into a user’s repo. - A
games.gamesgamesgamesgames.binaryrecord could allow DRM-free binary(s) for a game purchased by a user to be stored in the user’s repo.
None of these ideas are fleshed out, or even things I desire to build; they’re just concepts that would require a standard game lexicon to exist and before they could be built in a way that they’d be truly decentralizable.
What exists now
I’ve created a base set of lexicons that are already published to represent a tiny slice of a game’s data. This currently includes:
- base - Includes:
name- The name of the gamesummary- A summary of the gamemodes- An array of different modes that can be played (Battle Royale, Co-operative, MMO, Multiplayer; full list available in the lexicon)type- The type of game property this record represents (Game, DLC, Mod; full list available in the lexicon)
listGamesandgetGame- Queries for retrieving a list of games or a specific gameputGame- Procedure for publishing a game
Questions
Does this base structure make sense?
Specifically, I’m curious about the structure of the type and modes fields on games.gamesgamesgamesgames.game. type uses a ref to an enum, but it feels awkward. modes is the same as type, but it’s an array of enums. From a technical perspective, does this make sense? If this is the right way to go, I’ll quickly add the following fields (also taken from IGDB):
genres- Fighting, Music, Platform, Puzzle, etcplayerPerspectives- First Person, Third Person, Virtual Reality (VR), etcthemes- Action, Horror, Kids, Party, etc
How should we handle release dates?
A game may have multiple release dates which differ by region, platform, status, etc. This is the structure I’m currently planning for:
{
"releaseDate": {
"type": "object",
"properties": {
"releasedAt": {
"type": "string",
"format": "datetime"
},
"platform": {
"type": "string"
},
"region": {
"type": "string"
},
"status": {
"type": "string"
}
}
}
}
The only non-obvious field there is status, which would represent the release state (i.e. Beta, Early Access, Released, etc, reference Release Date Status from IGDB).
Art and other images?
I’m currently planning for capsuleArts, keyArts, and screenshots fields to handle some of the typical images that are associated with a game. We’ll also need a trailers field.
How are others handling arbitrary image fields? blobs are obviously the way to go, but are there any serious concerns to be considered from the technical side?
What’s next?
I’ve already started work on a website to operate as an alternative to IGDB using this data from ATProto. Once these lexicons are reviewed and fleshed out, I’ll get it published, making it easy for developers and publishers to start publishing their games on protocol.
After the IGDB alternative is settled, I’m hoping to dig into the issue of distribution. I’d like to figure out what it looks like to distribute games on protocol.
References
Lexicon data
- Lexicon Repository on Github
- Lexicon files are in
packages/lexicon/src
- Lexicon files are in
- Up-to-date lexicons via PDSLS
Narratives
