A Combat System proposal

jake R shared this feedback 22 hours ago
Not Enough Votes

Marek's blog post


SPACE ENGINEERS 2 – COMBAT SYSTEM DESIGN PROPOSAL A Systems-Based Approach to Ship Combat



1. OVERVIEW Traditional combat systems in sandbox building games often rely on simplified hitpoint-based damage models. While functional, these systems limit the depth of engineering decisions and reduce combat to numerical exchanges.

This proposal outlines a systems-driven combat model where survivability is determined by the interaction of multiple mechanics:

  • armor design
  • weapon roles
  • heat management
  • signature and detection

The goal is to transition combat from a health pool model to a dynamic engineering system where ship design directly influences combat performance.

Rather than treating ships as static objects with durability values, this system treats them as engineered machines. Protection, detectability, heat load, power demand, and combat effectiveness all emerge from how a ship is built and how it is operated.



2. ARMOR SYSTEM2.1 OPTION 1Armor is defined by three critical attributes:

  • armor value
  • health points
  • angle of armor relative to the incoming threat

Armor value represents resistance to penetration. Health represents the ability of the armor to sustain repeated impacts. The angle of impact determines how effective that armor is against incoming fire.

Armor blocks stack armor value across layers. Each block behind another contributes to the total resistance that a projectile must overcome. This stacking behavior is a core part of the system and must be carefully balanced.

A baseline example of this balance would be:

  • three small-grid heavy armor blocks thick equals one large-grid heavy armor block over the same surface area
  • large blocks provide slightly better efficiency per surface area, for example around ten percent, making them more PCU-efficient while preserving functional equivalence

This creates a natural incentive toward midsize and large ship construction while maintaining consistency across grid scales.

Each weapon has both a penetration value and a damage value. When a projectile impacts armor, the system evaluates:

  • total stacked armor value
  • weapon penetration value
  • impact angle

The angle-based system introduces a scaling check:

When a round impacts armor, the system evaluates whether the angle is sufficient to allow penetration or force deflection. This is determined by comparing the effective armor thickness, increased by angle, against the weapon’s penetration value.

At shallow angles, armor becomes more effective due to increased effective thickness. At more extreme angles, penetration becomes increasingly unlikely. Beyond a defined threshold, the projectile enters a deflection condition and is unable to penetrate regardless of raw penetration value.

This creates three functional regions:

  • penetration region
  • degradation region
  • deflection region

This system allows armor geometry and ship design to directly influence survivability.

Armor resistance represents a reduction in damage received. Health represents the ability of the armor to sustain repeated impacts. The angle of impact determines how effective that armor is against incoming fire based on set angles of impact that have a chance to bounce or deal damage depending on weapon used and the armor being impacted.



2.2 OPTION 2 — ANGLE-BASED ARMOR SYSTEMArmor is defined by three primary attributes:

  • Damage Resistance
  • Health Points
  • Impact Angle Relative to Incoming Threat

Each weapon is defined by two key parameters:

  • Damage Value
  • Penetration Angle Presets (per armor type)




IMPACT EVALUATION

When a projectile impacts armor, the system evaluates the following:
  • Stacked Armor Resistance
    (e.g., two armor blocks in depth provide increased resistance to connected blocks, such as +50%)
  • Weapon Penetration Angle Thresholds
  • Impact Angle




ANGLE-BASED INTERACTION

The system performs an angle-based check to determine the outcome of the impact.

At shallow impact angles, armor effectiveness increases due to higher effective thickness.

As the impact angle becomes more extreme, the likelihood of penetration decreases.

Beyond a defined threshold, the projectile enters a deflection condition and is unable to penetrate regardless of weapon damage.




INTERACTION STATES

This results in three functional regions:
  • Penetration Region
    The projectile penetrates and applies full damage.
  • Degradation Region
    The projectile penetrates but deals reduced damage due to angle and resistance.
  • Deflection Region
    The projectile is unable to penetrate and deals no damage.




POST-PENETRATION MODEL

If a projectile successfully penetrates, it transitions into a health-based penetration model.

Each projectile is assigned a remaining penetration health after initial impact.

As the projectile travels through armor, this value is reduced based on:

  • Armor resistance
  • Number of blocks penetrated

The projectile continues penetrating through successive blocks as long as it retains remaining health. Once the projectile’s health is depleted, penetration stops.

