Game vision & technical design · Updated October 12, 2026

A whole world.
A few friends.
One more turn.

Valehex is a browser-based strategy game about exploring, settling, and competing on a vibrant spherical planet. The multiplayer prototype supports exploration, settlements, production, and combat. Browser-run AI and offline solo are implemented locally and being prepared for deployment.

Up to 8 players plannedSequential turnsBrowser + Three.jsLearning project
01 / The idea

Familiar strategy. A different world.

Start from the familiar Civilization-style loop: explore, found cities, choose production, grow your territory, and defend it. Play on a globe with continuous geography, rich biomes, mountain ranges, rivers, and oceans. There is no flat map edge.

A living planet

Procedural worlds with forests, grasslands, deserts, tundra, polar regions, hills, and mountains. Geography and resources should make settlement locations and travel routes matter.

Your civilization

Three planned races (Humans, Insects, and Aliens) each cover every role, from workers to a capital unit, and unlock stronger units by building up. A focused technology span keeps the project smaller than a journey through all of human history. See the units and buildings.

Made for friends

Join through a private invitation link. Play free-for-all or in teams such as 2v2v2v2, 4v4, 3v3, or 2v2v2. Optional AI players fill empty seats.

This is a low-cost proof of concept and a shared learning experience, with no current monetization target. Civilization and StarCraft are inspirations; Valehex will use its own identity and artwork.

02 / A match

Explore → found → build → expand

  1. ExploreReveal nearby tiles and find crystal, routes, and good sites for a base.
  2. FoundOn your first turn, your race’s founder makes your first base, free and at once.
  3. Build & trainWorkers put up buildings and improve tiles with farms, mines, and crystal harvesters. Bases and army buildings train units, one at a time, within your supply.
  4. Expand & competeFound more bases at least 3 tiles apart, defend your territory, and pursue the match’s chosen victory condition.

Food, metal, and crystal pay for units and buildings. Supply caps army size, and wild creatures roam the map, so fighting and exploring cost units and players keep rebuilding. Veteran units will earn promotions later. The first costs, yields, and combat values are in the field guide; balance will come from playing.

Three races, tier 1 · October 14, 2026

Every race is playable

Each player picks Humans, Insects, or Aliens (or Random) in the lobby. For now each race has its first tier: its workers, buildings, and first army. Units fight with their own armour, range, and bonus damage, against ground or air. Menus speak each race’s language (Humans train, Insects hatch, Aliens warp in), and every entry has a “?” that opens it in the tech tree.

Humans

Start with a Colonist, 2 Engineers, 20 food, and 30 metal. The Colonist founds a Command Center; later Colonists are trained there. Engineers build Habitats for supply and a Barracks for Marines.

Insects

Start with 3 Foragers, 30 food, and 30 metal. One Forager becomes the Hive, where everything hatches. A Nursery unlocks Swarmers and Queens, and Drifters raise supply. Drifters count as flyers but walk for now.

Aliens

Start with 2 Shapers, 20 food, and 40 metal. A Shaper warps in the Sanctum and stays. Obelisks give supply, and a Portal warps in Vanguards. Alien units and buildings carry shields that soak up damage before their hit points and recharge 2 each turn.

Crystal under every tile

Every land tile holds a little crystal. A crystal harvester yields 1 crystal on an ordinary tile, 2 on a rich deposit (about 6% of land, shown as blue shards breaking through the ground), and 4 on one of the 12 five-sided pentagon vents, plus 1 while a worker tends it. Pentagons in the ocean wait for ships: each race will get a small work boat that builds a platform on them.

Buildings take time

Buildings and improvements take turns to finish and do nothing until then. Farms cost 4 metal, mines 6 (on hills or mountains), and crystal harvesters 10. Supply comes from your bases and your race’s supply source, up to 60.

Stacking, healing and terrain · October 15, 2026

Where a unit stands matters

Room on a tile

Every unit is small, medium or large (1, 2 or 3 points), and a tile holds 3 points of ground units plus 3 of flyers. Your units can walk through a full tile of your own but cannot stop there. Small units such as Marines, Swarmers and Vanguards are drawn as squads of three; a figure falls at two-thirds health and another at one-third, and healing brings them back.

Rest and heal

A unit that neither moves nor attacks heals at the start of your next turn: 33% of its health on your building’s tile, 20% within 2 tiles of one, 10% elsewhere, and nothing within 2 tiles of an enemy building. Rest (the moon button on the unit card) ends its turn at once and marks it with a small moon.

Hills, forests and rivers

A hit does 1 less damage for each advantage the target has: higher ground, standing trees, or a river between. At most 2 less, never below 1, and flyers ignore it. Before you attack, each target shows its damage, such as “4 → 2”, with an icon for each advantage, and rivers are drawn on the planet.

Flyers hover

Flying units float above the ground with a gentle bob, leaning into their turns. A soft shadow and the owner’s coloured ring on the ground under each one show which tile it is on. On a tile with ground units, a flyer hovers behind them so it never hides them. Shots and claws reach up to them, and a destroyed flyer falls out of the air.

