Splitting Dark Cosmos into two projects — design

Splitting Dark Cosmos into two projects — design

Context

Dark Cosmos (repo: bullet-heaven) started as a focused twin-stick bullet-heaven (Vampire Survivors × Nova Drift). Over the course of building it, EVE Online-style meta-progression ideas (ship classes, gold economy, the long-term vision in docs/ROADMAP.md) got introduced into the same project. Chris’s concern: is a hybrid diluting both the “simple, pick-up-and-play arcade shooter” identity and the “deep EVE-style sandbox” identity?

Working through it, the actual distinction that matters is genre, not depth:

• Survival vs. Story mode (both already in bullet-heaven) are the same game — same twin-stick real-time control, same weapon/upgrade/boss vocabulary — just different content structure (endless waves vs. authored rooms). Not a fork candidate; the existing null-object seam (Sim.story) is the right tool for this and stays as-is.
• The EVE-style direction requires a genuinely different interaction paradigm: pause-driven ship fitting instead of flow-state twin-stick control, a persistent world/economy instead of discrete resetting runs, real stakes on death (losing your fit) instead of banked run currency, and combat that’s plausibly simulation-flavored (range falloff, travel time, transversal) instead of arcade auto-fire/auto-target. That’s a different game, not a deeper mode of this one.

Decision: split into two separate projects. This is close to the cheapest possible moment to do it — no genuinely EVE-specific system (persistent economy, ship loss, fitting UI, falloff combat) has been built yet, so there is nothing to untangle out of bullet-heaven. Ship classes (frigate/cruiser slot counts) stay in Dark Cosmos — they still run through the same real-time auto-fire loop, no different from Nova Drift’s alternate loadouts.

Scope of this plan

This plan covers standing up the second project and building one throwaway vertical-slice prototype to test whether the EVE-lite core loop is fun at all. It does not cover the full EVE-style game (persistent economy, multiple systems, multiplayer, mining, contracts) — per docs/ROADMAP.md’s own note, that’s too large for one spec and gets decomposed into its own sub-projects later, once the core loop is validated.

Project 1 — Dark Cosmos / bullet-heaven (unchanged)

No structural change. Continues its current roadmap as-is: v0.1 launch prep, Story mode, ship classes, meta-progression shop, Elemental Dimensions, LAN co-op. Going forward, new work that needs persistent world state, permadeath-style loss, or menu-driven fitting screens belongs in the new project, not here.

Project 2 — working codename sovereign (placeholder name, not final branding)

• Location: ~/Claude/sovereign/, sibling to bullet-heaven — matches Chris’s existing pattern for separate game projects (chess-defense-td, chess-moba, flowtrails, star). Own git repo (git init first, since ~/Claude/.gitignore is blanket-ignore).
• Engine: Godot 4.6, fresh project.godot. Desktop-first (Mac) for phase 1 — mouse/keyboard iteration is faster and matches EVE’s native control paradigm, and it isolates “is this fun at all” from “does this translate to touch/TV,” which is a separate, harder question (CCP’s own EVE Mobile shows even a faithful, well-resourced translation to touch didn’t land as well as desktop — worth proving the core loop before spending effort on that).
• What’s reused from bullet-heaven (copied and adapted, not shared/symlinked — this is meant to diverge into an independent codebase): the data-oriented deterministic-sim architecture pattern — EntityPool/SpatialHash/SeededRng style pure-logic (RefCounted, no Node/Engine APIs), the GUT-based determinism test discipline (pin a byte-identical snapshot hash, re-verify every change), and later, once this project reaches device-testing, the tvOS/iOS deploy playbook (symlink-fold + devicectl install pattern).
• What’s NOT reused: weapons, the elemental system, story/dialogue, the meta-shop UI, ship classes — these are bullet-heaven-specific gameplay for a different combat feel, not applicable here.

Phase 1 prototype — the vertical slice

Single-player, single arena, throwaway-quality. Goal is answering three questions, not shipping a game:

1. Fitting: a pre-combat, paused fitting screen — pick a small number of module slots (weapon/tank/utility) from a small item pool. Does pausing to configure before a fight feel engaging or like friction?
2. Combat feel: real-time 2D combat where weapons have an optimal range with damage falloff beyond it, and projectiles have travel time (not instant hitscan/auto-target). Movement is orbit/approach/keep-at-range rather than twin-stick free movement. Does this feel good in a short session, or does it just feel like reduced responsiveness compared to arcade twitch combat?
3. Stakes: dying loses the current fit, forcing re-fit from a small stash before the next attempt. Does losing your fit feel like meaningful stakes, or just punishing friction?

Explicitly out of scope for phase 1: persistent multiplayer economy, mining, salvage, contracts, multiple star systems/a market, more than one ship, 3D.

Success criteria

Chris can answer, from actually playing the slice:

• Does pause-to-fit feel worth it, or should combat stay uninterrupted?
• Does falloff/travel-time combat feel good, or does the game want arcade responsiveness even in an EVE-flavored wrapper?
• Does fit-loss-on-death feel like real stakes worth building a whole economy around, or does it just frustrate in short sessions?

These answers decide whether to keep investing (persistent economy, more ships, multiplayer, later a touch/TV pass, later a 3D pass) or fold/pivot the concept before sinking more time in.

Risks / tradeoffs accepted

• Two codebases means shared engine improvements (perf work, spatial hash fixes) must be ported by hand if wanted in both — accepted, because the interaction paradigms are different enough that most of the code wouldn’t be shared even in an ideal world.
• Desktop-first phase 1 defers the touch/TV question — accepted as a deliberate sequencing choice to isolate risk, not an oversight.
• No hybrid option is being pursued — reconciling two incompatible control paradigms in one UI is a harder problem than either genre alone, and not worth tackling before the EVE-lite half is validated standalone.