Skip to main content

Bring an Existing Game to Arcadible

This guide publishes a game you've already built. Arcadible needs two things from it: a folder with an index.html that runs the game, and an arcadible.toml. Your code, engine, and build stay as they are. For a new game, start with Getting Started instead.

Add a manifest​

Install the CLI and log in, as in Getting Started, then run arc init in the game's directory:

cd my-game
arc init

In a directory that exists, arc init doesn't copy a template. It creates arcadible.toml if there isn't one, and gives it a game id. It also adds a version, unless your package.json has one, which Arcadible uses instead. Commit arcadible.toml, and never change its id.

Tell Arcadible how to build it​

Tell Arcadible the folder your build writes, and, if package.json doesn't build it, the command that does. A Vite project needs only the folder, since its build script runs as npm run build, and relative paths:

arcadible.toml
[workflow]
deploy_dir = "dist"    # contains index.html
vite.config.js
export default { base: "./" }; // relative paths
  • build runs before every deploy, and before arc serve. Without it, a project with a build script in package.json builds with npm run build. Set it for anything else, such as build = "./build.sh", leave it out if your game has no build step, or set build = "" to skip package.json's.
  • deploy_dir is the folder with your index.html, which players load. It defaults to .arcadible-public.

For an engine's web export, such as Godot's, see Game Engines. Then check the result:

arc build       # runs the build, and says if deploy_dir is missing
arc validate    # checks everything arc deploy will
arc serve       # plays the build locally, as Arcadible runs it

Describe it​

Your store page comes from your project's files, so most of it can come from what you already have:

  • README.md: its # heading becomes the title, and a ## heading right after it becomes the tagline, so a README that starts # My Game then ## Installation gets "Installation" as its tagline, and fails arc validate until its description is between two --- rules. Either shape the README for the store (title, ## tagline, one-line bio, then the description between two --- rules; anything after the last rule isn't shown), or leave it as it is and put the store page in an arcadible.md, which Arcadible reads instead. See Arcadible Markdown.
  • .arcadible/: add the icon, cover, banner, poster, and splash, and screenshots in .arcadible/gallery/. See Your Store Page.
  • arcadible.toml: add a handle, genres, and the inputs and orientation your game supports.

Only id and version are required to deploy, so you can fill these in while you test.

Deploy to staging​

Deploy a prerelease version, such as 1.0.0-beta.1, so the first build goes to staging instead of to players. It's version in package.json when you have one, and in arcadible.toml otherwise. A version that arc init added is already one, 0.1.0-beta.1. A release version goes straight to production:

arc deploy
arc play

0.0.0 is a release version. Tools such as create-vite write it, so deploying the project as it is sends its first build straight to players. Change version to a prerelease, such as 0.1.0-beta.1, before you deploy.

Fix what the first deploy finds​

A game that runs on your machine can fail in the Arcadible sandbox: case-sensitive file names, client-side routes, assets from other servers, precompressed builds, blocked dialogs, and saves kept in browser storage are the usual causes. Run arc serve to find most of them on your machine, play the staging build, and work through My game works locally, but not on Arcadible, which has each one and its fix.

Fix them, bump the prerelease, and deploy again.

Release it​

Set a release version, such as 1.0.0, and deploy. The game is unlisted until you set visibility = "public"; see Going Public.

Next steps​