Skip to content

Instantly share code, notes, and snippets.

@DavidSouther
Last active April 4, 2016 02:00
Show Gist options
  • Star 3 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save DavidSouther/5390171 to your computer and use it in GitHub Desktop.
Save DavidSouther/5390171 to your computer and use it in GitHub Desktop.
Space Naval Sim

cc by-sa 3.0

OUTDATED

It now lives here.

Premise

Take command of a Stellar Naval Vessel (SNV) in a universe with physics from the CoDominium universe. Manage navigation, weapons, science, and more as you lead your crew on various missions ranging from military engagements to interstellar diplomacy to scientific exploration. Earn your place in the admiralty and take on larger missions, eventually controlling armadas and fleets at a galactic level.

Guiding Principles

  • Realistic Apart from the addition of Alderson Tram Lines, the game should be as "real to life" as possible. Where possible, for the "real" campaign, use available stellar data. For generated campaigns, use parameters consistent with known stellar configurations. Choose vessel and fleet metaphors consistent with modern naval terminology. Invent technologies within the possibilities of known physics.
  • Fun The game has to be fun. The interface should make it as easy as possible to allow the gameplay mechanics to work. Navigation especially will be a game of approximations. Use reasonable approximations where possible. We really don't want to be calculating n-body simulations, so star systems will not have long-term perturbations but should use closed-form time-based ellipses for large bodies in the system. The game should minimize minutia that the player must handle. That said, the minutia should allow emergent tactics to arise from gameplay. Allow reasonable time speeds for various gameplay pieces - while it would take weeks of real-time to travel between bodies, even in this world, the player needs to be able to do such travel speeds almost instantaneously when moving between missions, or slow the time down to give out-of-combat orders.
  • Beautiful We are rendering large volumes of nothing, making the player realize the vastness of space. The game must then be beautiful in its piece environments. Stars should pop. Planets have atmosphere. The ships are elegant, metal beats. The interface has to be slick and straight-forward.

Gameplay

  • Bridge Command Give general orders for your ship, allowing AI or player consoles to conduct actual ship operations.
  • Bridge Consoles Manage specific parts of the ship's operations, in single player to micromanage or in multiplayer as a crew.
  • Fleet Command Manage a fleet from your flagship, sending ships and flotilla to accomplish large-scale objectives.

Campaigns

Storyline gameplay is driven by Campaigns, loosely scripted story "seasons" in the series. Campaigns are set in open-ended universes. The player has their ship, and that is the only constant. The admiralty will send orders with engagements for the player, but the player is also given the chance to take liberties to explore on their own. Engagements are set story pieces with predefined objectives. In early play, engagements are ordered by the admiralty to the player. As the player advances, the campaign orders will loosen, allowing the player significantly more liberty (as well as resources) in achieving the objectives set by the admiralty. By the end of the storyline, the player will themselves be setting admiralty objectives.

Engagements

  1. Hunt Pirates In this early engagement, the player will be in command of their ship orbiting an asteroid. The Admiralty has ordered the ship to destroy a rogue pirate ship, also in orbit around the asteroid. The two ships begin in similar orbits. The captain must order his ship through appropriate commands to seek and destroy the enemy. Serves as a tutorial level for basic navigation and combat operations.

  2. Hunt Pirate Base As a follow up to the previous mission, the ship has been ordered to seek out the pirate's base of operations on a nearby asteroid. The player must lead his ship through basic interplanetary navigation, performing repairs from the prior engagement, and performing science operations to find the pirate installation. More advanced planetary navigation might be necessary when entering the system, to find an appropriate orbit for bombardment.

  3. Capture station With a small fleet, the player has arrived in a system and must attack a station at a known location. Includes tactical "capture" operations (perhaps special "torpedoes" with marines?), and includes multi-ship engagement.

  4. Explore new system A new tramline has been discovered. Lead a fleet through the line, secure the far end, and begin exploring the new system. Science to discover the planets, asteroids, and locations of interest within the system. Secure those locations, and begin colonization work.

  5. Neutralize planet With a large fleet, the player must neutralize a planet held by enemy forces. The player has several options, including marine assault, orbital bombardment, and asteroid attack. Each has benefits and costs: marine assault will be very expensive on fleet personnel, but earns the planet as an installation for the fleet. Orbital bombardment will be quick, but somewhat costly on both the current fleet and the potential planetary installation. Asteroid bombardment will take the most time, but have the fewest current costs at the expense of completely destroying the installation.

  6. Blockade system With a large fleet, blockade a star system. Position your warships at key graviational points within the system, to destroy trade vessels as they jump in and as they coast around the system on interplanetary trajectories. Pillage the system, destroying key installations providing personell, ships, and supplies.

  7. Capture Binary System The ultimate in the main game, the player must command a large fleet to capture a well-fortified star in a binary system. The primary has a wealthy planetary system. The secondary orbits at a distance of ~6 light-months. The player can stage in one or more of several nearby systems, committing as many resources as necessary. Or... the player can research technology to cause the secondary to undergo a GRB pointed at the primary, and wait 7 months to attack.