If the projectile has explosive properties, it will detonate at the point where its remaining health reaches zero or upon impact conditions defined by the weapon.




SYSTEM ROLE

This system allows armor geometry and ship design to directly influence survivability.
  • Damage Resistance reduces incoming damage.
  • Health Points determine how much damage the armor can sustain over time.
  • Impact Angle governs the effectiveness of the armor during each interaction.
  • Projectile Health determines how deeply a successful hit can penetrate into the structure.



2.3 ARMOR COATINGSCoatings are applied using a dedicated block upgrade tool that functions similarly to the paint system.

Coatings introduce additional behavior layers on top of base armor without changing the underlying block.

Examples include:

  • titanium plated — increases armor value
  • signature absorbent coating — reduces the signature contribution of the block
  • depleted uranium coated — increases armor value and increases mass

This system allows armor to be tuned for different roles such as survivability, stealth, or density, without requiring entirely new block types.



3. WEAPON SYSTEMWeapons are defined by size restrictions, role, and heat generation.

Each weapon system exists within a defined role rather than acting as a general-purpose solution.

  • Kinetic weapons focus on penetration and physical damage transfer.
  • Energy weapons are divided into two distinct categories:
  • capital-class energy weapons such as railguns designed for large ships
  • small point defense systems designed for tracking and interception

Sustained kinetic weapons provide either continuous fire with lower penetration values but consistent pressure over time or high damage high penetration at the cost of reload and power consumption.

Each weapon system is balanced through:

  • penetration capability
  • damage output
  • heat generation

Weapons are not only defined by damage but by how they interact with armor and heat systems.



4. HEAT MANAGEMENT SYSTEMAll active systems generate heat. This includes:

  • thrusters
  • weapons
  • industrial blocks
  • power systems

Each system has both natural heat generation and natural heat dissipation.

Some systems, such as reactors, include onboard dissipation allowing them to operate under moderate loads without overheating. However, under maximum load, additional cooling systems are required.

Weapons generate significant heat but have very low natural dissipation. This requires external systems to manage sustained firing.

The heat system is designed to sit on top of all other systems as a secondary layer. It is not intended to dominate gameplay, but it introduces meaningful tradeoffs.

One of the most important interactions is that heat directly increases signature. A ship operating at maximum output across all systems will generate significantly higher signature compared to one operating efficiently.



4.1 HEAT DISSIPATION SYSTEMSActive CoolingActive cooling uses dedicated heat exchanger blocks:

  • operates similarly to batteries
  • pulls heat directly from the grid
  • processes and removes heat

These systems require water or ice as a resource, either through direct tank connection or integration with H2/O2 generators.

Heat exchangers are designed to handle large heat loads from:

  • reactors
  • weapons
  • industrial systems

Depending on operational load, multiple units may be required.



Passive CoolingPassive cooling is handled through radiator blocks:

  • must be placed on the exterior of the ship
  • continuously dissipate heat
  • require no power or resources

Radiators should be similar in size and form factor to solar panels, allowing them to be integrated into ship hulls without significantly altering shape.

They are effective for low to moderate heat loads and serve as a baseline cooling system.



5. RADAR, SIGNATURE, AND SCANNING SYSTEMAll blocks that consume or produce power generate signature.

Signature represents how detectable a ship is based on its current operational state.

Signature sources include:

  • thrusters
  • reactors
  • weapons
  • industrial systems

Signature scales dynamically based on usage.



5.1 ENVIRONMENTAL SIGNATURE MODIFIERSSignature and detection are influenced by environmental conditions, introducing spatial gameplay elements and encouraging tactical positioning.




Asteroids

  • Within 50 meters of an asteroid surface:
  • Signature reduced by approximately 80%
  • Inside an asteroid:
  • Signature reduced by 80–90%, or fully masked

Asteroids act as hard occlusion and stealth structures.




Asteroid Fields and Belts

  • Detection range reduced due to interference
  • Signature clarity degraded
  • Signature reduced by an additional 20–50%

This creates areas where sensor reliability is reduced, encouraging close-range engagements and tactical maneuvering at closer ranges.




Gas Clouds / Volumetric Regions

  • Apply global signature reduction
  • Reduce sensor range and accuracy




Planetary Environments

  • All signature reduced by approximately 90%



