plugg

plugg

Programming Language for Unified Generic Game Service

Based on the Game Description Language Specification and its extensions GDL-II and [rtGDL][], as well as selected concepts from CGDL (Card Game Description Language) and RBG (Regular Board Game) definitions, with a few adjustments (e.g., case-match patterns and added semantics to structured types).

The goal is to have one definition of a game in GDL and be able to generate the backend (for persisting games and game history), the service interface (with automatically generated RPC endpoints, extended by explicitly defined endpoints) and the client interface (for joining, updating and reviewing games), inserting accessibility hints in game components based on Vue component definitions.

Repository organization

• plugg: a parser and compiler for .ggd source (Plugg language), a superset of GDL and compatible with several of the language's variants. It can compile Plugg down to GDL-II (or in some cases rtGDL) and will compile to GDL if able. Contains a parser/compiler for both golang and TypeScript, developed in tandem. From there it can code-generate a reasoner engine for an arbitrary game or, with some of the semantics of the Plugg extensions to GDL, generate a client UI for a compatible platform (where the board and equipment components are defined). This repo has github actions for compiling the parser and benchmarking its parse times for priority operations (e.g. ground relations used in player moves).

• plugg-api: the common protocols and data types that all players (human and AI), as well as game master and lobby interfaces, use to interact. These are defined as a separate repo because some environments do not need an entire Plugg compiler to play (e.g., the game clients that have been code generated from rules). This is not to say that clients should not depend on plugg, but that there are benefits to building clients that only need to depend on the API. This repo has no github actions, but has hooks into build and test that check for internal consistency.

• plugg-gm: a golang service adhering to the Game Manager for hosting games. It coordinates the simultaneous play of moves, shares game updates with players and spectators, and validates legal play adhering to the game's rules. Though it depends on plugg so that it can arbitrate any bespoke games, some of the game rules may be a compiled-in go plugin generated by pluggc or partially compiled into an intermediate notation that the service can snapshot and read back in when play resumes. This repo has github actions for staging the GM to be released.

• plugg-db: maintains the list of games, game metadata and game history for recent matches. Is defined in a game-agnostic way and compatible with OpenAuth ID servers to provide ACLs across any arbitrary game definition or game state representation. Clients do not need to know how the metadata and replay data are stored, only how to retrieve and parse it as described in plugg-api. This is the reference implementation for database-related operations in the API.

• plugg-games: a private repository containing the game rulesets and backup of the wiki content residing at GGP Dojo. This is the backing store for games while they are in progress and is periodically synced with the servers running the ggpdojo site. Game metadata will include a 'status' property indicating whether it should be shown in the index or only available to beta testers, etc. This has no github actions; part of the release of any component that reads the game definitions (e.g. GM, clients), that may block if unable to parse a game that has been released and has a stable status. Making game parsing a submit blocker sounds interesting but would be a challenge in this multi-repo setup. Maybe with a release binary of the plugg-check binary? Will consider it.

• ggp-dojo: web site frontend for ggpdojo.com and OAuth callback receiver. It exposes the interface for viewing current games, creating new ones or joining a lobby invitation. This only needs to depend on plugg-api and plugg-db, it is the GM's responsibility to arbitrate game logic decisions. There is also a dependency on vue-client because ggpdojo.com is a convenient location to deploy it from, but that dependency is at deployment time, not during build. It would be interesting to implement an SPA from within a game description...
  This repo also has the FrontEnd server's github actions for staging a release.

• *-client: a variety of compilation targets could exist, but the primary target will be vue-client so that a playable client can be embedded in the same website as the wiki and public match listings. Next planned are other targets such as flutter-client and steamvr-client, which may only need to depend on plugg-api as reference implementations for clients that target a (pre-compiled) set of game definitions.

• plugg-bot: reference implementation for a competitive AI that can play most small games optimally and some larger games decently. Depends on the API for joining and playing games, depends on plugg for compiling a game into an intermediate representation. The intent is not to have the most competitive AI player but to accelerate the path for those who want to explore creating one. We will spend that time making a more effective tournament space so that the best reasoning engine may emerge. This repo also has the github actions for staging a release in its cluster.

Dependency structure

graph LR;
    plugg/go-->plugg-db;
    plugg/go-->plugg-gm;
    plugg-db-->ggp-dojo;
    plugg-api & plugg/ts --> plugg-bot & vue-client;
    vue-client <-.-> ggp-dojo;
    plugg-api-->plugg-gm;
    plugg-games--->ggp-dojo;