Standard
Refers to the whole OBGX.
Edition
Refers to the periodic aggregate release of the OBGX standard. The current edition scheme is [OBGX ]<yy>.<m>. (OBGX is added when disambiguation is needed). For example: OBGX 26.9 or 26.9 refers to the September 2026 release of the OBGX standard.
Draft
Refers to a work-in-progress edition of the OBGX standard, which is not yet finalized and may be subject to change. Drafts are typically used for internal development and testing purposes, and are not considered stable or reliable for production use.
Drafts are identified by the edition scheme followed by a -draft suffix. For example, 26.9-draft.
Revision
Refers to a subsequent correction to an edition of the OBGX standard. The current revision scheme is [OBGX ]<yy>.<m>.<r> (OBGX is added when disambiguation is needed). For example: 26.9.1 refers to the first revision of the September 2026 release of the OBGX standard.
Domain
Refers to a specific area of functionality within the OBGX standard, divided by manual semantic boundaries.
Current domains include:
- Data Model: Defines the data structures and formats used for representing OBGX understandable data.
- Game Model: Defines the game content and mechanics that can be implemented using OBGX, including blocks, entities, etc.
- Presentation: Defines the presentation layer of the game, including texts, textures, sounds, etc.
- Interaction: Defines the interaction layer of the game, including user input, GUI, and other interaction mechanisms.
- Host Services: Defines the out-of-game capabilities that can be provided, such as networking, storage, multimedia, and other services that can be used by the content packs.
- Runtime: Defines the implementation-specific execution facilities available to content packs.
- Host Integration: Defines the lower level integration of a host with its underlying game engine, possibly including render pipelines, network packets, and other engine-level integration points.
- Diagnostics: Defines the diagnostic and debugging capabilities that can be provided to content packs, including logging, error reporting, profiling, and other diagnostic tools.
Module
Refers to an independent unit of functionality within a domain, which can probably be implemented as a unit.
Module is the core concept of OBGX. They are the unit of versioning and dependency management.
Every module has an identifier. The scheme for module identifiers is [<vendor>/]<moduleName>@<version>, in which <vendor> and <moduleName> match ^[a-z](?:[a-z0-9-]*[a-z0-9])?$, and <version> matches ^[1-9][0-9]*$.
For example, block@1 and cherrygrove/block-layers@200 are valid module identifiers.
The vendor is optional. An unqualified module is a standard module specified by the OBGX standard. A vendor-qualified module and an unqualified module with the same module name are distinct modules. For example, block@1 and cherrygrove/block@1 do not identify the same module.
A specific version of a module can have dependencies on other modules, with specific versions or version ranges. The following forms of <version> are supported when describing dependencies:
4 (original form)
>=4
>4
<=8
<8
>=4<8
>=4<=8
>4<=8
>4<8
For example, block@>=4<8 means the module block with version greater than or equal to 4 and less than 8, or allows block@4, block@5, block@6, and block@7 to satisfy the dependency.
Element
Refers to an atomic unit of normative construct inside a module, which can be a type, an enum, a function, or a fault (type).
An element must belong to one version of a module. The scheme for element identifiers is <module-scheme>/<elementName>, in which <elementName> matches ^[a-zA-Z_][a-zA-Z0-9_]*$.
For example, block@1/Block and cherrygrove/block-layers@2/regBlockLayer are valid element identifiers.
Interface
Refers to an abstract contract defined by OBGX. An interface specifies a contract for types, values, operations, or behavior without specifying how an implementation represents or realizes them.
OBGX types, object declarations, and function declarations are interfaces. An element may define an interface or part of one, and an interface does not need to correspond to an element.
An implementation may realize an interface through programming-language types, operators, functions, methods, properties, declarative constructs, data formats, or any other suitable form.
Operation
Refers to an abstract action whose semantics are defined or constrained by OBGX. An operation is independent of the concrete form used to perform it.
Examples of operations include invoking a function, indexing an array or vector, determining an enum value's active member, obtaining an enum member's payload, and performing numeric arithmetic.
An operation may be realized as a programming-language operator, function, method, property access, pattern match, declarative construct, data-processing step, or any other suitable mechanism. Performing an operation does not require calling an OBGX function, crossing an API or implementation boundary, interacting with an implementation or host, or transferring control to an OBGX runtime.
OBGX may require an implementation to provide one or more operations for a specified purpose without prescribing their concrete forms. Every operation provided to satisfy such a requirement must satisfy the OBGX semantics defined for that purpose.
Game Object
Refers to a piece of game content metadata registered with a host through an implementation of an OBGX interface, such as a record, block, or entity.
Host
Refers to a logical OBGX interoperability environment that provides one or more implementations to packs. A host maintains the shared pack associations, namespaces, game object registrations, and other host-wide OBGX state used by its implementations.
The implementations provided by a host operate on the same host-wide identities and registrations. They may use different representations, but those differences must not alter OBGX-visible identity or behavior when values or registered game objects are communicated between them.
Implementation
Refers to a concrete, coherent realization of OBGX interfaces and operations available to packs within a host. An implementation may use one or more programming languages, declarative languages, or data formats.
Each implementation belongs to exactly one host. A host may provide one or more implementations.
An implementation is the unit for declaring support for OBGX modules, elements, and their versions.
Implementer
Refers to a person or organization that develops a host, an implementation, or both.
Pack
(Or content pack) refers to a collection of interface usage code and static assets that can use OBGX interfaces and operations as realized by one or more implementations of a host that correctly implements the OBGX modules used by the pack.
Identifier
When this terminology occurs without context, it refers to a value used to identify a game object.
This word also occurs with context. When it occurs with context, it refers to a value used to identify another thing depending on the context.
Namespace
Refers to an identifier associated by the host with a pack that participates in OBGX operations. Each pack is associated with exactly one namespace, while multiple packs may be associated with the same namespace.
A namespace does not identify a pack or imply ownership by a pack. OBGX does not specify how a host determines, stores, or internally represents the namespace associated with a pack.