Platty Game indev (RELEASE!)

Introduction

We shipped the indev release of Platty today. This is not a wrapper around C++, nor is it a script injection layer bolted onto an existing engine. Platty is a standalone, ahead-of-time compiled language targeting native x64, ARM, and WebAssembly, built explicitly for deterministic simulation and high-throughput game loops.

The indev milestone marks a stable compiler pipeline, a production-ready runtime, and full Entity Component System (ECS) graph validation at compile time. If your engine suffers from garbage collection pauses, cache thrashing during entity iteration, or race conditions in parallel system execution, Platty addresses these constraints at the language level. We designed Platty to treat memory layout and concurrency as first-class compile-time guarantees, eliminating the impedance mismatch between game logic and hardware execution models.

Why This Matters

Game engines operate under strict real-time constraints. A single frame must complete within a fixed budget (e.g., 16.6ms for 60fps) regardless of input variance. Traditional languages force developers to manage these constraints manually: C++ requires meticulous pointer discipline and custom allocators, while managed languages like C# or Java introduce non-deterministic pauses from garbage collection.

Platty solves this by baking arena-based memory management, lock-free task scheduling, and data-oriented access patterns directly into the type system. The compiler rejects code that violates cache-friendly iteration rules or introduces hidden heap allocations in the hot path. This matters because hit-rate consistency in multiplayer games, simulation determinism for rollback netcode, and frame-time stability in AAA titles depend on eliminating unpredictable runtime overhead. Platty shifts these failures from runtime crashes to compile-time errors.

How It Works

Platty compiles source code through a multi-stage pipeline that validates architectural constraints before generating machine code. The core mechanism revolves around the ECS Constraint Solver, which analyzes component access patterns and builds a static execution graph.

flowchart TD
    A[Source Code .plt] --> B[Lexer & Parser]
    B --> C[AST with ECS Annotations]
    C --> D[Constraint Solver]
    D --> E[Platty IR]
    E --> F[Data-Parallel Optimizer]
    F --> G[LLVM Backend]
    G --> H[Native Binary / WASM]
    H --> I[Platty Runtime]
    I --> J[Arena Allocator]
    I --> K[ECS Graph Executor]
    I --> L[Lock-Free Task Queue]
    J --> M[Frame Loop]
    K --> M
    L --> M

The pipeline operates as follows:

1. Lexer & Parser: Ingests .plt files and produces an AST annotated with component metadata, system boundaries, and lifetime scopes.
2. Constraint Solver: Validates that systems only access disjoint component sets unless explicit synchronization markers are present. It detects potential cache contention and rejects overlapping mutable access patterns.
3. Platty IR: Transforms the AST into an intermediate representation optimized for data-parallel execution. Systems are lowered into vectorizable loops with explicit stride calculations.
4. Data-Parallel Optimizer: Applies auto-vectorization, loop unrolling, and graph scheduling optimizations. It reorders system execution to maximize CPU pipeline utilization and minimize branch mispredictions.
5. LLVM Backend: Emits optimized machine code or WebAssembly. The backend integrates with LLVM’s pass manager but adds Platty-specific passes for arena boundary checks and deterministic floating-point enforcement.
6. Runtime: The Platty runtime manages the Arena Allocator, ECS Graph Executor, and Lock-Free Task Queue. These components coordinate to execute the frame loop with zero dynamic heap allocation.

Core Concepts

Platty introduces three fundamental abstractions that govern game architecture:

• Arena Scopes: Memory is partitioned into frame-scoped arenas. Allocations within a scope are freed atomically when the scope exits. The compiler enforces that no references escape the arena boundary, preventing dangling pointers and eliminating manual deallocation.
• System Graphs: Game logic is organized into systems that operate over component queries. The compiler builds a directed acyclic graph (DAG) of system dependencies. Systems without data dependencies execute in parallel across available cores.
• Query Composition: Queries specify component access modes (& for read, &mut for write). The constraint solver validates that no two parallel systems mutate the same component set. This guarantees thread safety without locks.

Examples & Code Walkthrough

The following examples demonstrate Platty’s syntax and architectural guarantees. Code is written for the indev release and compiles with plattyc.

Defining Components and Systems

Components are plain data structures. Systems are pure functions that operate over queries.

// Components must be trivially copyable and lack internal pointers
struct Position {
    x: f32,
    y: f32
}

struct Velocity {
    dx: f32,
    dy: f32
}

struct Gravity {
    strength: f32
}

// Systems are compiled into vectorized loops
// The compiler validates disjoint access across parallel systems
system UpdatePhysics(query q: Position & Velocity & Gravity) {
    // q.len() is optimized to a register load
    for i in 0..q.len() {
        // Direct pointer arithmetic bypasses virtual dispatch
        let pos = &q.position[i]
        let vel = &q.velocity[i]
        let grav = &q.gravity[i