What OneJS Play Is

A catalog of small games you can play, read, and open in Unity

play.onejs.com is a catalog of small games. Every one of them runs in the browser and shows you its source, and most can be forked or downloaded as a Unity project that builds. An author shipping art they did not make can turn copying off, which leaves reading and playing untouched.

Games are written in the same React and TypeScript you would use for any OneJS app, against a package called oj.

import { View, Text, mount, useFrame, input } from "oj"

function Game() {
    useFrame(() => {
        if (input.keyboard.wasKeyPressed("Space")) jump()
    })
    return <View><Text>hello</Text></View>
}

mount(<Game />)

No CS.*, no build configuration, and no root plumbing. mount() already knows where to render.

A game is a bundle, not a build

This is the one fact the rest of the platform follows from.

The game engine and the OneJS runtime are one shared container, served to every game on the site and cached for a year. A game is the JavaScript that runs inside it, usually a few kilobytes rather than the tens of megabytes a game engine normally ships as.

Three things fall out of that:

• Games start on their own. The container is one download per visit rather than one per game, so there is nothing to click through.
• Publishing is a build on the server. You send source, the site compiles it, and a failed compile changes nothing.
• Forking means something. What you fork is the actual source of the game you just played, not a description of it.

Each game gets its own origin

Games are served from *.onejsusercontent.com, a different registrable domain from the site itself, one label per game. That boundary is the reason a stranger's game can run in your browser at all: it cannot reach the site's cookies, and it cannot reach another game's storage.

You do not have to do anything about this. It is worth knowing because it explains a few things that would otherwise look arbitrary, like a game not being able to read its own id.

You are not in a walled garden

oj, the package a game imports, is a strict subset of OneJS: everything in it also works in a normal Unity project. That is a rule the runtime is held to rather than an aspiration.

So nothing you learn here is thrown away. When a game outgrows the sandbox, opening it in Unity is copy the file in, npm i, build, and that page covers what changes and what you gain.

Making one

Playing a game, reading its source, and opening it in the editor to change it and run it are open to everyone, with no account.

Signing in is what lets you keep something: creating a game, forking one, and saving your work. It also bookmarks the games you want to find again. Every signed-in account gets 1 GB of storage, and verifying a OneJS purchase from the Unity Asset Store with your invoice number doubles that to 2 GB. Verification is not a door: it changes how much you can store, not what you are allowed to do.

/new asks for a name, publishes a starter game, and opens the editor on it, so the first thing you see is your own game already running.

Where to go next

Start with Writing a Game if you want to make something, or Elements and Styling if you have already forked one and want to know what the code in front of you is doing.