107 lines
4.3 KiB
Markdown
107 lines
4.3 KiB
Markdown
# 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.
|