Hiranya Agarwal

Project 05 of 06 / Interactive software

Sculpt Showdown

A multiplayer voxel sculpting game that runs in a browser tab, with sculpting tools written for this game rather than borrowed from a general purpose editor.

Medium
Browser game
Rendering
Three.js
Period
2026 to now
Status
Single player works, multiplayer on a local transport
The Sculpt Showdown title screen: a voxel castle island floating in the sky with buttons to play a round, free build or start a multiplayer test.
The islandThe title screen. Every block of the castle was placed in the game's own tools.

The product

Make 3D creation immediate, competitive and shareable.

Most 3D tools ask for an install, an account and an afternoon before anything appears on screen. Sculpt Showdown aims to put several people in the same scene from a link, with a short round on one prompt and a shared reveal at the end. The interaction model is the product, so it is the part I built from scratch.

A round in progress with the prompt Knight in pajamas and a timer at 4:33, a pink and blue voxel sculpture on the plaza, the tool rail on the left and the colour palette on the right.
A round in progressFive minutes, one prompt (Knight in pajamas, this time), seven tools down the left, a round or block brush, and a palette of 64 colours.

Technical stack

A short path from code to public playtest.

  1. TypeScriptApplication and game logic with typed interfaces.
  2. Three.jsBrowser based 3D scene and rendering.
  3. ViteDevelopment server and production build pipeline.
  4. Cloudflare PagesPreview deployment and web delivery.

Engineering focus

Build the tooling underneath the experience.

  1. Stay browser native. Three.js keeps the game one link away, which is the whole point of a short competitive round.
  2. Write the voxel tools for this game. The sculpting model is built around how a round actually plays rather than around a generic editor.
  3. Ship continuously. Vite and Cloudflare Pages keep the build and deploy loop short enough to test an idea the same day.
  4. Prove the protocol before the network. One player is the authority. Each player owns a private plot, commits edits as a batch of index and colour pairs, and the host validates ownership, ordering, bounds and time remaining before applying them. Camera and tool state is never sent. Running that over tabs of one browser first means the rules are already right when a real transport replaces it.
  5. Polish before scale. Visual quality comes first, so the first public playtest is judged on the game rather than on the rendering.

Current status

The current build is in visual polish. Multiplayer runs today across several tabs of one browser, on a deliberately dependency free transport that proves the room and edit protocol before any network is added. Internet transport, accounts and matchmaking are not built yet, so there is no public playtest URL and no player numbers to report.