Carlos Rivera

Posted on Aug 27

I Built an AI Game Arcade with Vanilla JavaScript and Zero Build Steps

#javascript #ai #webdev #gamedev

GLM 5.3 Flash is out, so I wanted to test it by building something practical instead of another isolated code sample.

I made an arcade.

Arcade Vault is a small collection of playable browser games generated and developed as experiments with affordable AI models.

The first two cartridges

GRAVPULSE 2097

A 3D anti-gravity racer set on neon city circuits.

Play GRAVPULSE 2097

DUNESWEEPER

A procedural voxel archaeological minesweeper game where you excavate ruins, avoid traps, and search for relics.

Play DUNESWEEPER

Why vanilla JavaScript?

I deliberately kept the project simple:

No build step
Native ES modules
HTML, CSS, and JavaScript
Minimal dependencies
Shared libraries stored in the repository
Static hosting through GitHub Pages

The goal was to make every game immediately inspectable and playable. Clone the repository, open a static server, and the project runs.

There is no compilation pipeline between an idea and a playable experiment.

The architecture

The arcade has a small registry:

{
  "id": "gravpulse",
  "title": "GRAVPULSE 2097",
  "path": "games/gravpulse/index.html"
}

The main page loads games.json, creates a cartridge card, and points it to the corresponding game directory.
Each game is self-contained:

games/
├── gravpulse/
│   ├── index.html
│   └── src/
└── dunesweeper/
    ├── index.html
    └── src/

Shared utilities live outside the game folders, including the common “eject” button that returns players to the arcade.

This structure is intentionally boring. That is a feature.

The longer-term idea

Eventually, I would love to add a chatbox directly to the arcade. The experience I have in mind is something like:

“Create a small underwater game where I control a submarine and collect lost treasure.”

The chatbox would generate a new game module, add it to the registry, and make it playable directly in the browser.

Keeping the project build-free and dependency-light should make that kind of workflow easier to reason about. The generated output could remain close to the source instead of disappearing behind a large toolchain.

More cartridges are coming

I will probably keep adding games as new affordable models arrive.

Each model becomes another creative and technical test:

What kinds of game loops can it create?
How well does it handle state and input?
Can it produce maintainable browser code?
How much can be generated before human refinement becomes necessary?

For now, the arcade is small, but the foundation is there.

If you try either game, I would love to hear what breaks, what feels fun, and what should become the next cartridge.

DEV Community