Random Encounters

  • You are charting a new-ish system - tramline discovered 5 years ago, colonies from several factions. You are in orbit around the 4th planet, a gas giant, mass 0.8 Jupiters. It has a medium moon system: 3 large, a dozen small. Eight-band ring system, ending some 20Mm below your orbit, inclined ~10deg to you. During scans, an object is found in a nearby orbit with high heat signatures, small cross section, and low opacity. Likely an unknown vessel. Comms hails with tight-beam radio IIFF (Introduce / Identify Friend Foe). Unidentified object immediately burns for 75 seconds. Burn intensity produces mass estimate: small vessel, between 3 and 4 thousand tonnes. After burn, projected course towards nearest moon, the 5th from the planet of the 15 known moons. The moon has an average radius of ~95km, with its longest axis 115km. UFO's new course leads to periapsis with moon in 20 hours at an altitude of 150km, and will be behind moon relative to your current course for ~35 seconds, starting 5 minutes before periapsis. Given the burn rate just seen, the UFO could inject with eccentricity <1.0, inclination ~40 deg. with a 55 second burn, and 75 seconds to eccentricity 0. You can inject into the moon in 26 hours with a 2 minute burn immediately and an 80/120 second burn at periapsis (betwen 250 and 750km) with inclination between -70 and 70. You can inject into the moon in 14 hours with a continuous burn plan, at any altitude/eccentricty/inclination desired.

Game mechanics

Overall, game mechanics are built on a resource management scheme. Within the ship, three resources are available for broad tasks: fuel, energy, crew. On the ship, these are generally use-only within a sortie, and refilled when returning to base. Within a fleet, resources are used to build, repair, and improve vessels and installations. Vessels carry out your objectives, while installations generate resources. Primary resources are Hydrogen (power/fuel), Common Metals (General construction), Rare Metals (specialty construction), and Population (personnel resources for ships and installations).

Ship Mechanics

