Project Info
Inspiration
Most space-survival games begin by giving the player a capable ship, a secure base, or a clearly defined mission. BaseBorn begins with almost nothing. The player awakens alone inside a small Survey Pod beside the remains of a derelict spacecraft. The pod has limited protection, a single mining beam, and only enough capability to survive in the outer asteroid belt. The first objective is not to conquer the universe. It is to mine enough Ether to repair the nearby wreck, land inside its command cradle, and transform the Survey Pod into the living command module of a new spacecraft. BaseBorn was inspired by space-survival games, shared .io worlds, ship-building systems, and progression mechanics where player decisions change both how a build performs and how it looks. I wanted the journey from a fragile pod to a specialized spacecraft to happen through gameplay rather than through a character-selection screen. Every pilot begins from the same ruins, but the decisions made afterward create a different ship and a different story.
What it does
BaseBorn is a real-time multiplayer space-survival game for desktop and mobile browsers, built from scratch during OpenAI Build Week. Every player enters the same shared universe and begins beside a reserved derelict spacecraft. The playable loop is: Spawn in a Survey Pod in the protected outer belt. Aim the pod's mining beam at nearby asteroids. Break asteroids and collect synchronized Ether drops. Deliver 12 Raw Ether to repair the derelict starter hull. Land on the repaired spacecraft. Integrate the Survey Pod as its command module. Repair additional onboard systems. Earn XP, score, levels, and core-tuning points. Evolve the spacecraft's weapons and specialize its combat build. Form teams, travel toward more dangerous sectors, and compete with other pilots. The current game includes: Real-time multiplayer movement and combat One shared public map per server instance A persistent 400,000 × 400,000 space environment Keyboard, controller, touch, and mobile controls Independent movement and weapon aiming Physics-based spacecraft movement with inertia and damping Asteroid mining and shared Ether drops Six asteroid and Ether rarity families Five-minute asteroid regeneration Ship recovery and Survey Pod integration Onboard spacecraft-system repairs XP, score, levels, and a live leaderboard Core-stat progression Level-gated weapon evolutions Multiplayer teams, invitations, leadership, and shared ownership Server-synchronized projectiles and PvP damage Reconnection and progression restoration Responsive desktop, tablet, and mobile interfaces Installable Progressive Web App support A universe built around Ether Ether is the central resource in BaseBorn. The universe contains six Ether qualities: Raw Ether Refined Ether Charged Ether Radiant Ether Primal Ether Core Ether Raw Ether is common in the safer outer belt. More valuable Ether appears progressively closer to the center of the map, where asteroid durability, mining resistance, competition, and danger increase. This creates a natural risk-and-reward structure. New pilots can recover their spacecraft in relative safety, but stronger progression requires leaving the outer belt and entering contested space. Asteroid destruction is shared across the server. When one player destroys an asteroid, nearby players can see and collect the same Ether drops. The asteroid remains destroyed for five minutes before regenerating. Rewards, XP, score, cargo, asteroid state, and Ether collection are validated by the multiplayer server to prevent duplication and inconsistent progression. Player-driven spacecraft progression Every pilot begins with the same Survey Pod and the same universal spacecraft foundation. The final build is determined by the player's decisions. Players earn one core-tuning point per level from levels 2 through 34, with a maximum of 33 available points. These points can be allocated across eight core statistics: Health regeneration Maximum health Body damage Projectile speed Projectile penetration Projectile damage Reload speed Movement speed These stats support different playstyles. A pilot can build for durability, collision damage, mobility, sustained fire, powerful individual shots, projectile penetration, or a balance between several roles. At major progression levels, players can evolve their mounted weapon system. The current evolution paths include Twin and Sniper choices at level 15, with the architecture prepared for additional branches such as drones and other specialized weapon systems. Progression is intended to affect more than numbers. Weapon barrels, emitters, thrusters, drone systems, armor sections, projectiles, and other visual components can change as the spacecraft evolves. The Survey Pod is the beginning. The recovered spacecraft is the platform. The completed build becomes a visible history of the player's decisions. Multiplayer and teams Every connected pilot exists inside the same public world running on the server instance. Player movement, projectiles, asteroid destruction, Ether drops, damage, score, and progression are synchronized between connected clients. The outer belt functions as the starting and recovery area. PvP becomes active deeper inside the map, where more valuable resources can be found. Players can: See other pilots moving in real time Fight using synchronized multiplayer projectiles Compete for shared asteroid resources Track rankings on the live leaderboard Create or join teams Invite other pilots Transfer or manage team leadership Share spacecraft ownership Regroup near the team's active spacecraft Cooperate when mining or entering dangerous sectors The current build focuses on individual spacecraft and team cooperation. The planned physical fusion of multiple advanced team spacecraft into a larger mobile structure remains future work rather than a completed feature. How I built it I built BaseBorn from scratch during OpenAI Build Week using Codex and GPT-5.6. The client was created with: React 19 TypeScript Vite Canvas 2D rendering Responsive HTML and CSS Progressive Web App support The multiplayer server was created with: Node.js 22 WebSockets using ws Server-authoritative world validation Optional file-backed world persistence Railway deployment GitHub Actions continuous integration The project was divided into focused systems for: Player and spacecraft movement Input handling Asteroid generation Mining Ether drops Cargo Ship recovery Docking and integration Core progression Weapon evolution Projectiles and combat Multiplayer synchronization Teams and ownership Reconnection Persistence Desktop and mobile interfaces Camera behavior Rendering and visual feedback Separating these responsibilities made it possible to improve one part of the game without repeatedly destabilizing unrelated systems. How I used Codex and GPT-5.6 Codex was used throughout the project as an engineering collaborator rather than only as a code generator. I used Codex to help: Plan system architecture Implement individual gameplay systems Connect client and server behavior Trace bugs across multiple files Refactor complex code Review related code paths before making changes Strengthen server-side validation Improve multiplayer synchronization Create automated smoke tests Build load and persistence tests Verify responsive layouts Configure production deployment Prepare technical documentation Review the repository before release GPT-5.6 was used for broader reasoning about: The core gameplay loop The Survey Pod starting experience Spacecraft progression Ether rarity and map distribution Risk-and-reward balance Weapon-evolution paths Interface structure Mobile control design Multiplayer rules Testing requirements Release priorities I remained responsible for the game's direction, mechanics, visual identity, priorities, acceptance criteria, testing decisions, and final implementation choices. The most effective workflow was to give Codex a clearly scoped objective, explain the surrounding architecture, define constraints, specify acceptance criteria, and require verification before considering a feature complete. Challenges Replacing the original opening One of the largest design and engineering changes was replacing the earlier station-first opening with the current Survey Pod recovery sequence. The new experience required players to: Spawn in the correct Survey Pod Receive a reserved derelict spacecraft Mine exactly 12 Raw Ether Repair the starter hull Land on the recovered spacecraft Integrate the pod as its command module Continue progression without losing multiplayer state This change affected rendering, interaction prompts, cargo validation, server ownership, docking, progression, reconnection, tutorials, and interface behavior. It was not enough to replace one asset. Every connected system had to agree about whether the player was flying a pod, approaching a derelict spacecraft, repairing it, docking, or controlling the integrated craft. Server-authoritative multiplayer Another major challenge was deciding which information the client could request and which information the server had to calculate. The server now validates important systems including: Asteroid destruction Ether rewards Cargo balances XP and score Core-stat allocations Projectile creation Projectile damage PvP rules Ship claiming Team ownership Reconnection state This prevents clients from proposing impossible rewards, duplicated Ether, invalid stat totals, or inconsistent combat results. Shared-world synchronization Asteroids, Ether drops, projectiles, players, teams, and damage must remain consistent for everyone connected to the world. A player destroying an asteroid while docking, moving near a world boundary, disconnecting, or using an upgraded weapon range could create difficult synchronization problems. Codex helped inspect the complete event flow, identify where state could be lost, and implement fixes across both the client and server. Supporting multiple devices The game needed to remain playable using: Keyboard and mouse Game controllers Touchscreens Mobile movement and aiming sticks Desktop displays Ultrawide displays Tablets Landscape phones Portrait fallback layouts The camera, controls, HUD, menus, docking actions, and safe areas had to adapt without blocking gameplay. Testing a connected game A multiplayer game can appear correct during one manual session while failing under reconnection, multiple clients, delayed messages, repeated inputs, or persistent-state restoration. The project therefore includes automated verification for: Keyboard and controller movement Rotation, thrust, inertia, and damping Multiplayer joining and synchronization Shared asteroid drops Five-minute asteroid respawning Cargo validation Ship claiming Teams and leadership Shared projectiles and damage Reconnection Respawning World persistence Production builds The multiplayer load test also simulates 24 connected clients sending 20 input updates per second. Accomplishments that I am proud of I am especially proud of: Building a complete playable multiplayer game during the hackathon Creating a clear journey from Survey Pod to recovered spacecraft Making the pod physically become the spacecraft's command module Building one synchronized world shared by connected players Creating six resource rarities with increasing risk toward the center Implementing server-authoritative mining, cargo, progression, and combat Supporting desktop, controller, tablet, and mobile play Creating meaningful core-stat and weapon-evolution choices Restoring player progression after reconnection Building automated movement, multiplayer, load, and persistence tests Deploying the production game through Railway Using Codex across the complete engineering workflow Producing a playable product instead of only a visual concept or technical demonstration What I learned BaseBorn showed me that AI-assisted development works best when the developer maintains strong control over architecture and verification. Codex could implement large amounts of functionality quickly, but the quality of the result depended heavily on the instructions it received. The most successful tasks included: A clearly defined problem Relevant architectural context Explicit constraints Files and systems that needed inspection Acceptance criteria Required test commands Manual verification steps A clear definition of completion I also learned that interconnected systems cannot be developed as isolated features. Changing the player's starting craft affected progression, cargo, rendering, docking, multiplayer ownership, persistence, tutorials, and interface states. Every major change had to be reviewed as part of the entire product. AI accelerated the work, but human ownership remained essential for deciding what the game should become, which mechanics were enjoyable, what should be removed, and when a feature was reliable enough to ship.
What's next
The current project is a playable single-process multiplayer MVP with one shared world per server instance. The next planned improvements include: Account authentication Cross-browser progression Database or Redis-backed shared state Horizontal server scaling Regional multiplayer infrastructure Additional weapon-evolution branches Drone-based spacecraft builds Expanded cooperative PvE More enemies and objectives Central-universe encounters Physical fusion of advanced team spacecraft Moderation and reporting tools Telemetry and replay capture Seasonal leaderboards Live balance configuration More spacecraft visual customization Expanded sound and visual effects The long-term goal is to create a living space universe where every player begins in the same fragile Survey Pod but develops a spacecraft, team, strategy, and history that are uniquely their own. BaseBorn is about beginning with almost nothing and building something worth protecting. Mine. Repair. Integrate. Evolve. Survive.
This project did not link a GitHub repository.
Analysis
No indexed repository for this project, so there are no commit stats to show.
Technology
- Node.jsUnchecked
- OpenAIUnchecked
- ReactUnchecked
- TypeScriptUnchecked
No repository was indexed for this project, so these Devpost claims have not been checked against code.
AI coding agents
No repository was indexed, so agent usage could not be checked.
Detected from committed agent config files and commit authorship. Absence of a signal is not proof an agent was unused.
Codebase size
No repository was indexed, so there is no codebase to measure.
This project did not link a GitHub repository, so there is nothing to diagram.
This project did not link a GitHub repository, so its feature claims have not been checked against code.
Export this project's context (description, README, evidence, key source files) to chat with an AI agent elsewhere.