Sub-Surface / Threshold Layer

  • Below defined altitude or terrain layer:
  • Signature reduced by up to 99%, or fully masked



5.2 SIGNATURE CALCULATION SYSTEMS_total = Σ(B × O × A × H × T × M)

Where:

  • B = base signature value
  • O = output level
  • A = activity state
  • H = heat modifier
  • T = tech modifier
  • M = miscellaneous modifiers

Environmental modifiers are applied after base calculation.



Base Values (Example)

  • small thruster = 2
  • medium thruster = 25
  • large thruster = 150
  • 7.5m thruster = 1000
  • 1m reactor = 200
  • solar = 0



Example Ship BaselineA corvette-scale ship produces approximately:

6950 signature



Detection FormulaD = (S_total × C) / (R² × E)

Where:

  • C = sensor strength
  • R = range
  • E = environmental factors



5.3 SCANNING SYSTEM — PASSIVE AND ACTIVE DETECTION



PASSIVE SCANNINGAll ships are inherently equipped with passive scanning.

  • Based on ship X, Y, Z dimensions
  • Larger ships have larger passive scan profiles




Detection Behavior

At long range:
  • Directional cone only
  • No exact position
  • Minimal data

At closer range:

  • Expands into localized bubble
  • Provides:
  • approximate size
  • signature level
  • active systems (reactors, large weapons, etc.)




Resolution Scaling

Detection quality increases with:
  • target signature
  • proximity



ACTIVE SCANNINGActive scanning emits a scan pulse:

  • dramatically increases own signature
  • exposes the scanning ship




Risk vs Reward

  • Improves detection clarity
  • Makes the scanner more detectable
  • Targets may gain better resolution on the scanner



ACTIVE SCAN MODES


Omnidirectional (360°)

  • Full-area scan
  • Highest signature spike


Directional Cone Scan

  • Focused scan on a detected signal
  • Higher resolution
  • Lower exposure than full scan



TARGET LOCALIZATION MODELTargets are not presented as exact positions.

  • Directional cones for distant signals
  • Localized bubbles for closer signals

Players must interpret detection data rather than rely on exact markers, at least until the target is within combat distance.



6. SYSTEM INTEGRATIONAll systems are interconnected:

  • heat increases signature
  • weapons generate heat and spike signature
  • thrusters increase heat and signature under load

Detection, survivability, and combat effectiveness emerge from the interaction of these systems.



7. DESIGN OUTCOMESThis system creates emergent gameplay driven by engineering decisions.

Ships naturally specialize based on how systems are balanced:

  • stealth vs power
  • armor vs mobility
  • sustained combat vs burst capability

Ship design becomes the defining factor in combat performance.



8. CONCLUSIONCombat is no longer defined by hitpoints.

It becomes an engineering problem where design, operation, and system interaction determine survivability and effectiveness.

Ship design decisions become as important as player skill.

Replies (3)

photo
1

Wow, there is a lot to unpack here, but there are definitely some good concepts inside.

I do like adding armor angle to the damage calculation and allowing for full (non-damaging) deflection at certain angles.

I've been long asking for something along the lines of 'penetration value', essentially a method where you need a certain size/class of weapon to damage certain armor. Something like ship 'heavy armor' should not take any real damage from personal handheld weapons. You'd need heavier ship weapons to really do any real damage to armored parts of a ship.

photo
photo
1

Given the likely structure of the armor blocks, as inferred from their calculated density, it is unlikely that a projectile would be deflected. Only projectiles from small arms, or at most rounds from 20mm Gatling guns, can be deflected; everything else will penetrate the interior of the armor block regardless of the angle of impact.

photo
2

Wow, such a detailed suggestion.

It took me a while to go through it.

The TL;DR would be: ship design should matter for combat. And that’s absolutely true. Systems like weapon effectiveness against different blocks, heat generation, and scanning/radar should all create meaningful trade-offs and balance.

Armor angles and layers

The main issue here is reduced creative freedom. There are so many shapes people want to build, but this would push designs toward very pointy, optimized forms.

Some kind of shield system might be more versatile. It shouldn’t just absorb damage, but rather deflect or slow projectiles so they either miss or deal reduced damage, depending on emitter placement. Maybe shields could even be tuned in real time to counter specific threats (projectiles vs energy weapons), which would make multi-crew ships more meaningful.