Consoles

  • Navigation Manage your ship's position in the universe, from altering orbits around a body for different effects to moving between systems and coordinating Alderson jumps. Decisions include getting to certain points within allotted time, while conserving fuel efficiency for future engagements and missions. During engagements, must handle maintaining orbits while bringing weapons to bear and keeping weak spots from enemy fire. Resource: Fuel

  • Rotation ships are large craft, with significant mass to manage in combat situations. While thrusters across the ship are able to provide any needed change in rotational orientation, it does take some time to rotate the ship to an appropriate vector. A good helmsman will maintain an orientation vector in combat. A great helmsman will schedule reverse burns to control the torque at various points of the maneuver. (See Kerbal Space Program.)

  • Burn plan The most basic navigation technique. The conn plots the current orbit on a schematic of the system. The helmsman can then choose a point on the projected orbit to schedule a burn, specifying ship orientation and burn rate and time. The conn will then plot a second orbital line, based on the calculated orbit after the first burn. The helmsman can continue building plans indefinitely. The conn will alert the helmsman if a deemed "unsafe" burn is chosen. See (Kerbal's MechJeb mod.)

  • Position/Orientation/Time The helmsman chooses a point above the body's surface in Latitude/Longitude/Altitude components, chooses an orbital orientation for the desired orbit when at the position, and chooses some delta-T range for the orbit to take. The conn then computes a potential burn plan, which the helmsman is free to edit as needed. (Doesn't have a Kerbal equivalent?)

  • Tactical Manage fire control on a vessel, attacking targets of interest. Basic combat involves point-defense lasers vs missiles, and heavy lasers for more direct engagement. Tactical designates target areas on enemy vessels for various weapons, and manages point-defense laser concerns. Lasers take a drain on energy, missile supply is limited. Resource: Energy, Missiles

  • Kinetics A 100kg missile hitting an object at 225km/h (shuttle reentry speed) imparts some 5*10^12 joules of kinetic energy, causing damage on the scale of a medium sized nuclear power plant. Targeting the missiles requires plotting the trajectory of the projectiles, accounting for the continued orbital trajectory of the firing vessel, the target vessel, and the missile.

  • Lasers Beam weapons are much shorter range, but higher precision, than kinetic weapons. Laser systems fall in two broad categories - point defense and heavy damage. Point defense lasers are configured to track and damage missiles while the missile is in flight. The laser must maintain a tight focus on the missile for several seconds to heat the kinetic enough to cause structural collapse. Heavy beam weapons are used to damage large swaths of armor at a time, and possibly rupture the hull directly. Managing beam intensity to cause damage, while not overheating or overdrawing energy is an important task for the tactical officer.

  • Armor It's a bit odd, but the most effective armors against kinetic weapons generally involve wrapping your vessel in another layer of explosives. Called Reactive Armor Systems on modern (21st century) tanks, these armors are composed of a layer of explosive between two plates of metal. When the kinetic pierces the outermost layer, the explosive detonates, converting the mass of the kinetic into plasmas and altering the trajectory of the remaining solid, shunting it into yet more armor. Any panel, of course, can only be used once. Keeping a well-armored section of the hull towards an incoming barrage becomes more important as the engagement wages longer.

  • Personnell Combat Simulated, but not played, in the game.

  • Boarding Not as common, but a possible covert operation. A small, stealth vessel is released from the parent craft. It intercepts, attaches to, and breaches the enemy hull. Marines attempt to take control of the vessel. Vice versa, marines must respond quickly to enemy boarding attempts.

  • Powered Armor Drops These are hard. Read the Mobile Infantry parts of Starship Troopers. Feel free to ignore the politics. This is a tight collaboration between tactical and helm - drops must be at precise points on a planet, and the recovery capsule has an incredibly tight window for return.

  • Engineering Manage overall vessel health, including general maintenance and improvement outside combat and emergency repairs in combat. Manage overall systems energy levels, routing power to systems in need on-demand. Resource: Energy, Crew, Hull

  • Energy Engineering is responsible for maintaining effective energy levels, and routing that power between various ships systems. Nearly everything on the ship takes power - main engines, thrusters, active capacitive armor, beam weapons, life support. Reactive armor and kinetics don't require energy during combat.

  • Repairs After combat, hull damage needs repair, reactive armor needs replacing. Weapons need calibrating, reactors need tuning. Keeping a space vessel running well and smoothly is quite the undertaking!

  • Science Manage vessel observation equipment, including planetary and astrogation observations out of combat and enemy appraisal in combat. In combat, works closely with tactical to provide fire-control recommendations and solutions. Out of combat, work with Engineering on unique ship improvements, and navigation for creative conning solutions. Resource: Energy or Crew

    • Detection Vessels don't behave or look much different than a particularly warm metal asteroid when they aren't actively encaging engines. On the other hand, space rocks don't look or behave much differently than unpowered vessels! Add in finding Alderson tramlines to connect to new systems, finding planets, moons, rings, and asteroids in known but uncharted systems, and finding the myriad other unknowns in the Final Frontier, detection makes up a large part of a vessel's science departments responsibility.

    • Identification There are hundreds, if not thousands, of objects of interest in a stellar system. Having found them, the science team then must identify them. The basics: orbit, dimensions, and mass. Composition: metals? Rocks? Gasses? Is it a vessel? If so, comms will be brought in to work with IFF. If it's a hostile vessel, identification goes further in identifying strengths and weaknesses: hull composition, power, propulsion, and weapons capabilities, feasible future trajectories.

    • Research Science itself is, of course, about testing. The science personnell have a large role and responsibility in both pure research, and in support for other divisions' research. On ship, science can work with other departments to improve ship functionality and systems. They can also gather "pure" research, to pass back to fleet as a resource for larger research projects, improving the systems of the entire armada.

  • Communications Manage fleet communications, IFF, and non-friendly messaging. Ensure proper Identify Friend/Foe functions, secure communication among friendlies, and manage sending messages to non-friendly vessels. Resource: Minigame

  • IFF Comms are responsible for correctly identifying who, and who not, you can shoot.

  • Diplomacy Sometimes, you might be able to talk the other guy down.

  • Fleet / Formations Secure communication with the fleet is critical for long-duration missions with no realtime contact to the admiralty. When in a fleet action, knowing when and where a vessel must be in formation is the difference between victory and massive fleet destruction before the battle even begins!

  • Command / Executive Provide overall orders to bridge officers, passing necessary information between stations and making final ship decisions. When both CO and XO are present, decision duties fall to CO while XO handles coordination of the bridge. Resource: All

