OpenGDD

Known limitations

This page describes the OpenGDD v0.9 working draft. A package can express things that a tool cannot always find or check. Certification is experimental in this version. Nothing on this page changes a certification result.

Deliberately out of scope#

The current OpenGDD core does not define:

  • multiplayer session, delivery, networking, or private-view behavior;
  • checks of rendered 3D images. A web-3d package can pass validation, but the format does not say how to capture and measure rendered 3D images;
  • binary asset pipelines;
  • audio direction (see Audio below);
  • localization structure;
  • monetization design, including in-app purchases. The format has only the optional commerce field in the manifest, which records the designer's share and the builder's share;
  • a registry API; or
  • target platforms other than web-2d and web-3d.

platform says where the game runs and whether its game state needs two or three dimensions. It does not name the rendering technique. A game with flat game state is web-2d even when a builder draws it with a perspective 3D renderer. web-3d is for game state that needs three dimensions. The builder chooses the rendering technique unless the package states otherwise. Every requirement of the package must still hold with the chosen technique. When a technique changes how the game plays, the package must settle that decision. §2a of the OpenGDD specification lists the five things that decide whether a difference changes how the game plays. The build record does not record the rendering technique.

Real host-filesystem, save-byte, achievement, and recording integration is also not standardized for the current web targets. Simulated versions inside the game's fiction are ordinary game state.

Parts in scope that the format does not define yet#

A limit here does not mean a game is unbuildable. It means the package still needs its own prose or tests that independent tools cannot infer from OpenGDD alone.

Multiplayer authority and hidden information#

Many rules can be written as deterministic state transitions. The current core has no shared model for session membership, network authority, delivery, reconciliation, or private-view non-leakage. Those facilities need a future profile.

Puzzle-solving tools#

The working draft defines the parallel-string-layers-1 grid layout. A package can describe a puzzle and require that the puzzle has a solution. Independent tools still need shared rules for receiving the puzzle and reporting a solution. Until such rules exist, each package defines its own commands and conditions.

Rules that change without a fixed list#

A package can activate or replace rules when the designer has declared every such rule. The package does this through Fixed prose, declared ruleset state, and tests. The format does not standardize a game that creates new words or new behavior during play, outside the declared list of rules.

What a player knows or feels#

A test of game state cannot prove what a player knows, understands or enjoys. A test can show which places can be reached and which events happened. Those observations do not prove how a player understands the game.

Simulation detail smaller than the package specifies#

A package can specify large-scale results without specifying the size of simulation cells or steps. Below a declared feature width, or between declared observation times, visible outcomes may depend on cell size, neighborhood, update order, or another architectural choice. OpenGDD can state a limited requirement on what is observed, and the test that checks the requirement. This version defines no general rules for material simulation. It does not standardize every cell size or intermediate state.

Personalized presentation#

A player may choose part of the presentation, such as colors. The direction file does not define how those choices combine with the package's palette and color promises. An exact visual property can be audited only where a test and machine-checkable evidence show the result. Prose direction remains open to interpretation.

Material feel and motion#

Text, named palettes, and annotated reference imagery can communicate separate features such as shape, stitches, edge treatments, and shadows. Continuous qualities such as fiber, sheen, and deformation are harder to describe so that different builders produce the same result. The direction format has pillars, moods, anti-references, must-keep entries, annotated references, and color, contrast and timing promises. It has no general material-rendering solution. Judging a build against the direction belongs to the audit, which is part of the experimental certification protocol.

What the format cannot correct in a package#

OpenGDD cannot correct a package that has contradictory rules or incomplete evidence:

  1. Specify outcomes, not architecture. Require the observable result and its evidence. Leave renderer structure and equivalent implementation techniques to the builder, unless they are themselves part of the design.
  2. Give every test an input and a target. A useful test names its setup, action or schedule, expected observations, tolerances, and diagnostics.
  3. Do not create a second authority channel. Local fields must not silently redefine Fixed, Delegated, or Personalization authority.
  4. Do not restate tuning values in normative prose. Prose binds to keys and formulas. A number in an example carries no authority. A reader decides whether a sentence restates a rule.

A package that passes the schema checks is not proven complete. Before sharing a package, its author reviews the rules, confirms that every reference resolves, and confirms that each test can be set up and repeated. The author also states which claims the available evidence does not support.

Art direction#

Art direction is optional in the current working draft. When it is used, one direction.json file at the package root carries palettes, pillars, mood, anti-references, and must_keep requirements. It also carries measured colors, contrast, and timing promises, and the package's viewing conditions. Color promises use CIEDE2000 distance, contrast promises use the WCAG 2.1 contrast ratio, and timing promises cite a number in the values table of tuning.json. The format fixes those metrics. An entry cannot choose its own. Every colors, contrast, and timing entry must be covered by at least one acceptance test through its direction_claims field.

Different builders reproduce a palette and shapes more exactly than a continuous material quality. Not every exact visual surface has a machine-checkable evidence path. An exact texture with no applicable test stays a prose requirement, and package validation cannot decide whether it is met.

Audio#

Audio direction remains draft material in this version. A package can describe audio in prose. OpenGDD makes no claims about audio direction and defines no method to judge audio.