Welcome to the first official Starforge MMO development log. If you've been following the project from the early concept posts, thank you for your patience — things are moving faster than we anticipated, and we're excited to share what's been built. If this is your first time hearing about Starforge, welcome: this is a browser-based space MMO that runs entirely without a client download, featuring a real-time 3D galaxy map and persistent multiplayer simulation. Yes, all in a browser tab.
Why We're Building This
The space MMO genre has a problem. The great ones — the games with real depth, real player-driven economies, real territorial warfare — require massive client downloads, dedicated hardware, and years of onboarding time before you can meaningfully participate. We wanted to build something that captures the strategic depth of those games while lowering the barrier to entry to zero. Open a browser, pick a faction, and you're in the galaxy within two minutes.
The persistent MMO format in a browser has been attempted before, but never with the visual fidelity and real-time simulation depth we're targeting. That's the gap we're building Starforge to fill.
Tech Stack: The Decisions That Shaped Everything
The stack choice was the most consequential early decision. We evaluated three architectures before settling on our current approach.
Frontend: Next.js 14 with TypeScript. Next.js gives us the App Router for clean page structure, server components for SEO-critical content like this blog and the landing pages, and a solid foundation for the static marketing layer. TypeScript across the board — no exceptions.
3D Galaxy Map: Three.js. The real-time galaxy map is rendered using Three.js with custom GLSL shaders for nebula effects, star particle systems, and fleet movement trails. Three.js has a steep learning curve for anything beyond basic scenes, but it gives us the raw control we need for performance optimisation at scale — rendering thousands of star systems with smooth interaction on mid-range hardware requires careful management of draw calls, LOD systems, and geometry instancing.
Backend: FastAPI (Python). The game simulation server runs on FastAPI. We chose Python for the backend because our simulation logic involves complex mathematical models for fleet combat resolution, resource production curves, and market price algorithms — Python's scientific computing ecosystem (NumPy, SciPy) gives us tools that don't exist in other backend ecosystems. FastAPI's async support handles the concurrent WebSocket connections required for real-time galaxy map updates.
Real-time Layer: WebSockets. Fleet movements, battle events, market price changes, and sector capture notifications are all pushed via WebSocket connections. We're using a Redis pub/sub architecture behind the scenes to fan out events to connected clients without hitting the main database on every update.
The Static + 3D Architecture Decision
The most interesting architectural choice was separating the experience into two layers: a pure static layer for everything except the live game, and a Three.js 3D layer for the galaxy map itself.
The landing page, blog, faction guides, leaderboards, and player profiles are all statically generated at build time. They're fast, SEO-friendly, and deployable to a CDN edge network. No server round-trip for content that doesn't change in real time.
The moment a player logs in and opens the galaxy map, a Three.js scene mounts and WebSocket connections open. The 3D layer is completely isolated from the static layer — it's essentially a client-side application that bootstraps inside the Next.js shell. This separation means the static content loads instantly everywhere in the world (edge-cached CDN delivery), while the game client loads only for authenticated players who need it.
The performance difference is significant. First-contentful paint on the landing page is under 0.8 seconds globally. The game client takes 3-4 seconds to initialise the Three.js scene and establish WebSocket connections — acceptable for a game context, unacceptable for a marketing page.
What's Been Built in Phase 1
Phase 1 covered the foundation. Here's what exists and is functional as of this dev log:
Galaxy Map (Three.js) — 500 star systems rendered in 3D with LOD scaling, clickable sector selection, faction territory colouring, and real-time fleet position markers. Performance target of 60fps on integrated graphics is met on 85% of test devices.
Faction System — All four factions implemented with their bonus structures, unique buildings, and faction-specific technology trees. The Void cloak mechanic and Solar Overcharge are fully functional in combat simulations.
Resource Economy — Production buildings, storage silos, overflow mechanics, and the galactic market order book are all live. Price discovery is working as intended — Crystal is already trading 40% above Metal on the test server because players are prioritising Metal production, exactly as predicted.
Combat Resolution — Fleet battles resolve server-side in FastAPI using a tick-based simulation. The Three.js client renders combat as a visual sequence after the server resolves the outcome. This prevents cheating and keeps combat deterministic.
Authentication and Persistence — Player accounts, base state, fleet positions, and market orders are all persisted in PostgreSQL. Session handling uses JWT with refresh tokens.
What's Coming in Phase 2
Phase 2 is about depth and polish. The core systems exist — now we make them compelling.
Alliance systems are the highest priority. The social layer of an MMO is what retains players, and right now alliances exist in the database but have no collaborative mechanics. Alliance war declarations, shared research, territory claiming, and the co-op Leviathan raid are all Phase 2 deliverables.
We're also implementing the full chat system (sector chat, alliance chat, and direct messages), the notification system for fleet returns and market order fills, and the mobile-responsive redesign of the galaxy map for tablet play.
Closed beta is targeted for 8 weeks from this dev log. If you want early access, sign up for the newsletter — beta invites go to subscribers first.
Thank you for reading. We'll post Dev Log #2 in two weeks with the alliance systems deep-dive and the first screenshots of fleet combat rendered in Three.js. It looks considerably better than words can describe.
— The Starforge Team