SEN StarMade Feature Roadmap

Working design notes for SEN2024STARMADE, the Survivors Enclave StarMade server.

Status labels:

• Proposed: design agreed in concept, not yet tested live.
• Ready to test: command path is plausible and should be tested in a controlled sector.
• Live: implemented and verified on the server.

Server Context

• Active instance: SEN2024STARMADE
• Active world: survivors0
• Current indexed systems: 40
• Current world posture: small active/current world with legacy world0 archive nearby; treat world0 as archival unless explicitly restored.

Operating Principles

• Make game-director actions visible, documented, and reversible where practical.
• Prefer player-facing consequences over silent admin deletion.
• Keep economy-impacting or destructive actions behind explicit approval until tested.
• Separate public player access from GM/admin-only controls.

GM Faction And Public Outposts

Status: Proposed

Create a game-director faction that can own stations, shops, event structures, and public infrastructure without handing ownership to players.

Expected setup:

• Create a GM faction through admin commands.
• Spawn or load blueprint stations as faction-owned infrastructure.
• Place and configure faction modules for ownership.
• Keep public docks, shops, and service areas accessible to players.
• Protect admin storage, control blocks, and event systems with permissions.

Useful commands:

/faction_create <name> <description>
/faction_list
/faction_join_id <playerName> <factionId>
/faction_mod_member <playerName> <rank>
/load <catalogBlueprintName> <stationName>

Faction Shops

Status: Proposed

Use Shop Modules on GM or player faction stations to create controlled economy points.

Expected setup:

• Build or load a station.
• Claim it under the owning faction.
• Add a Shop Module.
• Stock the shop with blocks/items.
• Set buy/sell prices and desired quantities.
• Restrict access by public, allies, faction, or faction rank.

Admin support commands:

/give <playerName> <itemName> <count>
/giveid <playerName> <itemId> <count>
/shop_restock
/shop_restock_full

Blueprint Ship Broker

Status: Ready to test

Create a GM-run ship vendor that lets players buy complete ship blueprints or ship access from a curated list. This should feel like an NPC merchant in-world, even if the implementation is a faction-owned station, catalog terminal, shop module, and/or admin automation rather than a literal walking NPC.

Design:

• Build a public GM shipyard or broker station.
• Theme the vendor as an NPC faction representative, such as SEN Ship Broker, Trading Guild Surplus, or Junkyard Reclamation Office.
• Upload or expose curated ship blueprints through the server catalog.
• Put a Shop Module or service counter at the broker station.
• Restrict the available ships by progression tier, faction reputation, event unlocks, or price.
• Keep admin-only blueprint management areas protected.

Native path to test:

• Upload selected ships to the multiplayer/server catalog.
• Set catalog permissions so players can buy the approved entries.
• Require players to be near the broker/shop area to buy.
• Verify whether purchase immediately spawns the ship, unlocks the blueprint, or requires materials through shipyard/catalog construction on this server build.

Fallback concierge path:

• Player pays the listed price at the broker shop or to an admin-controlled account.
• Admin/game-director verifies payment.
• Admin loads the purchased blueprint near the shipyard.

Useful commands:

/list_ships
/load <catalogBlueprintName> <newShipName>
/give_credits <playerName> <count>
/server_message_to info <playerName> "<message>"

Important test questions:

• Can server catalog entries be priced and permissioned cleanly for public purchase?
• Does catalog purchase grant reusable blueprint access or a one-time spawned ship?
• Can a Shop Module directly support catalog ship buying in the desired way?
• Can blueprint purchases be limited by faction rank or only by catalog/shop permissions?
• What happens if the spawn area is blocked?

Recommended safeguards:

• Start with starter ships, haulers, miners, and salvage craft rather than combat-heavy ships.
• Keep prices high enough that mining, crafting, and salvaging still matter.
• Mark premium/event ships as limited or manually fulfilled until the economy is stable.
• Log each GM-loaded ship with buyer, blueprint, price, sector, and timestamp.

Spawn Megayard Free Repair Station

Status: Ready to test

Build a gigantic GM-owned repair station near spawn that can handle capital ships, including star-destroyer-scale builds. Repairs are free for players at the point of use, making spawn a reliable recovery hub after combat, exploration mistakes, or Deep Void junkyard recovery.

