Steal This Fucking Source Code — Because gaming deserves better.
v0.3.5 Alpha —
The gaming industry has a problem. Bloated engines. Lazy optimization. "Good enough" performance. The result? Games that stutter, overheat devices, and frustrate players into piracy. STFSC exists because optimization and attention to detail shouldn't be optional—they should be the foundation.
This engine is built from the ground up for one audacious goal: open-world gaming on standalone VR hardware, pushing the Quest 3's 2.4 TFLOPS to its absolute limits.
"They said it couldn't be done. We're doing it anyway."
MIT licensed. Take it, ship with it, sell what you build with it.
This repository is the engine. Clone it, build it, run it, and build your own game with it: it compiles, tests and runs with no game content on disk.
git clone https://github.com/necat101/stfsc
cd stfsc
cargo run --release --bin editor # the authoring editor| Included | Not included |
|---|---|
src/ — renderer, physics, audio, ECS, scripting, editor, export tools |
Game projects (projects/<name>/: assets, scenes, items, scripts, UI) |
android_host/ — the Quest/phone APK host package |
Game client packages (projects/<name>_client/) |
docs/, engine build scripts, sample scenes/ |
Game servers and packaged builds (avx2/) |
Games live in projects/<name>/ and are versioned privately by whoever makes
them; the engine ships no content of its own and depends on none. Games register
a normal cargo package as their client, and the exporter builds whatever a
project's project.json declares. docs/ENGINE_GAME_BOUNDARY.md is the map:
the export contract, how a project declares its runtime, and how the engine is
kept free of any single game's material.
The fastest way to check that boundary still holds after a change:
scripts/verify_engine_standalone.sh --run-testsIt stages exactly the published engine file set in a scratch directory and runs
cargo there, so a game dependency that only exists on a developer machine fails
the check instead of shipping. scripts/publish_engine.sh stages the same file
set into a fresh public snapshot and verifies it before it can be pushed.
STFSC is being shaped for ambitious open-world games that need smooth simulation under pressure. The first game built on it is Twighlight, a Rust/Minecraft-like survival sandbox with seeded procedural worlds, object-based building, day/night danger, survival play, and god-mode creation tools. It is developed and versioned privately on top of this engine, so its project root (projects/twighlight/) is not part of this repository.
- Engine source and shared tooling stay at the repository root.
- Game projects live under
projects/<project-name>/, like Unity-style project folders. - Each project owns its own
project.json, scene JSON, UI scene JSON, FuckScript source files, generated assets, and third-party asset folders.
The engine still keeps its 556-class goals: dense city streaming, vehicles, crowds, multiplayer-ready architecture, and standalone VR performance. Sandbox support is an added optimization profile, not a narrowing of the engine.
- Parallel Render Prep: Frustum culling, matrix math, and instancing batching now distributed across all CPU cores.
- Physics-to-ECS Sync: Multi-threaded updates from Rapier3D back to world transforms.
- Parallel AI Logic: High-density NPC (CrowdAgent) and Vehicle AI processed in parallel.
- Thread-safe Streaming: Procedural city chunk generation is multi-threaded for stutter-free travel.
- Full Undo/Redo System: All major operations (spawn, delete, move, properties) are tracked and reversible.
- Persistent Asset Pipeline: Automatic texture ingestion into
assets/textures/for project portability. - Real-time Material Sync: Instant inspection/tweaking of PBR properties and textures on Quest 3 without re-spawning.
- Missing Asset Diagnostics: Built-in warnings for missing project files with easy re-linking guidance.
- Parallel Viewport Prep: Smooth editor UI performance via multi-threaded viewport projection math.
- Seeded Chunk Planning: deterministic sandbox chunk plans for trees, resources, mobs, and build budgets.
- Survival/God Mode Rules: project metadata can distinguish resource-constrained survival from free-building creative play.
- Day/Night Runtime Clock: sandbox-aware clock hooks for hostile night spawning, lighting, and scripts.
- Parallel Planning Windows: chunk plan generation uses Rayon so wide sandbox worlds can stream without blocking the frame.
- Vulkan-based renderer with multiview stereo rendering
- PBR lighting pipeline with shadow mapping (PCF soft shadows)
- Reversed-Z depth buffer for maximum precision on large world scales (556 Downtown scale)
- Application Space Warp (AppSW) support for 36fps→72Hz upscaling
- Dynamic Lights (Point, Spot, Directional) with PCF Shadows and parallel UBO updates
- Instanced rendering with batched draw calls
- Rapier3D integration for high-performance rigid body dynamics
- Collision detection with scriptable event callbacks
- Static & dynamic bodies with configurable shapes
- 3D Spatial Audio with distance attenuation
- Multiple attenuation models (Inverse, Linear, Exponential)
- Streaming audio support for ambient sounds
- Native Rust scripting via
FuckScripttrait - Editable source export compiler: cache-mode FuckScript sources are parsed and generated as native Rust during export; no runtime interpreter is used in the game loop
- Lifecycle hooks:
on_awake,on_start,on_update,on_enable,on_disable,on_destroy - Fixed/late update hooks for physics-step logic and post-update pose following
- Collision callbacks:
on_collision_start,on_collision_stay,on_collision_end,on_trigger_start,on_trigger_stay,on_trigger_end - XR callbacks and helpers: HMD/controller poses, abstract actions, edge events, and haptic requests through
ScriptContext - Built-in scripts: CrowdAgent, PoliceAgent, TrafficAI, EnemyTracker, VehicleAI, WeaponNPC, HeadAnchor, LeftHandAnchor, RightHandAnchor, TriggerHaptics
- Entity Component System (ECS) via
hecs - Runtime Task Graph for dependency-aware parallel frame work across simulation, physics, render prep, streaming, networking, and maintenance systems
- Frame Budget Pressure Controls for deferring non-critical jobs when a platform is close to missing frame time
- Platform-tuned async runtime so desktop and standalone VR builds size networking/blocking worker pools from the same concurrency profile
- LOD system with distance-based mesh switching
- Async Resource Loading for background mesh uploads (No ANRs)
| Component | Technology |
|---|---|
| Language | Rust 🦀 |
| Graphics API | Vulkan 1.1+ |
| XR Runtime | OpenXR |
| Physics | Rapier3D |
| Parallelism | Rayon |
| ECS | hecs |
| Target Platform | Meta Quest 3 / Quest 3S |
Desktop (Windows / Linux)
- Rust 1.84+ via
rustup(MSVC toolchain on Windows) - A Vulkan 1.1+ driver
- Linux also needs
libasound2-devplus the X11/Wayland dev packages;.github/workflows/rust.ymlinstalls the exact list
Quest / Android (optional)
rustup target add aarch64-linux-android- Android NDK r27+ (
ANDROID_NDK_HOME) and an SDK with build-tools (ANDROID_HOME) cargo install cargo-apk
cargo build --locked --release --bin editor # authoring editor
cargo build --locked --release --bin stfsc_export # project exporter (the editor uses it too)
cargo run --release --bin editorbuild_linux.sh, build_engine.sh and build_all.sh wrap the same engine
builds; build_windows.ps1 / run_windows.ps1 are the PowerShell equivalents.
The engine's tests run with cargo test --locked --all-targets.
cargo apk build --release --lib --manifest-path android_host/Cargo.toml --target-dir android_host/target
adb install -r android_host/target/release/apk/stfsc_engine.apk
adb shell am start -n com.stfsc.engine/android.app.NativeActivityandroid_host is a package of its own: it declares the NativeActivity/OpenXR
entry point, the Android application metadata and the directory the exporter
stages an exported bundle into. An exported APK carries a project's scene,
assets and generated script bindings; a live editor connection is only needed
when you want a real-time debug push to a connected headset. build_quest.sh
runs the same build from a Linux/macOS shell.
For development and testing without a Quest headset:
cargo run --release --bin editorcargo run on its own opens the editor too (default-run = "editor"). The
engine ships no game client of its own, so the editor's embedded Scene viewport
is the local player; a game brings its own client binary and names it in
project.json, and the exporter builds that instead.
- Run the editor on your development machine:
cargo run --bin editor
- Use the embedded Scene viewport as the default local player.
- For Quest real-time debugging, connect the headset over ADB, refresh the Player / Push panel, then connect Quest Push.
- For desktop runtime debugging, start the runtime separately and use Connect Debug Push.
| Metric | Target | Status |
|---|---|---|
| Frame Rate | 72 Hz (36 fps + AppSW) | ✅ Achieved |
| GPU Utilization | <80% | ✅ ~18% idle scene |
| Memory Budget | <500 MB | ✅ ~115 MB |
| Draw Calls | Batched/Instanced | ✅ Implemented |
| Stale Frames | 0 | ✅ Achieved |
- Dynamic lighting & 3D Audio
- Parallel Resource Loading
- Physics integration (Rapier3D)
- NPC AI framework (FuckScript)
- Full Parallel Core (Rendering, Physics Sync, AI)
- Undo/Redo System for Editor
- Robust Asset Persistence (Local textures, Search fallbacks)
- Real-time Material live-sync
- Persistent sandbox save/load state
- Object-based building placement and stability hooks
- Resource inventory and crafting interfaces
- Mob spawn scheduler and night threat director
- Navmesh/pathfinding support for mobs and NPCs
- Multiplayer netcode foundation
- GPU-side occlusion culling (Hi-Z)
- Compressed texture streaming (KTX2/ASTC)
- Complete open-world streaming for sandbox and city profiles
- Full multiplayer gameplay foundation
- Performance parity with consoles
Steal this fucking source code. Seriously.
If you're building a game and struggling with VR performance, take what you need. Learn from it. Improve on it. The goal isn't to hoard knowledge—it's to prove that optimized, ambitious games are possible on mobile VR.
Piracy exists because players don't feel games are worth the price. The solution isn't more DRM—it's making games so good, so polished, so clearly crafted with care that players want to support them.
MIT — see LICENSE. Use the engine commercially, modify it, ship it inside a closed-source game; keep the copyright notice and you are done.
Game content built with the engine — a projects/<name>/ folder, its client
package and its server — is separate work and is not licensed here.
Built with obsessive optimization for standalone VR gaming.
STFSC Engine — Steal This Fucking Source Code