Games started before October 14, 2026 were retired with the old rules; nothing carries over. Race abilities such as regeneration, repair, larvae, and power fields, plus tiers 2 and 3 and flying, come in later steps.

Sequential turns, optional queued moves

One player acts at a time. Others may prepare orders while waiting. Queued orders execute only on their owner’s turn and are checked against the current state.

A queued order pauses when the unit sees a new hostile, a hostile moves toward any friendly unit, or the unit sees an attack. Hostiles moving away, known camps, and allied activity don’t interrupt. A paused order waits for its owner and never turns into an attack.

A pace chosen by the lobby

Players vote on turn deadlines, maximum turns, and game-ending conditions. The goal is to support short sessions as well as persistent matches lasting months.

If every unit is fortified or has queued orders, the turn plays itself. By default, the AI plays a timed-out turn for a player who gave no orders. Players can switch on Away so the AI covers for them, then take their seat back; three missed turns in a row turn Away on automatically. Eight-player sequential play will need testing to make short matches practical.

Fog of war and casual play

Current multiplayer sends each player only permitted terrain, units, and events. Planned browser-run AI needs additional simulation data to minimize messages. The UI and AI still respect fog, but an AI executor could inspect hidden information. Read the tradeoff.

Catch up without guessing

Team and global chat support coordination. A visibility-filtered event log explains what happened between turns. Later, a guided replay can move the camera between those events.

03 / Where we are

A playable foundation, with AI integration next

Implemented foundation

  • Seeded spherical terrain, biome textures, animated water, and Worldmaker controls.
  • Multiplayer units, movement, settlements, production, combat, and fog of war.
  • Private invitations, teams, lobby voting, turn deadlines, and saved matches.
  • Lambda game rules and DynamoDB persistence with version checks and request deduplication.
  • Local AI simulations, browser AI workers, validated online action batches, and offline solo saves.
  • Three playable races at tier 1, with supply, build times, crystal, and Alien shields (October 14, 2026).

Still to build

  • Deploy and playtest the browser AI and offline implementation.
  • Fortify, turns that play themselves, AI cover for missed turns, and an Away toggle.
  • Queued-order interruptions.
  • Wild units of every race and combat promotions.
  • Reusable seat links, one compressed snapshot for a new device, and wider mobile testing.
  • Automatic match updates and richer event replay.
  • Tiers 2 and 3, flying, research, and each race’s special abilities, then bots that play each race well.

Implementation status includes local development work, not a deployment guarantee. Browser AI, offline caching, and retry recovery have local tests; they have not been deployed to live matches.

04 / Online architecture

A persistent game without a permanent game process

The browser renders the planet and, in the agreed AI design, chooses bot actions. AWS validates actions and stores authoritative progress. Lambda runs when work arrives, then exits. A months-long match survives in the database while phones are locked and players are away.

Responsibilities
ServiceWhat it does for Valehex
Static hostingAmplify Hosting builds and serves the site on every push to main. Offline mode caches required assets locally.
Custom domain + TLSAmplify Hosting manages the valehex.com certificate; DNS stays in Route 53.
API Gateway + LambdaAuthenticate participants, validate and replay commands, and save results. Planned AI batches avoid repeating browser strategy searches; an authorized AI execution payload is separate from ordinary player views.
DynamoDBStore authoritative match state, versions, seats, orders, and bounded event history. Planned AI integration adds bot memory and batch receipts.
API Gateway WebSocketsOptional future notifications. The current client uses manual refresh; reconnecting clients must fetch authoritative state even if notifications were missed.
EventBridge scheduled ruleThe existing minute worker checks due human turns. AI integration must distinguish pending bot work from human turn deadlines.
CloudWatchCollect structured logs and track action failures, response times, turn processing, and backend health.
What happens when a player moves a unit?
  1. The browser sends an order with a request ID and the match version it knows.
  2. The server verifies the player’s seat, active turn, unit ownership, movement allowance, and legal destination.
  3. The server commits the changes and resulting events with a version check. Duplicate requests must not move the unit twice. DynamoDB supports conditional writes and atomic transactions for this purpose. AWS transaction reference.
  4. Return confirmation only after saving. Other players fetch their own updated view; automatic notifications remain future work.

Rules stay separate from graphics

A shared JavaScript rules module should describe tiles, legal orders, combat, and city production. The server is authoritative. Visual meshes and animations must not determine outcomes.

Ordinary multiplayer views keep the seed and hidden entities on the server. The planned AI execution payload deliberately relaxes that secrecy for casual games. Offline solo uses the same rules with the full state saved locally.

Design for reconnects and retries

Invitation links should exchange a private token for a seat session; credentials must stay out of logs. Persist state and events before notifying clients. Missed notifications are recovered by fetching updates.

Version checks protect against stale requests and scheduled callbacks. The current minute worker provides approximate timeout recovery; commands also enforce stored deadlines. Decided: a seat link signs any new device into that seat. The device gets one compressed snapshot with explored terrain and the latest 20 chat messages, then only changes.