Design:

• Place the repair station near the spawn area, but far enough from the exact spawn point to avoid crowding new players.
• Own it through the GM/admin faction.
• Build an oversized Shipyard frame with clear approach lanes and a very large open drydock.
• Use one or more obvious docking/repair bays, with signage or station layout guiding players to the Shipyard Core Anchor.
• Keep the repair zone public, but protect control rooms, storage, shipyard computers, and cargo systems from player modification.
• Pair it thematically with the Blueprint Ship Broker and Deep Void Junkyard.

Technical model:

• StarMade shipyards are station-exclusive systems.
• A valid shipyard uses a Shipyard Computer, Shipyard Modules in a C shape, and a Shipyard Core Anchor.
• Damaged ships dock to the Shipyard Core Anchor.
• Repair happens through the Shipyard Computer by reconstructing the ship from a design.
• The process can replace missing blocks, but it may reset saved hotbar configurations.

Free repair model:

• Repairs are free for players.
• The GM faction absorbs the material cost.
• The shipyard should be stocked with a deep material reserve, or replenished manually/automatically by admins.
• If native shipyard repair requires player-supplied design/materials in this build, use the station as a free assisted repair service until automation is proven.

Important test questions:

• How large must the shipyard C-frame be to safely dock and repair the biggest ship we expect?
• Does a player need to provide their own design, or can the station/admin provide one?
• Can repair draw from station cargo, shipyard computer inventory, or linked storage?
• Can permissions allow public repair use without allowing players to edit the station?
• What happens if multiple large ships try to use the yard at once?

Recommended safeguards:

• No combat inside the repair yard sector.
• Add a repair queue or one-ship-at-a-time rule if players begin blocking the bay.
• Do not allow hostile/chased ships to abuse free repair mid-fight.
• Keep a separate admin bay for recovering stuck or bugged ships.
• Log large free repairs if they materially affect the economy or PvP balance.

Spawn Core Safe Zone

Status: Proposed

The 9 stars surrounding spawn should be the protected core of the campaign. Treat this as a 3x3 safe-zone cluster centered on the spawn star: the spawn system plus its eight neighboring star systems on the main play plane.

Design:

• Spawn, the megayard, ship broker, beginner services, and public gates live inside the core.
• The core is the social/economic recovery zone, not an endgame warzone.
• The Nothing should not spawn, expand, or attack inside the core.
• Pirate Heat enforcement should not create base-pressure events inside the core unless manually approved by a GM.
• New players should be encouraged to start, repair, shop, and regroup inside the core before traveling outward.

Rules model:

• No harassment, spawn camping, or hostile blockades inside the safe-zone cluster.
• PvP inside the safe zone should be disabled by rule, sector protection, or GM enforcement wherever practical.
• Players can pass through, trade, dock, repair, and stage from the safe zone.
• Valuable endgame loot should come from outside the safe zone so the economy points outward.

Boundary model:

• Inner core: 9-star safe zone around spawn.
• Main play area: the livable band between the 9-star spawn safe zone and the galaxy edge.
• Galaxy edge: dangerous endgame space, The Nothing activity, rare loot, and higher risk.

Important test questions:

• What exact star/system coordinates make up the 3x3 spawn-core cluster?
• Can sector/system protections reliably enforce the safe-zone rules?
• Should player-owned bases be allowed inside the core, or should core ownership stay GM/public only?
• What exact edge-frontier staging coordinates should the four one-way cardinal gates use?

Anti-Harassment Pirate Heat System

Status: Proposed

Use escalating pirate pressure to discourage harassment while preserving normal PvP danger. The target cadence is that a player being attacked by another player roughly once every 3-4 days is acceptable, but repeated pressure against the same player or vulnerable players builds heat. Pirate response should be a delayed consequence against the offender's assets, not interference in the offender's active raid.

Core idea:

• Track aggression as incidents, not just kills.
• Use both per-attacker heat and attacker-victim pair heat.
• Let heat decay when the attacker stops hostile behavior.
• Escalate pirate response only when the pattern continues.
• Apply pirate pressure at the offender's base or holdings after the hostile incident, not at the victim's location during the raid.
• Keep exact thresholds private and variable so players cannot precisely game the system.

Baseline tolerance:

