Stock Arena

Inspiration

What if a fighting game had a stock market bolted onto it — where every fighter is a tradeable asset whose price swings on how they actually perform in the ring? Stock Arena began as a content experiment (auto-generated stick-figure battle clips) and grew into a full ecosystem: watch the fights, trade the fighters, and now step into the arena yourself.

What it does

Stock Arena is three things sharing one universe and one deterministic engine:

The clips — a seeded engine stages stick-figure "GAME" bouts and renders them straight to vertical video for socials. Same seed → same fight, always.
The market — a trading site (arena.seocubo.com) where fans buy and sell fighter "stocks" with points; prices move on real fight results, upsets pay multipliers, and shareholders vote on the loadouts fighters carry into their next match.
Arena: Ascent — the mobile roguelite (our Shipaton app). A one-thumb survivor-arena: drag to dodge, auto-attack the waves, and draft a new power every level, with a boss — a real roster fighter — every tenth wave. Between runs your ship voyages across a space map, banking Cores every minute even while the game is closed; optional SPACE-TIME rift fights and a HYPER WARP auto-shmup shave the trip. Play FOREVER (persistent) or ALL-IN (hardcore permadeath). Sign in with Google to climb leaderboards and fight async, deterministic PvP duels against other players' builds — or match-code a friend. Ad-light (opt-in rewarded ads only, no interstitials) with a RevenueCat "Remove Ads" upgrade.

How we built it

Engine: Godot 4 / GDScript, fully deterministic (seeded RNG), with a JS twin for the browser prototype — one engine drives the clips, the simulations, and the game.
Video pipeline: Godot Movie Maker renders offline → FFmpeg transcodes to 1080×1920 H.264, batched by a Python orchestrator.
Web: Next.js + TypeScript + Tailwind on Vercel, Upstash Redis for live market and portfolio state.
Mobile: one shared arena scene reused for normal runs, boss fights, live PvP duels, and the rift — reframed by state, not four codebases. A self-hosted Nakama backend powers Google sign-in, leaderboards, and the PvP loadout pool (duels stay fair via the deterministic engine — both players resolve the same seeded bout locally). AdMob rewarded ads (revive + warp overdrive; no interstitials) behind a GDPR/UMP consent flow, and RevenueCat for the Remove-Ads entitlement.

Challenges we ran into

Keeping the engine byte-for-byte deterministic across GDScript and JS so the site, the clips, and the game never disagree on who won.
An offline, CLI-driven render pipeline that batches — including a Windows ffmpeg command-length limit when a 14-fighter free-for-all fired 300+ synced sound effects.
Making one arena scene serve four contexts — normal runs, boss fights, live PvP, and the rift — sharing progression while each reads as its own thing. And matchmaking two players can actually hit: our first PvP pass needed both to tap within the same second, so we moved to a live search window with an on-screen timer and cancel.
Play compliance for ads (AD_ID, data safety, content rating, a published UMP consent message for EEA users), and bringing RevenueCat into a Godot app (no official SDK) for the purchase.

What we learned

Determinism is a feature: once the same seed always produces the same fight, everything downstream — clips, a live market, a playable game, a bracket — can trust one source of truth. A content pipeline and a game can share one engine. And ad-reward flows have to be tested on-device: desktop stubs fire synchronously and hide the exact races that break real reviving and purchases.

What's next

Season 2 playoffs as a live bracket on the site (Season 2 is already done), more arenas, a deeper idle voyage (offline earnings, prestige), PvP seasons and match-code tournaments off the deterministic engine, and wiring live PvP + arena results back into the market.