AI Modes

  • Goose Move between locations in a system, using fuel-efficent Hohman transfers.
  • Antelope Move between locations, using constant 15m/s burns.
  • Eagle From a long distance (interplanetary), observe targets of interest. Targets have very small burn windows to change course undetected. Maintain higher velocities, but instead of constant burns, keep total speed to match target low.
  • Cat Intraplanetary, plot glancing intercept courses. Course should bring vessels past barrage range. Switches to mouse when losing.
  • Mouse When enemy is expected to attack, carry out evasive actions. Burn when out of sight (behind planetoids). Escape if possible. Switches to cat when gaining the upper hand.

Fleet Mechanics

  • Navigation Order vessels to certain locations at certain times. Specify fleet layout for larger tactical operations.

  • Engagements Specify engagement objectives, from broad "Destroy/Capture" to specific orders for individual vessels.

  • Construction Manage fleet repair and new vessel and installation construction.

  • Research Manage research of improvements for across the fleet.

  • Personnel Manage population in the fleet's sphere of influence.

  • Trade Manange supply lines within and between systems.

Tech Tree

The tech tree can be broken into Ship and Fleet. Ship improvements affect a single vessel, and are the types of things a crew could perform independently. Its progression will be bounded by research in the Fleet tree - certain levels will be unavailable without the appropriate fleet research, while some fleet research will grant every ship in the fleet other improvements.

Ship

  • Propulsion Efficiency improvements on engine types. Experimenting and finding ways to push systems envelope limits.
  • Power
  • Weapons
  • Armor
  • Optics / Sensing

