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;