forked from daid/EmptyEpsilon
-
Notifications
You must be signed in to change notification settings - Fork 0
Idea pile
oznogon edited this page Mar 27, 2020
·
20 revisions
- Additional sensors as a powered ship system
- Does not replace existing sensor functionality; most existing ships should not have this
- High power draw forces Engineering decisions
- Extend long-range scan range with additional power; degrade on underpowered/damage state
- Reduce scan difficulty/autoscan speed with additional power; flicker objects on scanners on underpowered/damage state
- Draw additional power during active scan; encourage more efficient player input
- Detailed signal sensors
- Detect ships not only by visibility/reflectivity but also by emissions (heat, electrical, gravitational)
- Reveal ship energy consumption and system activity
- Warp/jump signatures, track origin and destination of recent non-impulse movement
Enables:
- Stealth gameplay
- Visual cloaking/visible by signal only with significant energy draw
- Signal cloaking/impervious to homing trackers only with significant energy draw
- Silent running; intentionally underpowering to reduce signal footprint
- Electronic warfare options
- Flares/signal decoys
- Missile hacking (maybe worth pursuing regardless)
- IFF spoofing
- Beam/missile lock avoidance
- Nebula and planets as natural homing/beam lock avoidance
- Signal jammers that mask radar/signals within range (portable nebula)
- EWACS ships
- Ship types with many advanced sensors and extra-long sensor range to rapidly scan/hack many targets at once, but few/no weapons and shields; powerful tactically but high-value target and vulnerable in combat (Hawkeyes/Sentries/Sentinels)
- Scanning screen, can be used to offload multiple simultaneous scans so Science can focus on tracking/painting targets
- SFX on certain actions and states
- Temperature, power, damage alerts on Eng/DamCon/Power
- Hull creaking, reactor instability, impulse noise on damage states
- Failure sounds upon systems hitting negative damage states
- Tube loading, beam arming sounds
- UI audible feedback/chirps
- New unknown sensor contact (how to track?)
- When heat or damage reaches threshold points (>80% heat, 0 heat; shields/system/hull damaged to <50%)
- When being scanned, targeted, hailed
- Must be toggleable on stations, and probably default to off
- Potentially inappropriate for multi-screen in-person games
- Potentially disruptive to online games using non-PTT voice chat
- For accessibility, VISUAL ALTERNATIVES/SUBTITLES ARE A MUST
- Ideally played local to the station and responsive to local state, without requiring network sync
Enables:
- Diegetic bridge ambiance without requiring DMX; no contrived, repetitive track required
- Feedback that aids grokking station function and improving efficiency
- ... or does it add to what makes a station overwhelming to newcomers?
- Scripting functions to play sounds on:
- Main screen only (implemented as
PlayerSpaceship::playSoundOnMainScreen()
, but not exposed to scripting) - Specific stations (using CMD_CLIENT_PLAY_SOUND)
- All stations (using CMD_CLIENT_PLAY_SOUND)
- GM station (not implemented)
- Spectator/Top Down stations (not implemented)
- Main screen only (implemented as
- Disable or control threat estimation
- Play/stop music tracks
- Likely requires having sound/music installed locally; bundle with scenarios that require them
Enables:
- More options for scenario writers to signal plot or ambiance
- Audio feedback for custom functions
- Signal scripted or GM-controlled game events
- Beams that can do any type of damage
- EM beams for dropping shields and damaging targeted systems faster
- Kinetic "beams"/railguns for damaging hulls faster
- Sustained beams (ie. phasers) vs. discrete beam projectiles (ie. HVLI but energy)
- Non-damage beams
- Nanorepair beams (hull repair)
- Energy transfer/refueling or shield-boost beams
- Increased regenerative efficiency by synchronizing beam freq with the target's shields
- Finally, a way ships can help stations after an attack
- Tractor/repulsor beams (pull/push ships and objects; networking difficulties, physics engine has little concept of relative mass)
- Scanning beams (alternative to Science for scanning on fighters/single-pilot craft)
- Beam slots that can be swapped between types, similar to tubes
- Maybe only swappable when docked?
Enables:
- Support ships
- Actual functional tugs
- Anti-shield and anti-hull specialists that can/must work together
- Field repair ships
- Long-range refuelling ships
- IFF/scanning options for small craft and fighters where the full functionality and cognitive load of Science doesn't make sense
- New support AI behaviors
- Intact ship whose reactor hits -100% and stays there for 30 seconds loses its crew but isn't destroyed
- When disabled, all systems drop to -100% damage and all energy is dumped
- Hack the ship to capture it for the player's faction
Enables:
- Meaningful piracy; capture ships and their cargo
- Any ship can be a player ship
- Requires that any ship becomes capable of being a player ship; need default generic ship layouts and attributes for templates without them
- Emergent skeleton crew escort missions
-
PlayerSpaceship:transferPlayersToShip()
allows transferring a player crew to another ship - ... or make it an AI ship that follows basic orders and autorepairs itself
-
- Escape pods?
- Stationary dock-target "ship" with:
- One Relay station + inventory/fleet management features
- Maybe can be done purely through scripting and Relay custom functions?
- Multiple advanced sensors to aid scanning
- Ability to broadcast waypoints
- Ability to resupply, repair, re-energize, re-crew docked ships
- Limited stocks of supplies
- Stocks are replenished by visiting freighters
- Can craft new ships from freighter materials
- Reliance on probes for long-range sensing
- Limited inventory of support ships to dispatch
- Fighters
- Supply drops
- Jumpship carriers
- Minelayers
- One Relay station + inventory/fleet management features
- Can reward Reputation to players
- Can deploy (and hop into?) new player ships
Enables:
- More player-to-player comms
- Command-and-control gameplay
- Station commander can focus on big picture and suggest/order player ship captains
- Fleet management of CPU ships
- Alternative to single-pilot station for single-player/loose-wheel gameplay
- Easier/less overwhelming onboarding role to help orient new players (depending on the scenario)
- ShipTemplate and tweakable per-ship settings for how much energy per tick/second/action? is drawn and generated
- Some ship reactors should be better than others
- Some ships' systems should be less efficient than others
- Should be a factor of baseline? Or a raw number?
- How to deal with action costs? (jumps, missile load/fire, maneuvers; beam firing is already configurable)
Enables:
- More ship differentiation and customization
- Efficiency gains via scripting (ie. upgrades at stations)
- More surface area for scriptable engineer torture