• One meaningful attack against the same player in a 72-96 hour window should usually be treated as normal PvP.
• Repeated attacks against the same player inside that window increase heat.
• Spawn camping, attacking new players, repair-yard abuse, repeated pursuit after disengagement, and targeting the same player through alts/friends increase heat faster.
• Declared wars, consensual duels, events, mutual faction battles, and clear retaliation should be exempt or reduced.

Variable controls:

• Detection window: randomized within a configured range, such as 72-96 hours.
• Warning threshold: hidden and adjustable by GM staff.
• Escalation threshold: hidden and adjusted by offender history.
• Cooldown/decay: heat drops over time when no new harassment incidents occur.
• Spawn timing: randomized delay after threshold crossing, preferably after the active player-vs-player encounter has ended.
• Spawn location: near the offender's base, home sector, faction holding, or owned station, not at the victim's location and not predictably at a fixed farm point.
• Fleet tier: scaled by offender ship class, repeat behavior, and recent escalation tier.
• Daily cap: maximum number of enforcement events per offender per day.

Escalation ladder:

1. Warning: pirate scan, rumor, or direct GM-style message.
2. Scout pressure: small pirate probe near the offender's base or travel route.
3. Hunter pressure: stronger pirate wing attacks offender logistics, outposts, or base perimeter.
4. Punitive pressure: heavy hunter group, bounty marker, blockade, or base-sector pressure.
5. GM review: manual intervention, temporary protection, forced relocation, or discipline.

Base-pressure rule:

• Pirates should not join, assist, interrupt, or decide an active player raid.
• Pirates should not spawn on top of the victim or inside the contested raid sector just because harassment heat triggered.
• The offender's next consequence should land at their own base, staging area, home sector, or other owned asset.
• If the offender has no known base, target their last known staging sector or delay response until a valid offender asset is identified.
• Avoid automated pirate base-pressure events inside the 9-star spawn safe zone; escalate to GM review instead.

Anti-farming safeguards:

• Enforcement pirates should be low-reward by design.
• Do not load enforcement fleets with rare cargo, high-value blocks, or premium salvage.
• Use purpose-built pirate blueprints with minimal economic value relative to the effort required to kill them.
• Pirates should despawn, retreat, or stop escalating when the offender changes behavior and heat begins cooling.
• Killing enforcement pirates should not reduce harassment heat by itself.
• Repeatedly baiting pirates should increase farm-abuse heat or trigger GM review.
• Third parties should not receive rewards for farming another player's enforcement event.
• If possible, enforcement pirates should prefer the offender's owned assets, logistics, and active ship, not nearby uninvolved players.
• Do not reveal exact heat values or spawn formulas publicly.

Farm-abuse indicators:

• Same players repeatedly alternating attacker/victim roles.
• Low-damage staged attacks followed by pirate farming.
• Players luring enforcement fleets into prepared kill zones.
• Multiple players provoking one offender to generate pirates.
• Offender repeatedly crossing thresholds but suffering no real loss.

Implementation phases:

1. Manual: admins log reports/incidents and spawn pirate response by judgment.
2. Semi-automated: a watcher summarizes recent kills, sectors, victims, and offenders for GM review.
3. Automated: watcher applies heat, sends warnings, and triggers approved pirate waves within configured limits.

Useful commands to test:

/server_message_to info <playerName> "<message>"
/spawn_mobs <catalogName> <factionId> <count>
/spawn_mobs_line <catalogName> <factionId> <count>
/initiate_wave <level> <seconds> <factionId>

Important test questions:

• Do server logs expose enough player-vs-player aggression detail for automation?
• Can we identify attacker, victim, sector, ship, and faction from logs or database state?
• Which pirate faction ID and catalog ships should represent enforcement pirates?
• Can spawned pirates be tuned to low/no profit while still being dangerous?
• Can pirate waves target the offender reliably enough to avoid collateral damage?

The Nothing Endgame Incursion

Status: Proposed

Create a separate hostile endgame NPC threat near the edge of the allowed galaxy. Working title: The Nothing. These are all-black ships representing an encroaching void force. Their job is to slowly pressure outer systems, destroy unattended or weak holdings, and create a repeatable endgame combat-and-economy loop.

Feasibility notes:

