What We Built This Week
Devlog #2 is here, and it covers the two biggest engineering challenges we have tackled since the project began: a real-time 3D galaxy map that can handle hundreds of players simultaneously, and a single-source-of-truth balance system that governs everything from ship stats to market fees. Both systems are live in our internal build and performing better than we hoped.
Let's walk through the work.
The Galaxy Map: Why Three.js, and How We Made It Fast
Early in Starforge's design, we made a deliberate choice to render the galaxy map in 3D rather than the flat 2D hex grids that dominate the browser MMO space. The reason is simple: space is not flat. A 3D map communicates scale, depth, and threat in ways that a 2D grid never can — when you see an enemy fleet moving through the nebula layers toward your sector, you feel it.
We chose Three.js for three reasons. First, it runs in the browser without plugins, which is non-negotiable for us. Second, its scene graph handles the kind of instanced mesh rendering we need for a 20x20 sector grid (400 sectors, each with star bodies, asteroid fields, fleet markers, and fog-of-war overlays) without us having to write raw WebGL. Third, the community is enormous — and we have already found solutions to most of our rendering edge cases in the Three.js GitHub issues.
The hardest technical challenge was hitting 60fps on mid-range hardware with a fully populated galaxy. Our first implementation was straightforward: render every sector, every fleet, every resource node as its own mesh. At 400 sectors with an average of 8 objects each, we were pushing 3,200 draw calls per frame. On a high-end GPU, this was fine. On an integrated Intel GPU — the kind most browser game players actually have — it was unplayable.
The fix was instanced mesh rendering. Instead of 400 individual star sphere objects, we have one InstancedMesh with 400 instances, each with its own transform matrix. Fleet markers use a shared geometry with per-instance colour. The fog-of-war is a single full-screen shader pass rather than 400 individual overlay planes. After these changes, draw calls dropped from 3,200 to under 80, and we now hold 60fps consistently on Intel Iris Xe graphics.
We also implemented level-of-detail (LOD) switching: when you zoom out to a full galaxy view, ships render as simple billboarded sprites. When you zoom into a sector, they swap to full 3D models. The transition is imperceptible at normal zoom speeds and saves enormous GPU bandwidth at the strategic view level.
The Balance System: One File to Rule Them All
Every live game studio has a balance nightmare story. Usually it starts with someone editing a damage value in the client code, forgetting to update the server, and shipping a patch where a ship does double damage on the frontend and the correct damage on the backend. We built balance.json specifically to prevent that class of bug from ever existing in Starforge.
balance.json is our single source of truth. Every number that affects gameplay — ship base stats, weapon type multipliers, resource production formulas, market fees, tech research costs, newbie protection thresholds — lives in one file, checked into the repository. The build pipeline exports it in two directions: to the Next.js frontend (so the calculator tools and wiki pages show accurate numbers) and to the game server (so combat resolution uses identical values to what the UI displays).
This approach has already paid off twice. When a playtester reported that the combat calculator showed different results than the actual battles, we traced it to a single field in balance.json that had been updated in one branch but not merged. With a flat file as the source, the fix was a one-line merge. In a traditional split-value system, we would have hunted through server code and client code separately.
The balance.json schema is versioned: every export includes a schemaVersion field. When the server loads its config, it checks that the schema version matches what it expects. If it doesn't, it refuses to start and logs a clear error. This means stale balance data can never silently go live.
Economy Design Philosophy: Why 5% Market Fee Burn
The Galactic Market is player-driven — all prices are set by supply and demand, and there is no NPC store to fall back on. This is intentional, but it creates a known problem: hyperinflation. In a game where resources are constantly produced and credits accumulate, prices eventually reach numbers that make no intuitive sense to new players.
Our solution is a 5% market fee burn. Every transaction on the Galactic Market charges the seller 5% of the sale value, and that credit is destroyed — removed from the economy entirely. We modelled this in a spreadsheet before writing a single line of game code. The model simulated 10,000 players at various activity levels over 90 days, tracking total credits in circulation, average prices for key commodities (Metal, Crystal, Gas), and the Gini coefficient of wealth distribution.
The 5% burn rate was the sweet spot: enough to create meaningful credit sinks that counteract production, not so high that it punishes legitimate traders. At 3%, our model showed runaway inflation starting around day 45. At 8%, trading volume collapsed because margins were too thin for arbitrage routes to be worth the effort.
We also designed event-based demand spikes into the economy. Boss raid weekends require large quantities of Antimatter, which is only produced in outer-sector asteroid fields. This creates natural price events that traders can anticipate and position for — the kind of emergent market behaviour that makes player-driven economies interesting.
What's Next: Beta Invitations and Discord Launch
We are sending out the first wave of closed beta invitations next week. If you signed up on the waitlist, check your inbox — we are starting with 500 players across all four factions, intentionally balanced to stress-test both the faction PvP system and the early-game economy.
The Starforge Discord server launches alongside the first beta wave. This is where dev updates will live going forward, including balance patch notes, bug report channels, and direct access to the development team. The invite link will be shared with waitlist members first before we open it publicly.
Thank you for following the build. Every comment and question from the community shapes what we prioritise — keep them coming.
— Starforge Team