BaseBorn

• 

  Main Login Screen

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:

1. Spawn in a Survey Pod in the protected outer belt.
2. Aim the pod's mining beam at nearby asteroids.
3. Break asteroids and collect synchronized Ether drops.
4. Deliver 12 Raw Ether to repair the derelict starter hull.
5. Land on the repaired spacecraft.
6. Integrate the Survey Pod as its command module.
7. Repair additional onboard systems.
8. Earn XP, score, levels, and core-tuning points.
9. Evolve the spacecraft's weapons and specialize its combat build.
10. 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 for BaseBorn

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.

Built With

• canvas-2d
• codex
• game-development
• github-actions
• gpt-5.6
• multiplayer
• node.js
• openai
• playwright
• pwa
• railway
• react
• react-19
• responsive-design
• server-authoritative
• typescript
• vite
• websockets
• ws