Cost goal: a small, usage-driven backend. Start in one region, send compact updates, cache assets, bound log retention, and monitor spending. This proposal avoids requiring a static public IP or always-on game host. It is not a promise of zero cost: storage, requests, connections, logs, and data transfer still matter. HTTP APIs bill per request in 512 KB increments, so fewer, compressed requests matter more than tiny payloads.

05 / Agreed design · October 8, 2026

Browser AI, durable online progress

Let the browser choose bot actions. Let Lambda verify the consequences and save the match. Reuse the same rules and AI for fully offline solo play.

Implemented locally; deployment pending. Browser workers now support solo saves, offline asset caching, online AI batches, and retry recovery. The protocol uses at most 128 actions per batch. Reusable seat links and broader mobile testing remain future work.

Offline solo

After the code and required assets load, the browser runs map generation, rules, AI, and local saves without gameplay requests. Cache assets for reopening offline and provide save export/import. Cloud saves are optional separate work.

Online multiplayer

Keep Lambda and DynamoDB for validation and durable state. No host browser must stay awake, and peer consensus or blockchain is not required. Phones can disconnect; confirmed progress remains available to other devices.

The previous browser tries; the next browser can finish

  1. Confirm the human turnSave it promptly. Return confirmation, the match version, and any pending AI work without waiting for bot computation.
  2. Compute locallyThe previous player’s browser runs consecutive bot turns in a Web Worker, collecting ordered actions and updated bot memory.
  3. Verify and save onceSubmit a bounded batch. Lambda replays legal actions and atomically saves the result, bot memory, and request receipt.
  4. Resume if neededIf that browser disappears, the next player’s browser completes pending AI before enabling their human turn. With nobody online, AI can wait.
Minimize messages without losing confirmed moves
  • Include pending work and continuation data in existing responses. Avoid a request for each unit movement or a separate reservation protocol.
  • Bind each submission to a unique request ID, starting match version, and rules/AI versions. Authenticate the submitting participant and allow actions only for the expected AI seats.
  • Replay on a working copy, reject invalid batches without partial saves, and commit with a version condition. Duplicate accepted requests return confirmation; stale work returns current state. Two browsers may compute the same turn, but only one result can commit for that version.
  • Bound action count, replay time, and memory. Store bot memory with match progress so another browser can resume. Stop at the next human turn and define deadline handling so pending AI does not consume that human’s time.
  • Persist pending submissions locally, retry with the same ID on reconnect, and distinguish “pending” from “saved.” Never rely on an upload when the player locks their phone. Unreceived actions cannot appear on another device.
  • Batching human plans behind an explicit “Submit turn” is an optional later optimization. Unsubmitted plans remain on that device.

One rules engine, two execution environments

Browser simulation and Lambda replay use deterministic rules, pinned versions, and explicit random state. Graphics do not determine outcomes. Run AI in a Web Worker to keep the interface responsive.

Lambda still calculates movement, combat, production, income, and turn transitions. It skips AI strategy and pathfinding, and never trusts a submitted final state. Measure these costs separately before estimating savings.

The visibility tradeoff

A browser simulating discoveries without repeated server requests needs underlying world state. The simplest casual-mode design provides the authorized executor a full simulation snapshot, excluding credentials and invitation secrets.

The AI receives a fresh fog-filtered view after each action, and the UI still hides unknown areas. Someone inspecting browser data could nevertheless reveal secrets or substitute other legal AI moves. Legality checks cannot prove the intended policy ran. Strong secrecy would require extra exchanges or server-run AI.

Implementation order: share deterministic rules and AI with offline solo; add bounded online batch validation and persisted bot memory; then integrate mobile recovery, cross-device identity, and request/compute measurements.

06 / Build in playable steps

First target: finish one small match

  1. Strategy sandboxMovement, exploration, settlement founding, city production, and resource yields using testable game rules.
  2. Two-player matchPrivate seats, sequential turns, queued moves, saved state, fog of war, and a basic victory condition.
  3. Friends & teamsUp to eight seats, lobby voting, deadlines, chat, and an event log. Integrate browser-run AI batches and offline solo play.
  4. Identity & depthOriginal species, richer 3D cities and units, improved AI, balancing, and event replay.

No release dates are committed. We’ll choose a minimal victory rule before the first match and broaden the design after playtests. Species abilities, research, diplomatic systems, and detailed combat remain design work. The field guide holds the current race proposal.

07 / An invitation

Want to build a piece of this world?

You don’t have to take on the whole game. A small, finished contribution or a thoughtful playtest would help.

Build

JavaScript game rules, a city production interface, AWS infrastructure as code, persistence, automated checks, or turn handling.

Create

Original species concepts, resource artwork, sound, and simple 3D units and cities. Resources can use sprites or small meshes; cities and units should have 3D assets.

Play & challenge

Explore the prototype now. Later, help test map fairness, pacing, combat clarity, resource value, and whether you want to take another turn.

If this sounds interesting, tell the person who shared this page what you’d enjoy working on—or just that you’d like a seat in an early match.

The repository is currently private. Public release under MIT is a possible future step; no project license has been selected yet.