prometeu-studio/docs/specs/random/pbs/PBS - Game Language Profile v1 (Draft).md
2026-03-24 13:42:16 +00:00

4.3 KiB

PBS - Game Language Profile v1 (Draft)

Status: Draft (Language/Product direction) Scope: PBS game-first language contract for 2D workloads Language: English

1. Purpose

This document defines the language-level direction for PBS as a game-first scripting language.

The profile targets:

  • intuitive onboarding for beginners,
  • predictable frame behavior for real-time 2D games,
  • explicit performance/cost surfaces for advanced developers,
  • strict compatibility with a closed VM and its bytecode/runtime authority.

This document is language-contract oriented. It does not define bytecode encoding details.

2. Authority and compatibility

Normative precedence order:

  1. Runtime authority (docs/specs/hardware/topics/chapter-2.md, chapter-3.md, chapter-9.md, chapter-12.md, chapter-16.md)
  2. Bytecode authority (docs/specs/bytecode/ISA_CORE.md)
  3. PBS - Language Syntax Specification v0.md
  4. This document (Game Profile direction and requirements)
  5. Legacy references (docs/specs/pbs_old/*)

If any rule here conflicts with runtime or bytecode authority, this document is invalid for that rule.

3. Design constraints

  • The VM is a closed execution target.
  • Language features must lower to supported VM/bytecode behavior.
  • Determinism and frame synchronization are non-negotiable.
  • GC is the baseline memory strategy.

4. Ten normative rules

Rule 1 - Frame-first semantics

PBS game-facing language features MUST preserve deterministic frame execution. Language constructs MUST NOT imply hidden asynchronous callbacks or preemptive execution.

Rule 2 - Closed-VM compatibility

PBS MUST only define features that can be represented by the closed VM contract. Language design MUST NOT require custom allocators, hidden host threads, or runtime behaviors outside VM authority.

Rule 3 - GC-first memory model

PBS MUST treat GC-managed heap semantics as the default and beginner path. Any future lifetime tools (such as pools/arena-like workflows) MUST be additive at API/library level unless runtime authority changes.

Rule 4 - Explicit cost surfaces

PBS SHOULD make high-cost operations visible to users through language diagnostics and tooling contracts. At minimum, allocation pressure, frequent host calls, and hot-loop risk points SHOULD be reportable in deterministic diagnostics.

Rule 5 - 2D game-native type surface

PBS SHOULD provide a first-class game-oriented type surface through core language + standard library alignment. The profile MUST support fluent expression of common 2D tasks (positions, velocities, bounds, colors, sprite/tile identifiers, frame counters).

Rule 6 - Service boundary as gameplay architecture

service MUST remain the primary executable boundary for gameplay systems. Language guidance SHOULD promote service-oriented decomposition for input, simulation, rendering orchestration, audio, and UI flows.

Rule 7 - Typed host contract boundary

Host interactions MUST remain typed and explicit at language level. Language constructs for host-facing APIs MUST preserve capability checks and syscall determinism from runtime authority.

Rule 8 - Frame-based event and timer model

Game-facing event/timer language patterns MUST be frame-based and deterministic. Language evolution MUST NOT reintroduce interrupt-like user execution semantics.

Rule 9 - Progressive complexity in one language

PBS MUST support both beginner and advanced developers without forking into separate languages. The beginner path MUST keep defaults simple and safe; advanced control MUST be explicit and opt-in.

Rule 10 - Fluency for game loops

PBS syntax and standard patterns SHOULD optimize for high-frequency game-loop code:

  • concise state updates,
  • clear system boundaries,
  • predictable data flow across update/render stages,
  • minimal boilerplate for frame-driven logic.

5. Non-goals for this draft

  • Defining new bytecode opcodes.
  • Replacing runtime GC with a new mandatory memory subsystem.
  • Adding language-level async callbacks or non-deterministic host behavior.

6. Planned follow-up specs

  1. Game Profile syntax additions (if needed), layered on top of v0 Core.
  2. Game-oriented standard library contract (collections, timers, ECS-adjacent utilities).
  3. Tooling diagnostics spec for frame-cost visibility.
  4. Host API declaration surface aligned with capability and syscall metadata.