As for layered armor, I’m not a big fan. It tends to inflate PCU usage, increase mass, require more thrusters and fuel, and make ships harder to build and repair. Armor coatings, however, sound like a good idea—different types effective against different weapons.

Heat

Heat management is 100% needed, and not just for combat.

It’s a great natural limitation on how many weapons you can run on a grid. But if you add radiator or heat exchanger blocks, you risk bypassing that limitation—people will just spam both guns and radiators. Instead of gun bricks, we’ll get gun/radiator bricks 🙂

That said, heat as a system has huge potential. It’s naturally harder to dissipate heat in space than on planets or near water, which creates interesting gameplay differences. Planetary bases (especially water-cooled ones) could have major advantages in sustained firepower.

Large ships might be the only ones able to handle nuclear reactors. Internal thrusters could become inefficient due to heat buildup. Batteries and capacitors would matter more. Preparing for combat would matter more. Even mid-battle repairs could be a trade-off if welders generate significant heat.

Radars / Scanners

As mentioned in Marek’s blogpost, players should be able to see what’s happening, adapt, and apply strategy.

I like many of your ideas, though I’m not sure how cleanly all of them can fit into the game. In general, I’d like clearer, more useful information:


  • Incoming missiles with time-to-impact
  • Enemy ship classification (size categories via icons)
  • Weapon loadout (e.g. railguns x4, gatlings x8, missile launchers x2)

At the same time, the HUD shouldn’t get too cluttered. Basic info could be shown as small icons, with more detail appearing when you focus on a specific target. Also, icons shouldn’t block the actual grid like they do now.

More advanced info could require scanner blocks. You might need to actively scan a target to get detailed data, which is then shared with allies. Even if you can’t see the enemy visually (e.g. at 2 km), you could still track their status through scans. This also adds more reasons to for having multi-crew ships.

Detection should definitely be part of the game. Terrain could act as natural cover, encouraging things like early warning systems. The same applies to asteroids and voxel environments in general—they should play a bigger gameplay role, not just be visual. Different environments (rings, atmospheres, asteroid clusters) could also affect speed/acceleration/max speed.

Planets

I think we can all agree—they look beautiful. And they should play a bigger role in gameplay.

It’s naturally easier to locate a base on a planet than in deep space, so there should be advantages to compensate for that, as well as for dealing with gravity. Heat management is one of them, but there could be more.

I’m not a big fan of safe zones as they are now. Instead, powerful shield emitters that generate a lot of heat (but are manageable on planets) could make more sense. Planetary bases should have clear advantages:


  • Higher sustained firepower
  • Cheaper construction
  • Thick, durable defenses (e.g. concrete structures)
  • Better repair capabilities

Concrete-like materials could be heavy and impractical for ships (or even not allowed), but ideal for bases. Large (XL) blocks could also help reduce PCU usage. Breaching a well-defended base should be very challenging—you’d need a significantly larger attacking force.

This could also encourage alternative tactics like infiltration instead of brute force, especially against NPC stations.

Safe zones could still exist, but in a more limited role. For example:


  • Preventing voxel changes (to stop underground tunneling)
  • Acting as personnel inhibitors

They shouldn’t require constant grid for Uranium or SF Chips. Instead, they could use reasonable energy, or even be split into separate functional blocks (inhibitor can be a separate dedicated block)

If offline raiding is a concern, there’s no perfect solution. But stronger base defenses would help: higher sustained firepower, shield emitters, cheap and durable "armor", auto-repairs, terrain advantages, etc. With enough preparation, attacking should still be possible—but not trivial. Even same weapons can have longer range if placed on static grid.

There will always be edge cases and “clever” exploits, especially against offline players. You can patch those over time, but there’s always a balance between realistic mechanics and preventing unfair gameplay. If SE1 managed it to some extent, SE2 should be able to as well.

photo
1

all great feedback what id also say though is that not every ship is designed for combat but the well built ones will use the conventional building techniques to really harden the ship- you can also balance the use of the armor by making them weigh significantly more and some other things- heat exchangers could use alot of power so much so that it could be a hard limit on the amount of them you could have vs size you could even make the size of the block like a 1x2 large blocks to limit the space- the system is designed to allow for deeper building if you want to and if not you dont have to then the game plays generally the same

photo
Leave a Comment
 
Attach a file
You can't vote. Please authorize!
You can't vote. Please authorize!