• StarMade supports multiple NPC faction entries in data/npcFactions/npcSpawnConfig.xml.
• The current server has default NPC faction data for Outcasts, Scavengers, and Trading Guild.
• The server also has NPC blueprint lanes under blueprints-npc, including pirate, neutral, and trading-guild.
• Current server.cfg has ENABLE_SIMULATION = true.
• Current server.cfg has NPC_FACTION_SPAWN_LIMIT = 0; this needs testing/adjustment before relying on additional native NPC faction spawning.

Core gameplay loop:

1. Player starts at spawn.
2. Player uses a protected gate from spawn to a frontier staging sector near the galaxy edge.
3. Player hunts The Nothing ships and outposts.
4. Rare loot drops from these ships or is awarded for confirmed kills.
5. Player returns to spawn through the gate.
6. Player sells the rare loot to a GM/NPC buyer.
7. Credits fund better ships, repairs, and progression through the Blueprint Ship Broker.

Threat identity:

• Ships should be visually all-black or nearly black.
• Silhouette should feel alien, simple, and menacing rather than pirate-like.
• Naming should communicate endgame danger: Null Frigate, Black Tide Hunter, Void Harvester, Event Horizon Carrier, Nothing Dreadnought.
• The faction should not behave like ordinary pirates or harassment enforcement pirates.

Frontier/gate design:

• Spawn has four clear public one-way outbound gates, one for each cardinal direction: north, east, south, and west.
• Each cardinal gate exits at a different edge-frontier staging sector near the galaxy boundary.
• The Nothing lives at the edge of the galaxy, not in the main play area and not near spawn.
• The edge-frontier staging sectors should be protected or heavily defended enough to prevent immediate gate camping.
• The normal play area sits between the spawn safe zone and these edge-frontier staging sectors.
• Beyond each staging sector, systems become dangerous endgame space controlled or contested by The Nothing.
• Return travel should use separate return gates, extraction points, or another approved return mechanic so outbound gates remain one-way.
• Frontier content should be opt-in: players choose a cardinal edge lane, travel outward, hunt, recover loot, and return to sell.
• The Nothing should not naturally breach the 9-star spawn safe zone without a deliberate GM event.

Encroachment model:

• The Nothing starts at the edge of the allowed galaxy, well outside the 9-star spawn safe zone.
• It slowly expands inward or increases activity in outer systems.
• It can attack or degrade unattended outer holdings.
• GM events can announce incursions, surges, or breaches.
• The encroachment rate should be slow enough that players can respond, but real enough that ignoring it has consequences.
• The 9-star spawn safe zone is the hard floor for normal encroachment; breaches into the core require explicit event approval.
• The four cardinal edge lanes can have different threat identities, ship mixes, loot tables, or escalation schedules.

Implementation phases:

1. Event-spawn prototype:
   • Use black hostile blueprints loaded or spawned by GM command.
   • Place encounters near a frontier gate.
   • Award rare loot manually or through controlled shop/item mechanics.
2. Curated faction prototype:
   • Build a dedicated set of black NPC ship blueprints.
   • Place them in a controlled NPC/pirate-compatible blueprint lane for testing.
   • Tune ship classes from scout to dreadnought.
3. Native custom NPC faction:
   • Copy/extend default NPC faction config into customNPCConfig.
   • Add a new spawn entry or preset for The Nothing.
   • Test fixed spawn near the galaxy edge.
   • Verify expansion, replacement, and aggression behavior before making it live.
4. Automated endgame loop:
   • Watch frontier activity.
   • Spawn or escalate incursions on a schedule.
   • Track rare loot awards/sales.
   • Feed credits back into ship broker progression.

Loot model:

• Primary rare item: a token-like loot item from The Nothing, such as Null Fragment, Void Core, or Black Shard.
• Secondary rare item: rare ship part, weapon component, reactor part, or upgrade material.
• Loot should be scarce and endgame-gated.
• Loot should be worth selling at spawn, but not so profitable that players ignore the rest of the economy.
• GM/NPC buyer at spawn should purchase these items for credits.

Anti-farming safeguards:

• Randomize spawn timing, ship mix, and sector selection.
• Do not make every ship drop rare loot.
• Use kill confirmation, wreck/site tokens, or GM-awarded drops if native loot is too exploitable.
• Add cooldowns per player/faction if the same group farms nonstop.
• Scale encounters by group size, ship size, or recent frontier success.
• Make some encounters dangerous enough that farming requires real risk.
• Avoid putting rare loot directly into easily salvageable blocks if that breaks the economy.

Useful commands and systems to test:

/spawn_mobs <catalogName> <factionId> <count>
/spawn_mobs_line <catalogName> <factionId> <count>
/initiate_wave <level> <seconds> <factionId>
/load <catalogBlueprintName> <entityName>
/server_message_broadcast info "<message>"

Important test questions:

• Can a new custom NPC faction be added cleanly in this server build, or should The Nothing begin as an event-spawned hostile faction?
• Does NPC_FACTION_SPAWN_LIMIT = 0 prevent new NPC factions, and what value should support this design?
• Can fixed NPC spawn be placed reliably near the galaxy edge?
• Can The Nothing expand or attack holdings through native simulation, or do we need a GM scheduler?
• Which item/block will represent rare The Nothing loot?
• Can shops buy that rare loot at spawn without enabling easy duplication or farming?
• Can return gates be made reliable and protected enough for a repeatable endgame loop?

One-Galaxy Campaign Boundary

Status: Proposed

Run the server as a one-galaxy campaign even though StarMade does not appear to expose a native hard one galaxy only world-border setting.

Design:

• Define the allowed galaxy or allowed coordinate range.
• Publish the boundary as an in-world rule: leaving the galaxy means entering the Deep Void.
• Warn players before enforcement when possible.
• Use admin tools or an external watcher to enforce consequences.

Possible enforcement ladder:

1. Warning message.
2. Short grace timer.
3. Emergency return or junkyard impound.
4. Death/destruction for repeat or deliberate breaches.

Deep Void Junkyard

Status: Ready to test

When a player leaves the authorized galaxy, their ship is sent to a junkyard sector and the player dies immediately. The ship is punished/impounded without being silently deleted, giving the world a recoverable salvage consequence.

Default junkyard sector:

0,0,0

Player-facing fiction:

Deep Void breach detected. Your ship has been seized by the Junkyard. You did not survive the transition.

Manual test command path:

/change_sector_for <playerName> 0 0 0
/kill_character <playerName>

Important test questions:

• Does /change_sector_for move the currently controlled ship with the player?
• If the player is docked, seated, or controlling a turret, what actually moves?
• Is sector 0,0,0 safe and suitable for a junkyard, or should a dedicated nearby sector be chosen?
• Does killing the player after transfer leave the ship recoverable in the target sector?
• Does this require a delay between transfer and kill?

Recommended safeguards:

• Exempt admins and approved event accounts.
• Do not delete the ship on first implementation.
• Log every enforcement action with player, ship/entity, source sector, destination sector, and timestamp.
• Test with a disposable ship before using on real players.

Automation concept:

• External watcher checks player sector coordinates.
• If a player crosses the boundary, watcher sends warning.
• After the grace period, watcher issues the transfer and kill commands through the server console/API.
• Store enforcement records outside the game world for admin review.

Asteroid And Resource Economy

Status: Proposed

Current server config includes:

ASTEROID_SECTOR_REPLENISH_TIME_SEC = 604800

Asteroids replenish after a sector is mined down and reloaded/replenished; there is no confirmed direct /spawn_asteroid command. Economy design should lean on shop stock, mining rules, sector population testing, and event rewards rather than assuming live asteroid spawning.

Potential admin tools:

/populate_sector <x> <y> <z>
/spawn_item <blockName> <count>
/give <playerName> <itemName> <count>

Open Questions

• What exact coordinate rule defines the allowed galaxy boundary?
• What exact star/system coordinates define the 9-star spawn safe zone?
• Should the junkyard be public salvage, faction-controlled salvage, or GM-only recovery?
• Should first-time breaches get a warning, or should the Deep Void mechanic be immediate?
• Which GM faction name and station theme should become official?
• What exact heat windows, decay rates, pirate tiers, and anti-farming caps should be used for the Pirate Heat System?
• Should The Nothing be implemented as a native custom NPC faction, GM event-spawned hostile faction, or both?
• What should the rare endgame loot item and rare ship part be called, and what should spawn buyers pay for them?