Fleet

  • Propulsion Systems New types of propulsion systems - New reactants, Ion, Electrothermal, Nuclear, Diametric? Alcubierre?
  • Power Systems New types of power - solar, fission, fusion, tokomak, etc.
  • Weapons Systems Larger mass drivers, smaller mass drivers, UV/Microwave/xray beams
  • Defensive Systems Reactive Armor systems, ablative armor systems, hybrids
  • Sensing Systems Optical sensing, IR, cooling systems (don't give off signatures). Combat spectroscopy - get spectral data from hits on enemy craft.

Development

Development will be completely open source. The project will be hosted on GitHub from day one. ?Assets will be kept separate from the code repo.?

Technology

Taking advantage of modern software environments, the entire client should run in a web browser client. Today's browsers are incredibly powerful, and with the correct usage can provide any features a game title needs.

For multiplayer aspects, a node.js server will handle all necessary sockets. The multiplayer server will be easily installable in a stand-alone environment (indeed, the single player version will actually be the full multi server running locally).

Client

Communication between the client and server will happen over socket.io. The SNS core libraries will be a vanilla model wired to Socket.io. These core objects will allow hooking into the game state.

The console interfaces will be in DOM. By exposing a consistent and clean socket.io interface and a framework agnostic game model, developers will be free to choose which DOM technology to use when creating consoles and clients. Core dev will probably use AngularJS.

The viewscreen will be WebGL, probably using the THREE.js library with S3age and others plugins, as needed. Consoles themselves can, of course, use WebGL to display their interface. The helm would have a 3d rendering of the current trajectory and attitude. Engineering would have a detailed schematic of the player's vessel. Weapons would have a schematic of the enemy vessel, to use for specifying targets.

WebRTC offers some great opportunities for doing neat things in the multiplayer, including a "cheap" ventrillo alternative. This could also be a fun "open hailing frequencies" game mechanic - set up a webcam correctly, and get the full experience of Captains staring each other down over massive viewscreens!

Audio

Audio has some very interesting ideas. Sound effects should be "Inside Ship" - heavy on internal sounds, machinery, etc. The larger the ship, the higher the crew luxury, the less that machinery will sound on the bridge. Think about the differences between the Red October (the nuclear submarine), a diesel sub, and the USS Enterprise D. The first two would be incredibly noisy, while the third has diplomatic luxury and would be more comfortable with a low thrumming of energy from the ship's core.

Music should be a dynamic system. It should be electronica inspired, and keyed to the current state of the game. Let's take a battle for a concrete example. As the battle begins, the music track starts at 80bpm. The BPM itself will be tied to the % health of the currently weaker vessel, maxing out between say 140 and 180 BPM immediately before destruction. The player's vessel itself has a base bass loop, that unerlies the entire composition. The shields have a mid-range loop, that starts the battle very clean. As the shields are damaged, the shield loop gets increasingly distorted, until being nearly pure static in its frequency ranges as the shields are disabled. Finally, the weapons systems have high-range, perhaps hihat loops, that crescendo as the weapon charges, dropping back to no volume after firing.

This combination of music and sound effects should provide a fantastic tension in the game, and should help greatly in keeping the game world fun and interesting during play.

Server

The server will be a node server that compiles and serves client assets on the fly, alleviating a need for a compilation step during development. The server will run the actual game state and update code, being responsible for calculating all physics in the game. It will not handle AI - that will be the responsibility of AI aware browser consoles.

Code

Code will be written in CoffeeScript, Jade, Stylus, and Web GLSL.

Phases

This doc describes a hugely ambitious project, on par with a AAA game title. Without a large team, these phases should get us through some basics to a minimum viable product, and hopefully build some excitement.

MVP

  1. Earth, Navigation, Viewscreen. The viewscreen will have several views out from the ship's location. The ship will be in orbit, and navigation will be able to guide the ship between orbits. Game state must be in a module portable between the browser and Node, as it will run in both places.
  • Earth: A sphere with a texture.
  • Viewscreen: Show the Earth, with a starfield skybox and orbital projection.
  • Navigation: Schematic representation of Earth and ship, orbital projection, and ship rotation controls.
  • The conn shows as an overlay on top of the Viewscreen.
  1. Moon, Improved Navigation. Adding a second body to the system allows a much wider variety of navigational options.
  • Moon: Second sphere with texture. Basic system physics (treat as inertial frame, only calculate 3-body for the craft).
  • Improved Navigation: add Burn Plan to Conn.
  1. Networking. The Viewscreen can and should be run on a dedicated high-graphics client, allowing the consoles to run from lower-powered clients. The different ship consoles will communicate through a server backend to maintain state.
  • Networking: The Viewscreen and Conn will connect over sockets to a node server. The node server will handle game state updates, pushing new state to the various connected consoles. The consoles will render normally.
  1. Tactical, AI Ship. Adding an AI enemy and combat allows the core gameplay to begin play. Minimal tactical is beam weapons and hull damage only.
  • AI Ship: Mesh, texture, and shader assets. AI can navigate, either station keeping or seeking. Weapons fire every N seconds(?).
  • Tactical: Beam graphics, basic ship targeting (point and click), beam range and weapon cooldown. "Fire!"
  1. Mars, Sol. Adding a second planet and the star to the system finishes the minimum core of the game.
  • Mars, Sol: Assets
  • Physics: Move inertial planetary systems to stellar system. To simplify physics, all body orbits will be parameterized to a closed form elipse. Only vessel calculations then need be computed, since everything else is "static", at least orbitally.
  1. Procedural System Generator. With parameterized base stars, planets, and moons, we can generate a variety of systems to test gameplay and system performance. These won't be completely random, but seeded from known star and planet catalogs of the local stellar neighborhood. Alderson Tramlines to jump between systems.

At this point, we have two (three?) working consoles, all the basics of ship combat, and could begin playing single-player games.

Basic Game

  • System Jumps
  • Navigation Continued play testing and improvements.
  • Tactical
    1. Exotic Weapons
    2. Shields
    3. Subsystems
  • Engineering
    1. Power management
    2. Damage control
    3. Ship improvements
  • Science
    1. System scanning
    2. Ship scanning
  • Combat

Fleets

  • Communication
  • Fleets
    1. Fleet navigation
    2. Fleet formations
    3. Fleet combat - just multiship combat? Lots of AI work.
  • Fleets 2
    1. Resources
    2. Installations
    3. Ship construction
    4. Ship research

Full Game

  • Engagements Large scale set pieces, composed of several objectives. About 45 minutes' worth of playable content per engagement.
  • Campaigns Groups of engagements with a good story and progression. Should shoot for about 10 hours of playtime, ~14 engagements.

Lore

Like any good Sci-Fi, it needs a great backstory and lore.

Science

[Start with a current understanding of science and physics. Game designers can extrapolate potential developments, but should base those in current science knowledge.]

New Science

  • Lithinides Lithinides are an invention and discovery in the late 21st century. By creating ceramics with a lithium/berylium mixture, the neutrons released in fusion reactors induce a charge directly in the lithinides, skipping the typical heat converter phase for power generation, allowing nearly direct power generation from fusion sources.

Technology

Ship Size

[Based on current US Naval vessels] Heavy cruisers displace on the order of 10^8 Kg when loaded.

Power

Fusion power, generally in the form of Hydrogen burning, is the primary power source on ships. With the invention of "Lithinides" - superconducting Lithium alloys - humanity harnessed the fusion of stars, extracting relatively large amounts of energy from Helium-3 sources. Current starship reactors generally produce ~100MWH per gram of 3He. Wiki says max hypothetical from 3He reactions is 493MWH from 3 grams of 3He. Starship power plants are generally rated in the 10 to 100 Gigawatt range. Accelerating 1e9kg at 1 Earth gravity works out to about 5 GW of power out of the thruster. This energy is generated from Tokamak fusion plants on the vessel - this is on scale with the DEMO planned production tokamak.

Propulsion

Starship propulsion systems generally work on a variety of electrical propulsion systems. Assuming 1/10 the acceleration would be needed for rotational torque, the maneuvering engines should be Hall Effect Thrusters, and the main engine a Plasma Jet Thruster. To accelerate a vessel at interplanetary speeds, the main engines must be capable of sustained 1g accelerations on vessels, with peak 3g output for short bursts. Thus, the main engines of a typical cruiser (mass 100Gg) must produce at least 1 and peak 3 TeraNewtons of thrust.

Weapons

Lasers - Given the state of the art at NIF (Lawrence Livermore) 2MJ beams should be baseline. Laser are in two forms - point defense, to quickly swivel and target incoming projectiles, and heavy, to target specific portions of an enemy's hull.

Missiles - Small tubes of solid propellant with vectored thrust nozzles for guidance. Fire swarms, hoping some hit. Kinetic damage alone will be sufficient. Designed to be small and fast enough to slip past laser point defense, but large enough to still have mass to cause damage on impact.

Exotic - EMP detonations. Torpedoes - Large, "slow" missiles with warheads to demolish bases after their Point-Defense lasers are damaged.

Armor - Explosive Reactive Armor on the order of dissipating a projectile with 10^12 joules energy. See for instance kontakt-5. Other reactive armor concepts exist. Possibly ablative armor for heavy lasers?

History

Inspirations

Similar Games

(and why they don't scratch my itch)

Long story short, none of these have the level of realism I'm looking for. I want the mix of my favorite parts of these three.

  • Kerbal Space Program Awesome Space Sim - accessible, yet challenging. Physics are incredibly realistic. Doesn't use actual space sizes. No space combat. Control is a single craft. Not a Space Opera.
  • Artemis Bridge Commander Control entire ship, but no overarching realism. Encounters only, no grand space opera. No fleet level control.
  • Sins of a Solar Empire Great scope and campaign. Lack of realistic physics. Great tech tree, but fleet command only - no consoles for coop Artemis style play.
  • Faster Than Light Really good example of ship micro, but turn based; no physics.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment