A Combat System proposal
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.
I like this feedback
SDX at least tries to do something interesting with combat, and to do so they basically have to create an entirely separate combat system. As gruller65 said, it is much harder to make good combat system as a mod because the base game combat system is limited, and they also need much larger engagement ranges. Not that I think we need very long ranges in vanilla game (this is just to make it in line with Expanse Universe), but the base game combat system lack a lot features that you can use to base your mod on, including also simple things like targeting UI and all other things that gruller65 and others have enumerated as potential improvements.
I think there can be a way to create much more interesting combat mechanics in a sandbox game. But “building your own weapons” will not help with that — it can only make balancing even harder. I mean, what would you even balance if there are no defined weapons to begin with? People will quickly discover the single best overpowered setup. Then, if you change something, they will simply invent and switch to another one.
I strongly believe that the number of weapon types should be very limited. Ideally, there would be something like three weapon categories forming a simple rock-paper-scissors triangle. Then you could have different sizes or more advanced versions of those same weapon types.
The balancing should work in a way where putting all three weapon types equally on the same ship makes that ship mediocre at everything. This would naturally encourage players to build ships that excel in one or two areas, but not all three. If the server meta shifts toward certain ship types, players will immediately start building other types to counter the majority, and the system will begin to self-balance.
That is basically Combat Design 101, and it is already quite difficult to achieve in a sandbox game. If you add too many variables into a system where players have absolute freedom to build whatever they want, it becomes almost impossible to meaningfully control or tweak the balance.
SDX at least tries to do something interesting with combat, and to do so they basically have to create an entirely separate combat system. As gruller65 said, it is much harder to make good combat system as a mod because the base game combat system is limited, and they also need much larger engagement ranges. Not that I think we need very long ranges in vanilla game (this is just to make it in line with Expanse Universe), but the base game combat system lack a lot features that you can use to base your mod on, including also simple things like targeting UI and all other things that gruller65 and others have enumerated as potential improvements.
I think there can be a way to create much more interesting combat mechanics in a sandbox game. But “building your own weapons” will not help with that — it can only make balancing even harder. I mean, what would you even balance if there are no defined weapons to begin with? People will quickly discover the single best overpowered setup. Then, if you change something, they will simply invent and switch to another one.
I strongly believe that the number of weapon types should be very limited. Ideally, there would be something like three weapon categories forming a simple rock-paper-scissors triangle. Then you could have different sizes or more advanced versions of those same weapon types.
The balancing should work in a way where putting all three weapon types equally on the same ship makes that ship mediocre at everything. This would naturally encourage players to build ships that excel in one or two areas, but not all three. If the server meta shifts toward certain ship types, players will immediately start building other types to counter the majority, and the system will begin to self-balance.
That is basically Combat Design 101, and it is already quite difficult to achieve in a sandbox game. If you add too many variables into a system where players have absolute freedom to build whatever they want, it becomes almost impossible to meaningfully control or tweak the balance.
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.
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.
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.
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.
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:
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:
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:
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.
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:
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:
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:
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.
So a few things to break down here.
Armors and armor resistances: Stuff like this already exists in SE though isn't always directly implemented. Assuming similarity to SE it's as easy as going in and putting a damage multiplier value on blocks. In fact it's one of the way I balanced my Duramax Armor. In order to achieve the durability I could've added more components adding to weight which I didn't want to do. The final solution was a combo of setting health and a damage resistance both. For default purposes the only question is how Keen implements it. For modders so long as they can set those values easily enough there's no issue.
Angled impacts of weapons: So this is where we start getting into a calculations nightmare potentially. This already exists somewhat in SE1 and could be done in 2. If you've ever seen videos of fights or paid attention in your own, sometimes you'll see projectiles fly off a sloped armor block. If you get a good enough hit on something like an artillery or assault cannon shell they're the best examples imo. The issue with some of your more detailed bits you proposed is that you risk getting into a calculations nightmare that can really bog the combat down. You don't need much beyond basic angle deflection calculations to have good combat for that sort of thing. Then there is the quagmire of having to take account potentially different coatings which there are no need for.
Heat: this is an automatic and hard no from me as you've proposed it here for a number of reasons. First is that while you may legitimately enjoy the idea of it, such a thing will be instantly weaponized to punish "wrong build" or people who build in ways that other people don't like. Prime example being people who constantly whine about so called "gun bricks" even though they never define what exactly constitutes a gun brick. So long as people put in the proper engineering to make said "gun brick" work I don't care if they have 5 weapons or 5000 weapons on the ship. No ship is ever unbeatable or invincible.
Another big issue is that there are no positives to this system at all, only downsides. To give an example, while I would expect a reactor to potentially get less efficient as it gets hotter or potentially even shuts down (assuming auto shut off is a thing), there is no benefit to having additional cooling beyond what is required. To quantify for discussion sake, let's suppose that a reactor under regular operation is between 25-75 heat units with 100 being auto-shutoff, and 0 being it not on at all. Let's suppose for an average ship that reactor operates at around 50 heat units under standard load and provides normal power at normal efficiency rate. Let's suppose I'm able to push the heat generation of the reactor down to say 15 units for a normal load, I would expect the reactor to have a slightly increased efficiency at its job. Yet I get nothing like that. It's basically "use these radiators because I said so or suffer the consequences" and there is no positive benefit to heat. I can't make stuff more efficient with extra cooling, I can't weaponize said heat into flamethrower type turrets to repel boarding parties, or similar.
When designing stuff for games, whether it be the full on AAA studio level or small time modder stuff, you have to answer a few questions. The big ones are "why would I ever want to go there" for maps, and in this case for the system of heat "why would I ever want to use this." While you can certain go the route of "because if you don't you'll melt your ship" and leave it there, that's not going to be interesting gameplay to most people. Kind of like trying to sell someone a used car at a car lot but only focusing on what's wrong with the car and never talking about anything positive. In this instance you've already defined your downsides, now you need some benefits. See previous examples of perhaps using flame turrets, or making certain blocks more efficient beyond that norm. It doesn't have to be an extreme double efficiency or anything, but a respectable something. Again just to quantify let's say 10% to get a starting point. Now you are giving people proper tradeoffs. In exchange for managing heat and using the system and dealing with said downsides, they in turn get extra efficiency and flame turrets. This is a very rough example but you get the idea. As a developer/creator of something, if you as the creator can't give people sufficient reasons to want to use it, you can't expect them to come up with reasons on their own. Nor can we make people play in ways they don't want to play either because they'll either just find a workaround, or flip us the bird and not use our stuff at all.
Now a final chief reason heat is a bad idea is because it will dominate every build and become mandatory, which is something you said yourself you want to avoid. In order to survive, people now have to build with radiators and heat in mind or else. If you're someone who hates "gun bricks" as some say, now you've just added radiators to the mix as you know good and well people will just slap extra radiators and such on until they can run their 5k weapons again. So you're not stopping anything at all, just changing the form it takes. If people want to limit the amount of weapons a grid can hold, server owners already have tools for this and can limit them based on block type IDs assuming they keep similar setups to SE1.
Radars: I'm not opposed to better detection methods within reason. However this can quickly become a quagmire of people arguing over irrelevant details and using it as a griefing tool. Better detection methods on their own can very quickly be abused to hunt down potential victims in a pvp scenario and used to gank those who are simply nowhere near the already established players in terms of level and infrastructure. There would need to be some safeguards in place so people could get info but it doesn't become an automatic "I win" or "I know everything about you" sort of thing.
Overall there are other ways to balance combat. No two servers are likely to be the same once we get down to it.
So a few things to break down here.
Armors and armor resistances: Stuff like this already exists in SE though isn't always directly implemented. Assuming similarity to SE it's as easy as going in and putting a damage multiplier value on blocks. In fact it's one of the way I balanced my Duramax Armor. In order to achieve the durability I could've added more components adding to weight which I didn't want to do. The final solution was a combo of setting health and a damage resistance both. For default purposes the only question is how Keen implements it. For modders so long as they can set those values easily enough there's no issue.
Angled impacts of weapons: So this is where we start getting into a calculations nightmare potentially. This already exists somewhat in SE1 and could be done in 2. If you've ever seen videos of fights or paid attention in your own, sometimes you'll see projectiles fly off a sloped armor block. If you get a good enough hit on something like an artillery or assault cannon shell they're the best examples imo. The issue with some of your more detailed bits you proposed is that you risk getting into a calculations nightmare that can really bog the combat down. You don't need much beyond basic angle deflection calculations to have good combat for that sort of thing. Then there is the quagmire of having to take account potentially different coatings which there are no need for.
Heat: this is an automatic and hard no from me as you've proposed it here for a number of reasons. First is that while you may legitimately enjoy the idea of it, such a thing will be instantly weaponized to punish "wrong build" or people who build in ways that other people don't like. Prime example being people who constantly whine about so called "gun bricks" even though they never define what exactly constitutes a gun brick. So long as people put in the proper engineering to make said "gun brick" work I don't care if they have 5 weapons or 5000 weapons on the ship. No ship is ever unbeatable or invincible.
Another big issue is that there are no positives to this system at all, only downsides. To give an example, while I would expect a reactor to potentially get less efficient as it gets hotter or potentially even shuts down (assuming auto shut off is a thing), there is no benefit to having additional cooling beyond what is required. To quantify for discussion sake, let's suppose that a reactor under regular operation is between 25-75 heat units with 100 being auto-shutoff, and 0 being it not on at all. Let's suppose for an average ship that reactor operates at around 50 heat units under standard load and provides normal power at normal efficiency rate. Let's suppose I'm able to push the heat generation of the reactor down to say 15 units for a normal load, I would expect the reactor to have a slightly increased efficiency at its job. Yet I get nothing like that. It's basically "use these radiators because I said so or suffer the consequences" and there is no positive benefit to heat. I can't make stuff more efficient with extra cooling, I can't weaponize said heat into flamethrower type turrets to repel boarding parties, or similar.
When designing stuff for games, whether it be the full on AAA studio level or small time modder stuff, you have to answer a few questions. The big ones are "why would I ever want to go there" for maps, and in this case for the system of heat "why would I ever want to use this." While you can certain go the route of "because if you don't you'll melt your ship" and leave it there, that's not going to be interesting gameplay to most people. Kind of like trying to sell someone a used car at a car lot but only focusing on what's wrong with the car and never talking about anything positive. In this instance you've already defined your downsides, now you need some benefits. See previous examples of perhaps using flame turrets, or making certain blocks more efficient beyond that norm. It doesn't have to be an extreme double efficiency or anything, but a respectable something. Again just to quantify let's say 10% to get a starting point. Now you are giving people proper tradeoffs. In exchange for managing heat and using the system and dealing with said downsides, they in turn get extra efficiency and flame turrets. This is a very rough example but you get the idea. As a developer/creator of something, if you as the creator can't give people sufficient reasons to want to use it, you can't expect them to come up with reasons on their own. Nor can we make people play in ways they don't want to play either because they'll either just find a workaround, or flip us the bird and not use our stuff at all.
Now a final chief reason heat is a bad idea is because it will dominate every build and become mandatory, which is something you said yourself you want to avoid. In order to survive, people now have to build with radiators and heat in mind or else. If you're someone who hates "gun bricks" as some say, now you've just added radiators to the mix as you know good and well people will just slap extra radiators and such on until they can run their 5k weapons again. So you're not stopping anything at all, just changing the form it takes. If people want to limit the amount of weapons a grid can hold, server owners already have tools for this and can limit them based on block type IDs assuming they keep similar setups to SE1.
Radars: I'm not opposed to better detection methods within reason. However this can quickly become a quagmire of people arguing over irrelevant details and using it as a griefing tool. Better detection methods on their own can very quickly be abused to hunt down potential victims in a pvp scenario and used to gank those who are simply nowhere near the already established players in terms of level and infrastructure. There would need to be some safeguards in place so people could get info but it doesn't become an automatic "I win" or "I know everything about you" sort of thing.
Overall there are other ways to balance combat. No two servers are likely to be the same once we get down to it.
The more the game's physics deviate from real-world physics, the worse it gets. The more nonsensical—in the sense of unrealistic—rules you come up with, the sooner and more strongly solutions will emerge that you didn’t anticipate or expect.
What many call “gun spam” is one such manifestation. It is the result of small, light, and cheap ships trying to stand up to large, powerful, and expensive ships in battle. Simply put, the builders of large ships did what makes sense—they increased the number of weapons effective against light ships.
Is that nonsensical? No!
It is not nonsensical. Exactly the same development took place in the Pacific theater during World War II. The number of light anti-aircraft guns on battleships increased many times over.
USS California (BB-44) (as build in 1919)
USS West Virginia (BB-48) (as build in 1921)
And as for the would-be Richthofens: show me at least one instance where a lone fighter pilot managed to damage a large warship. Lone = without the support of dozens of other aircraft.
The more the game's physics deviate from real-world physics, the worse it gets. The more nonsensical—in the sense of unrealistic—rules you come up with, the sooner and more strongly solutions will emerge that you didn’t anticipate or expect.
What many call “gun spam” is one such manifestation. It is the result of small, light, and cheap ships trying to stand up to large, powerful, and expensive ships in battle. Simply put, the builders of large ships did what makes sense—they increased the number of weapons effective against light ships.
Is that nonsensical? No!
It is not nonsensical. Exactly the same development took place in the Pacific theater during World War II. The number of light anti-aircraft guns on battleships increased many times over.
USS California (BB-44) (as build in 1919)
USS West Virginia (BB-48) (as build in 1921)
And as for the would-be Richthofens: show me at least one instance where a lone fighter pilot managed to damage a large warship. Lone = without the support of dozens of other aircraft.
There is a concept known as "muzzle power" – this is the total energy of the projectiles fired by a weapon per unit of time. This muzzle powery is directly related to the weapon’s recoil.
It is therefore possible to define the minimum power of the gyroscopes (and motors) and the minimum mass of the ship required to absorb the recoil and stabilize the ship during weapon firing.
Suppose that absorbing a muzzle power of 1 MW requires 1 ton of ship mass and the power of a single "medium-sized" gyroscope (intended solely for absorbing the weapon’s recoil, not for other purposes).
Let a theoretical 20mm Gatling gun fire 100 projectiles weighing 200 grams each at a velocity of 1000 m/s per second. The muzzle power of the weapon will be 10 MW.
To absorb the recoil of a single Gatling gun, a light ship must therefore have a minimum mass of 10 tons and ten gyroscopes.
A large "gun spam" ship with thirty Gatling guns in turrets would require a minimum mass of 300 tons and gyroscope power equivalent to three hundred medium-sized gyroscopes. A mass of 300 tons is not a problem for a large ship—but the gyroscope power represents a significant problem—and a hard limit.
There is a concept known as "muzzle power" – this is the total energy of the projectiles fired by a weapon per unit of time. This muzzle powery is directly related to the weapon’s recoil.
It is therefore possible to define the minimum power of the gyroscopes (and motors) and the minimum mass of the ship required to absorb the recoil and stabilize the ship during weapon firing.
Suppose that absorbing a muzzle power of 1 MW requires 1 ton of ship mass and the power of a single "medium-sized" gyroscope (intended solely for absorbing the weapon’s recoil, not for other purposes).
Let a theoretical 20mm Gatling gun fire 100 projectiles weighing 200 grams each at a velocity of 1000 m/s per second. The muzzle power of the weapon will be 10 MW.
To absorb the recoil of a single Gatling gun, a light ship must therefore have a minimum mass of 10 tons and ten gyroscopes.
A large "gun spam" ship with thirty Gatling guns in turrets would require a minimum mass of 300 tons and gyroscope power equivalent to three hundred medium-sized gyroscopes. A mass of 300 tons is not a problem for a large ship—but the gyroscope power represents a significant problem—and a hard limit.
There's to much to read here holy cow.
I get captainbladej52 point with the calculations required for ricochets though SE1 did something like this already, but I think Semtex says it better regarding the density of the blocks. For instance The Glacis Plate or front plate of the M4 Sherman has a density of around 7,850 kg/m^3 while the 0.5m heavy armor half block has a density of 1,515.68 kg/m^3 while being 4 times the thickness. That's a massive difference, heavy armor is like tin foil in comparison.
As for the whole heat management thing, I think it could be a good idea it just has to be done right. captainbladej52 kind of makes a decent point with the whole its not adding anything because there's "no positives". Though personally I think he's kind of making an ass out of himself, especially after the point natec made about conveyors having "no positives", other than it gives purpose to our designs. Despite that I do agree there needs to be a benefit to it like engine performance or reactor benefits which correct me if I'm wrong OP never said anything about there not being these types of benefits so I don't get the fuss about that. It could be a good idea just make the radiators take a small conveyor input for heat transfer, we use conveyors for everything already. As for the radar/heat sig thing idk about that it could work but it might be a trolling disaster when multiplayer becomes a thing.
That's just my bit happy engineering
P.S. @captainbladej52 your no Arbiter yourself your acting rather toxic because you to don't like something. You don't talk for all of us especially when you argue with someone where neither side is taking any points of reason from one another.
There's to much to read here holy cow.
I get captainbladej52 point with the calculations required for ricochets though SE1 did something like this already, but I think Semtex says it better regarding the density of the blocks. For instance The Glacis Plate or front plate of the M4 Sherman has a density of around 7,850 kg/m^3 while the 0.5m heavy armor half block has a density of 1,515.68 kg/m^3 while being 4 times the thickness. That's a massive difference, heavy armor is like tin foil in comparison.
As for the whole heat management thing, I think it could be a good idea it just has to be done right. captainbladej52 kind of makes a decent point with the whole its not adding anything because there's "no positives". Though personally I think he's kind of making an ass out of himself, especially after the point natec made about conveyors having "no positives", other than it gives purpose to our designs. Despite that I do agree there needs to be a benefit to it like engine performance or reactor benefits which correct me if I'm wrong OP never said anything about there not being these types of benefits so I don't get the fuss about that. It could be a good idea just make the radiators take a small conveyor input for heat transfer, we use conveyors for everything already. As for the radar/heat sig thing idk about that it could work but it might be a trolling disaster when multiplayer becomes a thing.
That's just my bit happy engineering
P.S. @captainbladej52 your no Arbiter yourself your acting rather toxic because you to don't like something. You don't talk for all of us especially when you argue with someone where neither side is taking any points of reason from one another.
Semtex-
"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."
... fascinating point, and makes sense. Small arms, compared to armor, ricochet off and wouldn't penetrate anyways with a direct hit, so from a gameplay perspective, the added CPU calculations are irrelevant.
Point 2: armor changes
A deductive syllogism for changing armor to have a different type of combat::
1. Combat is composed of gun-boxes firing at each other.
2. Introduce forced deflection on all rounds based on armor shape.
Therefore,
3. Players make gun-stars.
Conclusion,
4. Combat is composed of gun-stars firing at each other.
Not much really changed dude, just different shape and higher CPU loads. We need a 'creativity multiplier' thing for combat.
Heat - heat mechanics is backwards in space than atmo. Hotter things in space radiate at a better efficiency...to the 4th power...than cooler things. Just saying.
(Edit) Semtex - for the rifle recoil thing...we have gravity generators (with essentially inertia dampeners)...wouldn't that make weapon recoil not a thing with a couple of those...?
Semtex-
"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."
... fascinating point, and makes sense. Small arms, compared to armor, ricochet off and wouldn't penetrate anyways with a direct hit, so from a gameplay perspective, the added CPU calculations are irrelevant.
Point 2: armor changes
A deductive syllogism for changing armor to have a different type of combat::
1. Combat is composed of gun-boxes firing at each other.
2. Introduce forced deflection on all rounds based on armor shape.
Therefore,
3. Players make gun-stars.
Conclusion,
4. Combat is composed of gun-stars firing at each other.
Not much really changed dude, just different shape and higher CPU loads. We need a 'creativity multiplier' thing for combat.
Heat - heat mechanics is backwards in space than atmo. Hotter things in space radiate at a better efficiency...to the 4th power...than cooler things. Just saying.
(Edit) Semtex - for the rifle recoil thing...we have gravity generators (with essentially inertia dampeners)...wouldn't that make weapon recoil not a thing with a couple of those...?
All this debate about weapons and combat strikes me as a relentless effort to put builders of large ships with lots of weapons at a disadvantage. All in the name of some sort of "balance" or imagined "fairness" for builders of small ships.
Really?
A builder of large ships must invest a considerable amount of time and materials into building a large ship. An amount of time and materials many times greater than what is needed to build a small ship.
It is therefore right and fair that in battle, his investment of time and materials pays off in the form of victory.
All this debate about weapons and combat strikes me as a relentless effort to put builders of large ships with lots of weapons at a disadvantage. All in the name of some sort of "balance" or imagined "fairness" for builders of small ships.
Really?
A builder of large ships must invest a considerable amount of time and materials into building a large ship. An amount of time and materials many times greater than what is needed to build a small ship.
It is therefore right and fair that in battle, his investment of time and materials pays off in the form of victory.
Goodness there is a lot to go over here...
OP video/post:
-The proposition for armor sounds a fair bit like what we've got in SE1, except for weapons having different penetration-values and there being a "no damage deflection" value. I'm certainly all for making small-arms have reduced effectiveness against significant armor, but deflection really should be calculated as a percent chance of happening instead of just a garneted event. If deflection is garneted then there's a serious risk of bogging the game down in calculations when you fire a high rate of fire weapon in to something covered in spikes as the projectiles skip back and forth without hitting anything they could hope to penetrate in what should otherwise act as a sort of "shot-trap" that would at least degrade the armor at that point. I might also advise against trying to figure in durability augmentations based on adjacent armor blocks, as weapons thus far have all been of either the low-damage-point-n-spray with no penetration or single-high-damage-blows-through-several-layers kind of things. Unless Keen decides they need a middle-ground weapon in there I am uncertain having to calculate multi-layer thickness for penetrating shots will do anything more than add unnecessary calculations for the system to run in a fight.
-Why do we need to incentivize mid and large sized combat-ship construction more than SE1 already did? Small combat ships in SE1 already typically require the pilot to be an ace just to survive, they often run in to endurance issues (lots of fights they can't win because they can't carry enough ammo to kill a target), and the only incentives to using small ships in SE1 are reduced starting-cost and reduced after-combat maintenance (again assuming the ship survived).
-The coating thing is interesting, but it may be more practical to have subsets of blocks that simply have that property from the get-go, as otherwise you're tying part-usage and block-mass to a paint-tool that will absolutely break immersion for a lot of the more "hard-sci" players... On the other hand having a "block-replacement tool" that replaces the targeted block or group of blocks with identically shaped blocks possessing the chosen new properties without potentially splitting a grid would absolutely be something people would love to get their hands on, and would be far less of an immersion-issue as it effectively grinds down what's there and welds something new in its place.
-Size-restricting a weapon or block would be non-sensical. Things like ammo/fuel, block weight, block-size, or power-draw are easily defined and measurable values you can engineer a ship around. If a grid has them, the thrust to move it all around, and proper conveyoring, then it has everything it needs and so it very logically works, but "grid size"? How is the game to determine a grid's intended "size" vs where it got to be via outside factors? This is just asking for absurdity along the lines of "I (removed a internal decorative planter I didn't like)/(un-merged my utility-shuttle)/(got an antenna shot off) so my railguns stopped working". I get that someone slapping some engines and a cockpit on to the side of the biggest weapon in SE and calling it a ship is absurd, but SE is an engineering game so there needs to be an engineering reason something does or doesn't work.
-Hit-scan weapons like lasers should probably be avoided as they functionally remove evasion from the combat equation and make designs that rely on it entirely unusable (fighters, bombers, drone-carriers).
-Custom-turrets were a well-liked feature in SE1 that people would just script in before Keen made it a block. It should be expected that they will at some point make it in to SE2, so I would advise considering anything "fixed" to just be a larger turret.
-Heat would be fun, though what you've described as "active-cooling" sounds more akin to a cross between thermal capacitors and active cooling. Thermal capacitors store heat, while active-cooling (at least in other games) pushes heat in to a coolant (like water) and then dumps said coolant entirely off the grid. I might also advise that a block's "natural heat dissipation" be tied to a grid's environment, such that it can be reasonably relied on in atmosphere, much more effective submerged in water, and much less effective in space. Such variations would both me more realistic and would encourage people to engineer different designs in different ways for different environments.
-Stealth and detection would be fun so long as there's a minimum detection range, as otherwise we'll run in to issues with people stealthing strait in to the hull with no warning or defense. SE1 has enough of an issue with grinder-monkeys as is, and warhead-missiles that don't trigger point defenses would absolutely create a hard meta.
-Long-range scanning probably shouldn't give precise data on anything, if you can't pinpoint a target's exact location then why would you know anything about it that requires directly observing it in relatively high-resolution?
-Shields are a terrible idea, as they can't be balanced in a game like SE. They turn defense in to a math-problem that isn't hard to solve and create a meta anyone wanting to be competitive in pvp must adhere to.
Comments:
4Peace
-SE1 has angled armor, and people still build anything they want. Deflection is definitely a thing that happens, and people do build for it, but Keen made it a percent-chance in SE1 to avoid bogging the game down with deflection-calculations (and inadvertently made shot-traps a sort-of thing). So as long as there are reasonable minimum/maximum values for things and it stays a chance of deflection instead of a guarantee I doubt it will be too much of an issue.
-Shields are still a terrible idea, though shields only reducing incoming damage instead of the typically asked for hit-point-bubble would work a lot better, particularly if the system also uses power and generates heat in proportion to the incoming kinetic energy of the projectiles.
-Why not have layered armor still be a thing? I get that massive ships with hull thicknesses measured in tens of meters are resource-intensive in every conceivable way, it is kind of how physics, engineering, and scale works, but if someone’s willing to commit the time and resources and it isn’t somehow breaking the game then shouldn’t they get what they’re after?
-What’s wrong with gunbricks now having to include the extra space for radiators? Radiators would require space between guns such that it would make the weapon-count seem more reasonable for a ship’s size, and they aren’t armor, so hosing the brick’s radiators down with lead could potentially be almost as degrading to the ship’s effectiveness as damaging its conveyor-network. The need to protect the radiators well still exposing them to the ship’s exterior would in turn cause the ship’s designer to have to consider careful placement of such, needing to engineer protective angles and the like that would reduce the ship’s brick-ness.
Captainbladej52
-Please get over yourself.
Gruller65 & Tristan Sullivan
-Try not to get too worked up over Cap, the concept of having to redesign their existing SE1 gunbricks to accommodate new systems and mechanics that are not direct overt benefits to said gunbricks is blasphemous to them. Cap will project, spout fallacies, lay baseless accusations against everyone disagreeing with them, and never admit or accept that any part of their argument or actions was wrong. You’ve read their first post, nothing they have to say is going to change on any subsequent post, best to just troll them for their behavior before moving on and ignoring any subsequent posts they make.
Semtex
-I question if you are not missing the point of the OP, or if perhaps I am missing the way you see things… The OP seems quite interested in making gunbricks not a thing, but has failed to specify a size-cap. To this end I suspect their issue has less to do with size and more creativity (simple wall of gun builds and builds with turrets packed as tightly together in the greatest numbers as possible). Heat encourages spacing the guns a bit more to match the thermal capabilities of the ship, and while there are plenty of folk who would just add space and call it good, there are plenty more that will see extra space as unused canvas and break out the art-supplies. Their solution is imperfect, but it would be generally a step in the direction they seem to want to go.
Goodness there is a lot to go over here...
OP video/post:
-The proposition for armor sounds a fair bit like what we've got in SE1, except for weapons having different penetration-values and there being a "no damage deflection" value. I'm certainly all for making small-arms have reduced effectiveness against significant armor, but deflection really should be calculated as a percent chance of happening instead of just a garneted event. If deflection is garneted then there's a serious risk of bogging the game down in calculations when you fire a high rate of fire weapon in to something covered in spikes as the projectiles skip back and forth without hitting anything they could hope to penetrate in what should otherwise act as a sort of "shot-trap" that would at least degrade the armor at that point. I might also advise against trying to figure in durability augmentations based on adjacent armor blocks, as weapons thus far have all been of either the low-damage-point-n-spray with no penetration or single-high-damage-blows-through-several-layers kind of things. Unless Keen decides they need a middle-ground weapon in there I am uncertain having to calculate multi-layer thickness for penetrating shots will do anything more than add unnecessary calculations for the system to run in a fight.
-Why do we need to incentivize mid and large sized combat-ship construction more than SE1 already did? Small combat ships in SE1 already typically require the pilot to be an ace just to survive, they often run in to endurance issues (lots of fights they can't win because they can't carry enough ammo to kill a target), and the only incentives to using small ships in SE1 are reduced starting-cost and reduced after-combat maintenance (again assuming the ship survived).
-The coating thing is interesting, but it may be more practical to have subsets of blocks that simply have that property from the get-go, as otherwise you're tying part-usage and block-mass to a paint-tool that will absolutely break immersion for a lot of the more "hard-sci" players... On the other hand having a "block-replacement tool" that replaces the targeted block or group of blocks with identically shaped blocks possessing the chosen new properties without potentially splitting a grid would absolutely be something people would love to get their hands on, and would be far less of an immersion-issue as it effectively grinds down what's there and welds something new in its place.
-Size-restricting a weapon or block would be non-sensical. Things like ammo/fuel, block weight, block-size, or power-draw are easily defined and measurable values you can engineer a ship around. If a grid has them, the thrust to move it all around, and proper conveyoring, then it has everything it needs and so it very logically works, but "grid size"? How is the game to determine a grid's intended "size" vs where it got to be via outside factors? This is just asking for absurdity along the lines of "I (removed a internal decorative planter I didn't like)/(un-merged my utility-shuttle)/(got an antenna shot off) so my railguns stopped working". I get that someone slapping some engines and a cockpit on to the side of the biggest weapon in SE and calling it a ship is absurd, but SE is an engineering game so there needs to be an engineering reason something does or doesn't work.
-Hit-scan weapons like lasers should probably be avoided as they functionally remove evasion from the combat equation and make designs that rely on it entirely unusable (fighters, bombers, drone-carriers).
-Custom-turrets were a well-liked feature in SE1 that people would just script in before Keen made it a block. It should be expected that they will at some point make it in to SE2, so I would advise considering anything "fixed" to just be a larger turret.
-Heat would be fun, though what you've described as "active-cooling" sounds more akin to a cross between thermal capacitors and active cooling. Thermal capacitors store heat, while active-cooling (at least in other games) pushes heat in to a coolant (like water) and then dumps said coolant entirely off the grid. I might also advise that a block's "natural heat dissipation" be tied to a grid's environment, such that it can be reasonably relied on in atmosphere, much more effective submerged in water, and much less effective in space. Such variations would both me more realistic and would encourage people to engineer different designs in different ways for different environments.
-Stealth and detection would be fun so long as there's a minimum detection range, as otherwise we'll run in to issues with people stealthing strait in to the hull with no warning or defense. SE1 has enough of an issue with grinder-monkeys as is, and warhead-missiles that don't trigger point defenses would absolutely create a hard meta.
-Long-range scanning probably shouldn't give precise data on anything, if you can't pinpoint a target's exact location then why would you know anything about it that requires directly observing it in relatively high-resolution?
-Shields are a terrible idea, as they can't be balanced in a game like SE. They turn defense in to a math-problem that isn't hard to solve and create a meta anyone wanting to be competitive in pvp must adhere to.
Comments:
4Peace
-SE1 has angled armor, and people still build anything they want. Deflection is definitely a thing that happens, and people do build for it, but Keen made it a percent-chance in SE1 to avoid bogging the game down with deflection-calculations (and inadvertently made shot-traps a sort-of thing). So as long as there are reasonable minimum/maximum values for things and it stays a chance of deflection instead of a guarantee I doubt it will be too much of an issue.
-Shields are still a terrible idea, though shields only reducing incoming damage instead of the typically asked for hit-point-bubble would work a lot better, particularly if the system also uses power and generates heat in proportion to the incoming kinetic energy of the projectiles.
-Why not have layered armor still be a thing? I get that massive ships with hull thicknesses measured in tens of meters are resource-intensive in every conceivable way, it is kind of how physics, engineering, and scale works, but if someone’s willing to commit the time and resources and it isn’t somehow breaking the game then shouldn’t they get what they’re after?
-What’s wrong with gunbricks now having to include the extra space for radiators? Radiators would require space between guns such that it would make the weapon-count seem more reasonable for a ship’s size, and they aren’t armor, so hosing the brick’s radiators down with lead could potentially be almost as degrading to the ship’s effectiveness as damaging its conveyor-network. The need to protect the radiators well still exposing them to the ship’s exterior would in turn cause the ship’s designer to have to consider careful placement of such, needing to engineer protective angles and the like that would reduce the ship’s brick-ness.
Captainbladej52
-Please get over yourself.
Gruller65 & Tristan Sullivan
-Try not to get too worked up over Cap, the concept of having to redesign their existing SE1 gunbricks to accommodate new systems and mechanics that are not direct overt benefits to said gunbricks is blasphemous to them. Cap will project, spout fallacies, lay baseless accusations against everyone disagreeing with them, and never admit or accept that any part of their argument or actions was wrong. You’ve read their first post, nothing they have to say is going to change on any subsequent post, best to just troll them for their behavior before moving on and ignoring any subsequent posts they make.
Semtex
-I question if you are not missing the point of the OP, or if perhaps I am missing the way you see things… The OP seems quite interested in making gunbricks not a thing, but has failed to specify a size-cap. To this end I suspect their issue has less to do with size and more creativity (simple wall of gun builds and builds with turrets packed as tightly together in the greatest numbers as possible). Heat encourages spacing the guns a bit more to match the thermal capabilities of the ship, and while there are plenty of folk who would just add space and call it good, there are plenty more that will see extra space as unused canvas and break out the art-supplies. Their solution is imperfect, but it would be generally a step in the direction they seem to want to go.
When it comes to projectile ricochets off armor, the best possible solution in a computer game is to ignore the possibility of projectiles ricocheting off armor.
The theory surrounding projectile ricochets off armor (in the real world) is still incomplete; there are no "simple" mathematical models, only empirical knowledge and "semi-empirical" formulas.
The reason is that the ricochet of a projectile off an armor plate depends on a large number of parameters, both of the armor plate (strength, elasticity, notch toughness, thickness...) and the projectile (shape and design of the projectile’s front section, hardness, toughness, impact velocity and impact energy, cross-sectional load of the projectile...). Furthermore, it is not sufficient to evaluate the armor plate and the projectile separately, but also their properties in relation to one another (for example, the ratio of the armor plate’s thickness to the caliber of the impacting projectile).
The author also makes the erroneous assumption that the armor plate is not damaged when a projectile ricochets.
This is, of course, not true. A whole range of damage to the armor plate occurs—from notches and grooves caused by the projectile’s impact, through deformation (bending and denting) of the plate and the formation of cracks in the armor plate, to the tearing of the armor plate material on the back side of the armor plate (the plate is not penetrated, but the interference of tensile and compressive waves generated during the ricochet tears out the armor plate material, which has an effect equivalent to the explosion of a fragmentation grenade).
Of course, when a projectile is deflected, the armor plate absorbs a significant portion of the projectile’s impact energy—the projectile changes its direction and velocity upon deflection.
When it comes to projectile ricochets off armor, the best possible solution in a computer game is to ignore the possibility of projectiles ricocheting off armor.
The theory surrounding projectile ricochets off armor (in the real world) is still incomplete; there are no "simple" mathematical models, only empirical knowledge and "semi-empirical" formulas.
The reason is that the ricochet of a projectile off an armor plate depends on a large number of parameters, both of the armor plate (strength, elasticity, notch toughness, thickness...) and the projectile (shape and design of the projectile’s front section, hardness, toughness, impact velocity and impact energy, cross-sectional load of the projectile...). Furthermore, it is not sufficient to evaluate the armor plate and the projectile separately, but also their properties in relation to one another (for example, the ratio of the armor plate’s thickness to the caliber of the impacting projectile).
The author also makes the erroneous assumption that the armor plate is not damaged when a projectile ricochets.
This is, of course, not true. A whole range of damage to the armor plate occurs—from notches and grooves caused by the projectile’s impact, through deformation (bending and denting) of the plate and the formation of cracks in the armor plate, to the tearing of the armor plate material on the back side of the armor plate (the plate is not penetrated, but the interference of tensile and compressive waves generated during the ricochet tears out the armor plate material, which has an effect equivalent to the explosion of a fragmentation grenade).
Of course, when a projectile is deflected, the armor plate absorbs a significant portion of the projectile’s impact energy—the projectile changes its direction and velocity upon deflection.
Interaction between armor and a projectile.
In my opinion, the best way to assess the interaction between an armor block and a projectile is to work with the concept of 0.25-meter cubes. A 0.25-meter block has a certain durability, which is determined by the type of armor block (light, heavy, “special,” etc.). For assessment purposes, a 2.5-meter block is then composed of 1,000 0.25-meter blocks arranged in a 10x10x10 cube and has a resistance 1,000 times greater than that of a 0.25-meter block. Armor elements have an arrangement of 0.25-meter blocks corresponding to the shape and correspondingly lower resistance.
The projectile is represented by a single 0.25-meter block or several 0.25-meter blocks arranged in a row. The last of the projectile’s blocks is the warhead. The resistance of the projectile’s blocks should correspond to the projectile’s caliber and mass and, logically, should be significantly greater than the resistance of the armor blocks.
How it should work:
The projectile strikes the armor block—the trajectory of the projectile’s 0.25-meter blocks through the 0.25-meter “internal” blocks of the armor block is determined. The penetrating projectile destroys the "internal 0.25m blocks" along the trajectory, and simultaneously, the durability of the projectile’s front block decreases by the same amount until its durability is depleted.
If the projectile assembly contains an explosive block, it explodes upon impact with an internal armor block and destroys a certain number of blocks in its vicinity. Or, if the projectile’s front block still exists—albeit with minimal remaining durability—the explosive block detonates according to predefined rules. For example, five or ten meters after the first contact with an obstacle... Or it simply waits for the front block to be completely destroyed and for its interaction with the next obstacle...
The resistance of a 2.5 m armor block is reduced by a factor of two (or x times) the damage corresponding to the number of destroyed 0.25 m "inner" blocks after the interaction with the projectile ends. The reason for this is to avoid the need to store information about the projectile’s trajectory through the armor block and the position of the destroyed “internal” blocks. A hit damages the 2.5 m block as a whole. The division of the 2.5 m block into small 0.25 m “internal” blocks is used only at the moment of interaction with the projectile. Upon the impact of another projectile, the division into 0.25 m internal blocks is repeated, but the internal blocks already have reduced durability.
This system of damage and interaction between armor and projectile has the advantage of not requiring calculations of the projectile’s impact velocity and energy expenditure during the penetration of the armor block.
The projectile’s penetration capability is defined by a single value—the durability of the projectile’s “front” block.
The entire process of penetrating armor (including armor composed of multiple armor blocks) is reduced to a single calculation cycle
At the same time, it allows for the existence of explosive projectiles, including those consisting solely of an explosive block, which will detonate on the surface of the armor block—and yet damage it depending on the force of the explosion.
Interaction between armor and a projectile.
In my opinion, the best way to assess the interaction between an armor block and a projectile is to work with the concept of 0.25-meter cubes. A 0.25-meter block has a certain durability, which is determined by the type of armor block (light, heavy, “special,” etc.). For assessment purposes, a 2.5-meter block is then composed of 1,000 0.25-meter blocks arranged in a 10x10x10 cube and has a resistance 1,000 times greater than that of a 0.25-meter block. Armor elements have an arrangement of 0.25-meter blocks corresponding to the shape and correspondingly lower resistance.
The projectile is represented by a single 0.25-meter block or several 0.25-meter blocks arranged in a row. The last of the projectile’s blocks is the warhead. The resistance of the projectile’s blocks should correspond to the projectile’s caliber and mass and, logically, should be significantly greater than the resistance of the armor blocks.
How it should work:
The projectile strikes the armor block—the trajectory of the projectile’s 0.25-meter blocks through the 0.25-meter “internal” blocks of the armor block is determined. The penetrating projectile destroys the "internal 0.25m blocks" along the trajectory, and simultaneously, the durability of the projectile’s front block decreases by the same amount until its durability is depleted.
If the projectile assembly contains an explosive block, it explodes upon impact with an internal armor block and destroys a certain number of blocks in its vicinity. Or, if the projectile’s front block still exists—albeit with minimal remaining durability—the explosive block detonates according to predefined rules. For example, five or ten meters after the first contact with an obstacle... Or it simply waits for the front block to be completely destroyed and for its interaction with the next obstacle...
The resistance of a 2.5 m armor block is reduced by a factor of two (or x times) the damage corresponding to the number of destroyed 0.25 m "inner" blocks after the interaction with the projectile ends. The reason for this is to avoid the need to store information about the projectile’s trajectory through the armor block and the position of the destroyed “internal” blocks. A hit damages the 2.5 m block as a whole. The division of the 2.5 m block into small 0.25 m “internal” blocks is used only at the moment of interaction with the projectile. Upon the impact of another projectile, the division into 0.25 m internal blocks is repeated, but the internal blocks already have reduced durability.
This system of damage and interaction between armor and projectile has the advantage of not requiring calculations of the projectile’s impact velocity and energy expenditure during the penetration of the armor block.
The projectile’s penetration capability is defined by a single value—the durability of the projectile’s “front” block.
The entire process of penetrating armor (including armor composed of multiple armor blocks) is reduced to a single calculation cycle
At the same time, it allows for the existence of explosive projectiles, including those consisting solely of an explosive block, which will detonate on the surface of the armor block—and yet damage it depending on the force of the explosion.
SDX2 mod just came out, a warfare modd on a custom server, and there are a couple of deductions that can be made. To be fair, I have never played on that server, these are just observations from a new guy:
1. After ten years, multiple iterations, testing from tons of people, total freedom on modding...people still break combat. And people still claim it is unbalanced. And people complain about lack of diversity, or certain 'meta' weapons. Still. All these ideas...and they will be broke in a month. And another 10 years later...same cycle, again. Others have been trying different things with modding for years...to the same problems. Why? I made a 'Weapons:' post that goes into the philosophy behind it. (and post below, essentially)
2. New weapon tweaks on the mod. They are changing the values of their different weapon systems. Why? They are essentially 'designing' a new weapon, to counter what players have been doing with 'gameplay' as a 'counter' to the modders weapon 'design', since players cannot 'design' a weapon themselves. The only way to 'counter' a modder/dev weapon 'design', is by ... gameplay counters...which 'breaks' the balance...so they should lose a fight instead? Or a gentleman's agreement? ...and all '-' are on purpose.
3. Ship Cores. Since people break the balance on the weapons the modders designed, they must limit gameplay to try and ensure the type of combat they want...by now forced to limiting ship 'design' by the introduction of ship cores. An allowable set of ships designs to be used, with allowable weapons to be used in the different slots, by a player.
4. Penetrating weapons. Sounds good, actually an interesting idea to counter welders. The idea being a block doesn't just turn 'off' when a certain amount of damage is accrued, but it gradually loses it ability to function, incrementally. Add that with rounds that penetrate multiple blocks with each shot, interesting concept, sounds like good one.
5. Quote: "Racer - The guy who races his hot-rod on the circuit, to fans and trophies of accomplishment."...
..."Which of these was it designed for? #4, in the end. All others are a derivement from it's original purpose"......"Weapon systems should be built. Instead of a balance patch, players will tinker with their weapon builds, shield builds, armor builds, etc."
...Combat has turned into a gentleman's agreement, a set of rules for the 'race'. Or a football game, an elaborate set of rules to move a ball, that are fair. Which is fine, lots of people like an afternoon of showmanship. But, for the Mad-Max player, his build will defeat these builds, if those players move to another server, and use those rules against others who don't. Again, I made a post on it.
How to solve it? Instead of modders designing weapons with their patch, let players design weapons in-game. Now when you make a patch, you are balancing the under-laying 'reality' of the physics in a simulation/sandbox, not the block's implementation in it.
Again, I'm not ripping on them specifically, just noticing that there is a pattern there in general, and a possible fix to enable players to innovate and design counters and solutions to other players designs...and solutions..., in game. (edit: Basically, you can't balance 'reality', you can only innovate in it. The Dev's can concentrate on a layer below a block's usage of that, and let the player design their own 'innovations' a layer above)
SDX2 mod just came out, a warfare modd on a custom server, and there are a couple of deductions that can be made. To be fair, I have never played on that server, these are just observations from a new guy:
1. After ten years, multiple iterations, testing from tons of people, total freedom on modding...people still break combat. And people still claim it is unbalanced. And people complain about lack of diversity, or certain 'meta' weapons. Still. All these ideas...and they will be broke in a month. And another 10 years later...same cycle, again. Others have been trying different things with modding for years...to the same problems. Why? I made a 'Weapons:' post that goes into the philosophy behind it. (and post below, essentially)
2. New weapon tweaks on the mod. They are changing the values of their different weapon systems. Why? They are essentially 'designing' a new weapon, to counter what players have been doing with 'gameplay' as a 'counter' to the modders weapon 'design', since players cannot 'design' a weapon themselves. The only way to 'counter' a modder/dev weapon 'design', is by ... gameplay counters...which 'breaks' the balance...so they should lose a fight instead? Or a gentleman's agreement? ...and all '-' are on purpose.
3. Ship Cores. Since people break the balance on the weapons the modders designed, they must limit gameplay to try and ensure the type of combat they want...by now forced to limiting ship 'design' by the introduction of ship cores. An allowable set of ships designs to be used, with allowable weapons to be used in the different slots, by a player.
4. Penetrating weapons. Sounds good, actually an interesting idea to counter welders. The idea being a block doesn't just turn 'off' when a certain amount of damage is accrued, but it gradually loses it ability to function, incrementally. Add that with rounds that penetrate multiple blocks with each shot, interesting concept, sounds like good one.
5. Quote: "Racer - The guy who races his hot-rod on the circuit, to fans and trophies of accomplishment."...
..."Which of these was it designed for? #4, in the end. All others are a derivement from it's original purpose"......"Weapon systems should be built. Instead of a balance patch, players will tinker with their weapon builds, shield builds, armor builds, etc."
...Combat has turned into a gentleman's agreement, a set of rules for the 'race'. Or a football game, an elaborate set of rules to move a ball, that are fair. Which is fine, lots of people like an afternoon of showmanship. But, for the Mad-Max player, his build will defeat these builds, if those players move to another server, and use those rules against others who don't. Again, I made a post on it.
How to solve it? Instead of modders designing weapons with their patch, let players design weapons in-game. Now when you make a patch, you are balancing the under-laying 'reality' of the physics in a simulation/sandbox, not the block's implementation in it.
Again, I'm not ripping on them specifically, just noticing that there is a pattern there in general, and a possible fix to enable players to innovate and design counters and solutions to other players designs...and solutions..., in game. (edit: Basically, you can't balance 'reality', you can only innovate in it. The Dev's can concentrate on a layer below a block's usage of that, and let the player design their own 'innovations' a layer above)
Replies have been locked on this page!