Elsewhere: a small world with a little help

I’m building Elsewhere, a low-poly browser game with animals, procedural animation, music, and a world you can wander around in.

The next idea is fairly small: what if you could stop somewhere in that world and get a little help?

Ask a question. Get a short explanation. Work out the next step on something you’re doing. Then carry on playing.

That’s the direction I want to explore with Codex. A lightweight connection that makes a character useful without turning the whole game into a complicated work interface.

There are two parts to this idea.

One is the game repository itself. Working with the repo in Codex gives the development work a concrete home: the code, dialogue, interaction rules, and the parts that need testing. The open-source direction matters here because other people could eventually inspect those pieces, change them, and build their own version.

The repository is private today. Making it available as open source is a direction for the project, not something I’m claiming is already done.

The other part is what a player might experience inside the game. That could be a short text conversation with a character: help understanding something, a few suggestions for a simple task, or a small action that the game explicitly supports.

The current conversations are manual or scripted. A live Codex-backed conversation is still something to build and verify.

I want to keep that scope narrow. There’s no video or image processing goal here. Just text, small requests, and responses that fit naturally into the game.

For example, a player could ask a character to explain an unfamiliar term or help break a task into a few steps. If a response needs to affect the game, it should come back as a limited, structured action that the game code checks before doing anything.

A character suggesting an action shouldn’t be enough to execute it. The game needs to decide whether that action exists, whether the inputs are valid, and whether it is allowed in the current situation. Dialogue should never become a route to arbitrary execution in the repository.

That’s where most of the useful engineering would be.

Keep the information sent with each request limited. Put limits on response size. Handle timeouts. Have ordinary fallback dialogue ready when the connection fails. Let the player cancel, close the conversation, or continue without AI.

Anything that changes something outside the game would need clear user control and the appropriate confirmation. These are design requirements to implement and test, not a promise that connecting a model automatically makes a system safe.

There’s also an important distinction around accounts. CFE is independent of OpenAI. Its current ChatGPT sign-in identifies the user; it does not establish that a subscription can fund these game conversations. That integration and its access model still need verification.

For now, Elsewhere is a game and a place to try this idea carefully.

The next useful version could be modest: a character that answers a short question well, helps with one small task, and handles a failed request without interrupting the world around it.

That’s the kind of little help I want to explore.