Game Balance: The Mathematical Approach

    Joined
    Aug 23, 2013
    Messages
    379
    Reaction score
    65
    Currently, game balance is a controversial topic. To me, it seems like Schema doesn't know how to balance the game and is making everything configurable so that all the different end-users can screw it up in different ways. This is bad because the chance of hundreds of random people actually agreeing on anything is zero, and the end result will be perpetual disagreements and a fragmented community (e.g. where you can't take a ship from one server and use it on another due to wildly different settings).

    What I intend to do here is to promote a mathematical approach to game balance. To do this I'll use assumptions about what is desirable, and create a set of formulas for various things (weapons, shields, power, thrust, etc) that are "balanced" relative to those assumptions. The assumptions I'll use and the formulas I come up with are only intended as a demonstration - I'm not suggesting tha these formulas actually be used (and only suggesting that the mathematical approach be adopted).

    Also, I will start "simple" and increase the complexity of the formulas as additional assumptions are added.


    Block Ratios

    Let's start by defining a "well rounded" ship. In very general terms, a ship has 3 main attributes - offense, defence and maneuverability. A well rounded ship is a ship where all 3 attributes are equal (e.g. not a glass cannon, not a tank, not a turtle and not a hare). To support the 3 attributes a ship also needs power. We can classify blocks into one of 4 types (offsense, defense, maneuverability and power). For a well rounded ship, let's assign block ratios to each class equally - 25% of blocks would be for offense, 25% would be for defense, 25% would be for maneuverability and 25% of blocks would be for power. Note: I am ignoring various "miscellaneous" blocks (SD cockpit, docking modules and enhancers, etc) as the number of these blocks on a typical ship is too few to matter.

    Of course these block ratios only apply for a well rounded ship. Different ships will use different ratios, which is a good thing.


    Power

    Power is the "odd thing" - it's not one of the ship 3 main attributes but all 3 of the main attributes depend on it. For this reason; it makes sense to define power and use that as the basis for balancing everything else.

    Power itself can be divided into 2 different statistics: power regeneration and power storage. These need to be balanced first. Let's assume that for a well rounded ship we want half the power blocks to be recharge and half to be storage; and that we want a ship to go from "no power" to "fully charged" in 30 seconds. Also, for the sake of "dividing by 3 things" later and convenience, let's say one block of storage will store 750 units of power. This gives us the first 2 formulas:

    power_capacity = power_tanks * 750
    power_regen_per_second = power_generators * 750 / 30 = power_generators * 25​

    Let's also assume that (for a well rounded ship) offense, defense and maneuverability each consume the same amount of power when being used. You wouldn't want power to be at full capacity all of the time (that'd be boring). For a well rounded ship, I'd want power regeneration to cover half of the max. power consumed by offense, defense and maneuverability combined. This means that if you're firing and moving at the same time (or firing and regenerating shields, etc), then you'd be depleting your power storage. Based on that we get 3 more formulas:

    offense_block_power_consumption_per_second = 2/3 * 25 = 16.66
    defense_block_power_consumption_per_second = 16.66
    thruster_block_power_consumption_per_second = 16.66​


    Thrusters

    First, let me say that km/h is an awkward unit. I'm going to work in meters per second. 50 km/h is 13.88 m/s. This is slow. Let's do the calculations for 30 m/s (108 km/h).

    For the well rounded ship; let's assume that (from a standing start) we want to reach 30 m/s in 10 seconds. Acceleration is the change in velocity over time; so this this works out to an acceleration of 3 m/s^2 (and is about the same acceleration as your Grandmother's car).

    Force is mass (in Kg) times acceleration; and (because our well rounded ship is 25% thrusters and we want 3 m/s^2 acceleration) this means each thruster needs to generate "4 * mass_of_block * 3" newtons of force. Now things get tricky...

    We know that a block has a mass of 0.1 "somethings". I have no idea if that's 0.1 Kg or 0.1 pounds or 0.1 monkey testicles. Let's define mass properly! A cubic meter of water is 1000 Kg. Metals tend to have higher density than water (e.g. a cubic meter of steel is about 7850 Kg), but not all of the game's blocks are solid (e.g. wedges) and we could assume that things like power generators are partially hollow. Mostly it's all dodgy ("Hardened hull has the same mass as a red mushroom? WTF?"). Let's just take a random guess an assume an average block is 1000 Kg.

    We get these formulas:

    mass_per_block = 0.1 "somethings" = 1000 Kg
    force_per_thruster = 4 * mass_of_block * 3 = 1333.333 newtons
    thruster_block_power_consumption_per_second = 16.66​

    If/when we get directional thrusters, the above calculations would need to be redone. For example, if half our thrusters are used for lateral movement and the other half used for rotation then the force per thruster would have to be doubled so we end up with the same 3 m/s^2 acceleration.


    Shields

    Currently shields only have a capacity and a recharge rate. This means there's little downside to having extremely over-sized shields, which is bad. To fix this shields should also have "leakage" (e.g. at full shields, it should cost some power to maintain the shields even when they aren't recharging). For balancing leakage against recharge, let's say recharge should cost 4 times as much power as leakage:

    shield_leakage_power_per_second = shield_recharge_power_per_second / 4​

    Because shields would be consuming power even when they aren't recharging (and because hulls don't consume power), the previous formula for defense block power needs some adjustment. For a well rounded ship; let's allow for shields that are recharging 25% of the time. This means:

    defense_block_power_consumption_per_second = 16.66 = shield_recharge_power_per_second * 0.25 + shield_leakage_power_per_second * 0.75​

    Combining the previous 2 formulas gives us:

    shield_recharge_power_per_second * 0.25 + shield_recharge_power_per_second / 4 * 0.75 = 16.66​

    This leads to these formulas:

    shield_recharge_power_per_second = 38 * shield_blocks
    shield_leakage_power_per_second = 9.5 * shield_blocks​

    For simplicity, let's also say that 1 point of shields is equal to 1 point of power. This means that each shield block recharges 38 points of shields each second:

    shield_recharge_per_second = 38 * shield_blocks​

    Let's also assume that (for a well rounded ship) we want shields to go from "shields down" to full shields in 30 seconds. This means that:

    shield_capacity = shield_recharge_per_second * 30 = 38 * shield_blocks * 30 = shield_blocks * 1140​

    However; there's been some talk of separating shield recharge and shield capacity into 2 different types of blocks (similar to power generators and tanks). I really like that idea, so let's do that instead. For a well rounded ship we can assume half of the shields blocks are for shield recharge and the other half are for storage. This means that (for shield leakage power consumption) we could just make the shield storage blocks consume power all of the time and subtract that from power consumed when shield are recharging. The adjusted formulas become:

    shield_recharge_per_second = 38 * 2 * shield_recharge_blocks = shield_recharge_blocks * 76
    shield_recharge_power_per_second = 38 * 2 * shield_recharge_blocks = shield_recharge_blocks * 76
    shield_leakage_power_per_second = 9.5 * 2 * shield_storage_blocks = shield_storage_blocks * 19
    shield_capacity = shield_recharge_per_second * 30 = 76 * shield_storage_blocks * 30 = shield_storage_blocks * 2280​



    Weaponry Part 1

    Weapons need to be balanced against both power and shields. The power is already "done enough for now", in that we've already worked out that each offensive block should consume 16.66 of power.

    To start balancing weapon DPS; let's assume that for a "straight slugfest" (e.g. 2 identical "well rounded" ships hitting each other without moving) we want the fight to last about 60 seconds - you don't want instant kills and you don't want fights to be a contest to see which pilot has the largest bladder. Of course actual pilots would move their ships (e.g. out of range of the opponent's weapons and/or dodging) so an actual fight would take longer. The 60 seconds is actually the minimum amount of time for shields to go down (assuming equal "well rounded" ships).

    For the well rounded ship; 2 blocks of shields means 2280 shield capacity and 76 recharge per second. During the fight a ship would regenerate 4560 shields, which means that for the fight to last 60 seconds the equivelent "2 block weapon" would need to do 6840 damage (iniital shield capacity + shield regen per second * time). 6840 damage in 60 seconds works out to 114 damage per second for 2 weapon blocks, or 57 damage per second per block. These are the initial formulas:

    weapon_power_consumption_per_second = weapon_blocks * 16.66
    weapon_DPS = weapon_blocks * 57​

    Now; there are a lot of different weapons in the game, and it'd be very sad if all of them were the same. We need attributes to vary to make different weapons seem different. Fortunately the game already has these (e.g. range, reload time, etc). We need formulas that describe the relationship between all the attributes. To make this easier to balance, I'll start with an "average weapon", and then extend the simple formulas to cope with variations. This "average weapon" doesn't actually need to exist as a weapon in the game (e.g. all weapons could vary it in some way); but I like the idea of "plain AMC" as the average weapon so I'll do that.

    The initial/simple formulas (excluding projectile speed) for "plain AMC" might be:

    weapon_power_consumption_per_second = weapon_blocks * 16.66
    weapon_DPS = weapon_blocks * 57
    weapon_reload_time = 1
    weapon_range = 1000​

    For most weapons projectile speed depends on the server's max. speed setting but beams are "infinite speed". The easy way to handle this is to define projectile speed as a "server max. speed divisor". For example, if the divisor is 0.5 and the server's max. speed is 100 km/h then the projectile's speed would be 200 km/h. Beams would have a divisor of 0.

    weapon_projectile_speed_divisor = 0.25​

    For weapon damage we need separate values for damage against blocks (e.g. hull) and damage against shields. This can be a ratio from 0 to 1 (where 0.5 means equal damage against blocks and shields), like this:

    weapon_shield_ratio = 0.5
    weapon_shield_DPS = weapon_DPS * weapon_shield_ratio * 2
    weapon_hull_DPS = weapon_DPS * (1 - weapon_shield_ratio) * 2​

    From here we need to select "primary attributes" that will be varied for different weapons, and create formulas to find "secondary attributes" from those primary attributes. I'm selecting weapon_range, weapon_reload_time, weapon_shield_ratio and weapon_projectile_speed_divisor as the 4 primary attributes. The primary attributes would be determined by primary and secondary weapon type (e.g. beam, AMC or missile) and effects.

    Let's look at weapon range first. If one ship has very short range weapons and another has very long range weapons; and both used the number of blocks, consumed the same power and did the same DPS; then the ship with the longer range would have a significant advantage - it'd be unbalanced. To correct that we need to vary a secondary attribute based on weapon range. Varying power consumption and/or DPS sounds like a good idea, so I'll change both of those formulas:

    weapon_power_consumption_per_second = weapon_blocks * 16.66 * ( (weapon_range / 1000 + 2) / 3) = weapon_blocks * (weapon_range / 180 + 11.111)
    weapon_DPS = weapon_blocks * 57 * ( (1000 / weapon_range + 2) / 3) = weapon_blocks * (19000 / weapon_range + 38)​

    This means that a weapon with 1000 range would be the same as before (16.66 power per second per block, 57 damage per second per block), a weapon with 2000 range would consume 22.222 power per second per block and do 47.5 damage per second per block, and a weapon with 500 range would consume 13.888 power per second per block and do 76 damage per second per block. That's good enough for me!

    For a weapon with an extremely long reload time you can fire it and then get out of your enemy's weapon range while you reload. This gives weapons with extremely long reload times an advantage. However; you'd also need to be able to store enough power to fire it. With the current formulas, for the well rounded ship, for every 2 weapon blocks you'd have 1 power tank block that stores 750 power. A weapon with a 60 second reload time (and 1000 range) would need 60*16.66 or 1000 power per block to fire. You'd need a "less well rounded" ship to make it work (e.g. sacrifice defense or manuevarability). Basically, there's already enough disadvantage to make weapons with extremely long reload times balanced.

    For a weapon with an extremely short reload time there's 2 tactical advantages. First, there's less "overkill" (e.g. if it takes 100 damage to destroy a block, then it's better to do 2 shots at 100 damage each than it is to do one shot that does 200 damage where half the damage is wasted) but that only helps when the enemy's shields are down anyway and becomes irrelevant once you start considering piercing and punch through effects. Second, there's a minor advantage for aiming - e.g. if a shot misses the target you can adjust. This is only a minor advantage though.

    Mostly; the advantages of extremely short and extremely long reload times aren't enough to worry about.

    Next is weapon_shield_ratio. I'm fairly sure most people would agree that damage against shields is more advantageous than damage against blocks (I know I'd rather be attacked by someone with good block damage and poor shield damage). The previous weapon_shield_DPS formula made weapons do 100% more damage against shields when weapon_shield_ratio is 1. Let's nerf that back to 50% more damage. Also there would've been a problem when weapon_shield_ratio is 0 - as soon as the enemy ship regenerates a single point of shields the weapon is useless. Fixing both those problems at the same time:

    weapon_shield_DPS = weapon_DPS * ((weapon_shield_ratio + 0.5) / 2) * 2 = weapon_DPS * (weapon_shield_ratio + 0.5)​

    That leaves the weapon_projectile_speed_divisor. The question here is, how easily can the enemy dodge the projectile? Beams can't be dodged at all, and slow moving projectiles (e.g. dumb-fire missiles) are easy to dodge. For the current set of formulas it's unbalanced (everyone would use beams for everything). If the enemy dodges the projectile 50% of the time then the weapon would need to do twice as much damage to make it balanced. Let's try something like this:

    weapon_DPS = weapon_blocks * (19000 / weapon_range + 38) * (1 + weapon_projectile_speed_divisor)​

    For a beam (where weapon_projectile_speed_divisor is zero) DPS is the same as before. A slow missile (e.g. weapon_projectile_speed_divisor = 1, or server's max. speed) does double damage, and a medium speed AMC (weapon_projectile_speed_divisor = 0.25, or 4 times server's max. speed) does 25% more damage.


    Weaponry Part 2

    With formulas for secondary weapon attributes we need values for primary weapon attributes. This involves the master weapon system type, slave weapon system type and ratio of master and slave blocks, and the effect module type and ratio of master and effect blocks.

    Before I start this part; there's one thing I've overlooked so far: Pulse weapons. Pulse is special because it's the only "area of affect" (AoE) weapon (and "weapon_range" is actually a radius). Because it's capable of hitting multiple targets I'd halve the DPS. This means we need another primary attribute, and it's going to be an "AoE or single target" flag that is either 0 (single target) or 1 (AoE). The revised DPS formula (which is the damage per second done to each enemy hit) becomes:

    weapon_DPS = weapon_blocks * (19000 / weapon_range + 38) * (1 + weapon_projectile_speed_divisor) / (1 + AoE_flag)​

    This means if you only hit one enemy with your pulse weapon it's half the damage that an equivelent single target weapon would've done; if you hit 2 enemies the total damage is equal; and if you hit 3 or more enemies the total damage is much better.

    The other thing I want to talk about is beams. When I first started writing this I had beams as short range weapons. It's not what I want - I really want beams to be long range but "attenuated". What I mean here is that the damage the beam does depends on how far away the target is - if the target is close the beam does full damage, but if the target is far away the beam does a lot less damage. Pulse weapons should also be attenuated. Let's add another "attenuatedFlag" primary attribute that is either 0 (normal) or 1 (attenuated). This creates a problem with DPS formula because range effects DPS. To fix that, for attenuated weapons I'd halve the effect that range has on DPS:

    weapon_DPS = weapon_blocks * (19000 * (attenuatedFlag + 1) / weapon_range + 38) * (1 + weapon_projectile_speed_divisor) / (1 + AoE_flag)​

    There's also an (obvious) formula I haven't mentioned yet for "per shot damage", like this:

    weapon_shot_damage = weapon_DPS * weapon_reload_time​

    The "per shot" formula needs to be modified to do the actual attenuation:

    weapon_shot_damage = weapon_DPS * weapon_reload_time * (1 - attenuatedFlag + attenuatedFlag * (1 - targetDistance / weapon_range) )​

    Basically; an attenuated weapon with a range of 3000 and a reload time of 1 second would do 50.66 damage per block at point blank range, 25.33 damage per block at 1500 range and no damage at 3000 range or greater. A similar weapon that isn't attenuated would do 44.33 damage per block for any target in range (from 0 to 3000).

    Of course damage against blocks and damage against shields should be updated to use weapon_shot_damage:

    weapon_shield_shot_damage = weapon_shot_damage * (weapon_shield_ratio + 0.5)
    weapon_hull_shot_damage = weapon_shot_damage * (1 - weapon_shield_ratio) * 2​

    Now all of that's out of the way, let's slap some numbers down for master weapon system primary attributes:

    Master Beam:
    weapon_range = 500
    weapon_reload_time = 0.5
    weapon_shield_ratio = 0.5
    weapon_projectile_speed_divisor = 0
    AoE_flag = 0
    attenuatedFlag = 1​

    Master AMC:
    weapon_range = 1000
    weapon_reload_time = 1
    weapon_shield_ratio = 0.5
    weapon_projectile_speed_divisor = 0.25
    AoE_flag = 0
    attenuatedFlag = 0​

    Master Missile:
    weapon_range = 2000
    weapon_reload_time = 8
    weapon_shield_ratio = 0.5
    weapon_projectile_speed_divisor = 1
    AoE_flag = 0
    attenuatedFlag = 0​

    Master Pulse:
    weapon_range = 500
    weapon_reload_time = 4
    weapon_shield_ratio = 0.5
    weapon_projectile_speed_divisor = 4
    AoE_flag = 1
    attenuatedFlag = 1​


    For the slave weapons systems and ratio of master and slave blocks, and for effect module type and ratio of master and effect blocks; we're mostly looking at modifying the primary attributes. We don't need to care much about game balance for this because the secondary attributes (power, DPS, etc) enforce game balance for us. For this reason I'm not going to give details of all of the slave weapons and effects. I will point out a few though...

    The first combination that stands out is missiles with either beams or missiles as the slave weapon system. These have "target chasing" abilities (missile lock and heat-seeking). Back when I was talking about projectile speed I decided that if a projectile is slow it's easy to dodge and should have higher DPS to compensate; but if the projectile is "target chasing" this is wrong. It needs to be fixed. I'm adding a "targetChasingFlag" primary attribute that is either 0 (normal) or 1 (missile lock or heat-seeking) and using it to remove 90% of the projectile speed bonus for target chasing weapons:

    weapon_DPS = weapon_blocks * (19000 * (attenuatedFlag + 1) / weapon_range + 38) * (1 + weapon_projectile_speed_divisor * (1 - 0.9 * targetChasingFlag) ) / (1 + AoE_flag)​

    The next combination that needs looking at is the "shotgun" style combinations (beam, cannon and missile master weapons with missile slave weapons). In this case the DPS stays the same, but is simply divided by the number of beams or projectiles.


    Intermission

    This is getting long and the current set of formulas are spread everywhere. I just want to put them all here in one place before moving on (and sneak in a "weapon power consumption per shot" and a "total thrust" formulas that were too obvious to mention previously):

    power_capacity = power_tanks * 750
    power_regen_per_second = power_generators * 25​

    mass_per_block = 0.1 "somethings" = 1000 Kg
    force_per_thruster = 4 * mass_of_block * 3 = 1333.333 newtons
    thruster_block_power_consumption_per_second = 16.66
    total_thrust = force_per_thruster * thruster_blocks​

    shield_capacity = shield_storage_blocks * 2280
    shield_recharge_per_second = shield_recharge_blocks * 76
    shield_recharge_power_per_second = shield_recharge_blocks * 76
    shield_leakage_power_per_second = shield_storage_blocks * 19​

    weapon_power_consumption_per_second = weapon_blocks * (weapon_range / 180 + 11.111)
    weapon_power_consumption_per_shot = weapon_power_consumption_per_second * weapon_reload_time
    weapon_DPS = weapon_blocks * (19000 * (attenuatedFlag + 1) / weapon_range + 38) * (1 + weapon_projectile_speed_divisor) / (1 + AoE_flag)
    weapon_shot_damage = weapon_DPS * weapon_reload_time * (1 - attenuatedFlag + attenuatedFlag * (1 - targetDistance / weapon_range) )
    weapon_shield_shot_damage = weapon_shot_damage * (weapon_shield_ratio + 0.5)
    weapon_hull_shot_damage = weapon_shot_damage * (1 - weapon_shield_ratio) * 2​


    Scale (Ship Size)

    Up until now I've carefully avoided any mention of ship size or power/shield/weapon scaling. With the current formulas (above), if one "well rounded" ship is twice the size of another "well rounded" ship then it'll have twice as much offense and defense. This isn't what I'd want. There should be "diminishing returns" (as things get bigger the improvements get less).

    Strangely; the maneuverability for both "well rounded" ships will be identical despite the size differences (e.g. twice the thrust with twice the mass means the same acceleration). This is exactly how things should be (it's consistent with physics). Some people will disagree with this, but they shouldn't worry - "diminishing returns" for power generation means that large ships will have to make large sacrifices to generate enough power for their thrusters, and I'd expect the first thing large ship builders are going to do is sacrifice thrusters (increasing space for power generation while reducing power consumed by thrusters at the same time). Of course if someone wants to build a huge ship that's 25% thrusters and 50% power generators (with bad offense and defence) then that's their choice. What I'm saying here is that thrust and maneuverability is perfectly fine without any "diminishing returns" for thrusters.

    The same applies to all other power consumption - if there's diminishing returns for power generation and power storage, then there's no need to have diminishing returns for things like weapon power consumption, shield power consumption and thruster power consumption.

    For the remaining formulas; the formulas that matter are currently using "number of blocks". We only need to change them so they use something like "number of blocks to the power of 0.9". I'm going to write this as "blocks**0.9" rather than "blocks^0.9" as I'm used to caret being an XOR operator. Anyway; here's the first set of revised formulas:

    power_capacity = power_tanks**0.9 * 750
    power_regen_per_second = power_generators**0.9 * 25​

    shield_capacity = shield_storage_blocks**0.9 * 2280
    shield_recharge_per_second = shield_recharge_blocks**0.9 * 76​

    weapon_DPS = weapon_blocks**0.9 * (19000 * (attenuatedFlag + 1) / weapon_range + 38) * (1 + weapon_projectile_speed_divisor) / (1 + AoE_flag)​

    That's a good start; but I'd want to encourage large ships to use slow power regen and large power storage, and slow shield regen and large storage. To do this I want different exponents to make regen/recharge less linear and storage/capacity more linear. Here's the next revision:

    power_capacity = power_tanks**0.95 * 750
    power_regen_per_second = power_generators**0.85 * 25​

    shield_capacity = shield_storage_blocks**0.95 * 2280
    shield_recharge_per_second = shield_recharge_blocks**0.85 * 76​


    Block Layouts

    For the formulas I've got above; any type of block can be placed anywhere and it doesn't matter. That's bad - it means people can just slap blocks anywhere randomly without thinking or caring about it and still get the highest efficiency from them. The way power tanks need to be joined is good, so let's modify the power capacity formula to keep that basic idea:

    power_capacity = power_tanks**0.95 * 750 / power_tank_groups**1.5​

    Now; at the moment a few things (power generators and thrusters) in StarMade use what I'll call "XYZ frame bonuses". This also makes people think about block layout. The disadvantage is that it completely ruins game balance, especially for small ships that can't hope to get anywhere close to the "XYZ frame bonuses" that medium ships can get with ease (it completely destroys "diminishing returns"). For this reason alone (helping to make small ships better than flying turds) the "XYZ frame bonuses" desperately needs to be ripped out of the game ASAP.

    We need to some other way of making people think about efficient block layout for power generators. I like the idea of pretending that heat effects efficiency. Let's say that power generators generate heat and when too many power blocks are touching they can't operate as efficiently - it sounds believable to me! In practical terms, this could be as simple as using a formula like this:

    power_regen_per_second = power_generators**0.85 * 25 / (power_generators / power_generator_groups)**0.2​

    The actual effect of this is, if every power generator is by itself (not touching any other power generator) you get the maximum efficiency, and efficiency suffers if too many power generators are touching. For 100 scattered power generators (no touching) you'd get about 1252.97 e/sec; for 100 power generators arranged as 10 lines of 10 blocks you'd get about 790.57 e/sec, and for a single group of 100 power generators you'd get about 498.82 e/sec.


    Summary

    This entire post only took me about 1 day to put together, and if the final formulas I ended up with (which were mostly pulled out of my rear) were actually implemented I wouldn't be too surprised if the game became fairly close to balanced.

    I'm sure there's something in all of the stuff above that's not quite right or could be better or was overlooked (or intentionally omitted). That's not really the point though - it's all just a big example. The point is that it's possible to balance a game in this way, and it'd probably only take a few days to actually do it properly (and another day or so to update the game's source code).
     
    Joined
    Aug 29, 2013
    Messages
    61
    Reaction score
    14
    I can't believe I actually made it all the way through your post, but what a write up.
    I love your ideas here, though there are a few holes and flaws.

    #1, you talk about Power, but you don't detail that power tanks and power generators each take up half the permitted '25%' of your 'well rounded ship', and I think your numbers failed to pick this up.

    #2, you talk about thrust and how you want it to balance for a painfully slow accelerating ship:
    mass_per_block = 0.1 "somethings" = 1000 Kg
    force_per_thruster = 4 * mass_of_block * 3 = 1333.333 newton

    How on earth did you work that out?
    4 * 1000(kg) * 3(m/s^2) = 12000 Newtons, not 1333.333.

    But then you drop this bombshell:
    thruster_block_power_consumption_per_second = 16.66

    Innocent, but now your thrusters draw more power than your power generators generate by a radical amount because your power generators are balanced up to power 2/3 of the ship when you forgot you had to split your power group in half (for storage)! Numbers:
    200 block ship = 25 power generators, 25 power tanks, 50 thrusters
    power regen per second = 25*25 = 625
    thrust power draw per second = 50 * 16.66 = 833

    #3, By the time you go through shields, I start to question how much you actually tested your math out. Clearly you've spent a lot of time here and I'm in no way saying it's all garbage because honestly a lot of this is pure gold, but your numbers, especially early on, don't add up. Of course, I was building an excel based calculator for your write up as I was reading through it the second time and your formula for things like shield leakage just destroyed all hope of having shields up while moving or shooting. Thats not to say shield leakage is a bad idea, I bloody love it! Just, your numbers are off.

    Around now you're also starting to write out your equations in more detail and that's great, but you also end up merging equation lines that should be left separate, e.g:

    shield_capacity = shield_recharge_per_second * 30 = 76 * shield_storage_blocks * 30 = shield_storage_blocks * 2280

    Looks fine at a glance, but shield capacity shouldn't be based on recharge rate or even be comparable to recharge rate, only storage blocks. Thankfully your forumla for shields further down relies entirely on storage blocks!

    Honestly, what you've got here is a great foundation. I personally recommend you go away and plug together a spreadsheet or something and actually look at how a "well rounded ship" would work out for you, how the numbers would balance, etc, and look at potential DPS compared to shield regen/etc, because having two "well rounded ships" that could never beat each other in a static gun fight would be ridiculous, yea?

    Good work so far, great effort, just needs properly working through I feel.

    ~CR~
     
    Joined
    Aug 23, 2013
    Messages
    379
    Reaction score
    65
    I can't believe I actually made it all the way through your post, but what a write up.
    I love your ideas here, though there are a few holes and flaws.

    #1, you talk about Power, but you don't detail that power tanks and power generators each take up half the permitted '25%' of your 'well rounded ship', and I think your numbers failed to pick this up.
    You're right - I messed up the early power formulas (didn't take into account that only half of power blocks are regen) so all the power is messed up everywhere after that.

    #2, you talk about thrust and how you want it to balance for a painfully slow accelerating ship:
    mass_per_block = 0.1 "somethings" = 1000 Kg
    force_per_thruster = 4 * mass_of_block * 3 = 1333.333 newton

    How on earth did you work that out?
    4 * 1000(kg) * 3(m/s^2) = 12000 Newtons, not 1333.333.
    It looks like I divided by 3 instead of multiplying by 3 :)

    But then you drop this bombshell:
    thruster_block_power_consumption_per_second = 16.66

    Innocent, but now your thrusters draw more power than your power generators generate by a radical amount because your power generators are balanced up to power 2/3 of the ship when you forgot you had to split your power group in half (for storage)! Numbers:
    200 block ship = 25 power generators, 25 power tanks, 50 thrusters
    power regen per second = 25*25 = 625
    thrust power draw per second = 50 * 16.66 = 833
    This is caused by my first mistake (didn't take into account that only half of power blocks are regen).

    #3, By the time you go through shields, I start to question how much you actually tested your math out. Clearly you've spent a lot of time here and I'm in no way saying it's all garbage because honestly a lot of this is pure gold, but your numbers, especially early on, don't add up. Of course, I was building an excel based calculator for your write up as I was reading through it the second time and your formula for things like shield leakage just destroyed all hope of having shields up while moving or shooting. Thats not to say shield leakage is a bad idea, I bloody love it! Just, your numbers are off.
    For how much I tested my maths out, the answer is zero. The idea was to show the process of creating formulas for game balance and not to actually create balanced formulas. Basically: "The assumptions I'll use and the formulas I come up with are only intended as a demonstration - I'm not suggesting that these formulas actually be used (and only suggesting that the mathematical approach be adopted)."

    Around now you're also starting to write out your equations in more detail and that's great, but you also end up merging equation lines that should be left separate, e.g:

    shield_capacity = shield_recharge_per_second * 30 = 76 * shield_storage_blocks * 30 = shield_storage_blocks * 2280

    Looks fine at a glance, but shield capacity shouldn't be based on recharge rate or even be comparable to recharge rate, only storage blocks. Thankfully your forumla for shields further down relies entirely on storage blocks!
    If you mean this formula:
    shield_capacity = shield_storage_blocks * 2280

    Here's were it came from:

    shield_capacity = shield_recharge_per_second * 30 = 76 * shield_storage_blocks * 30 = shield_storage_blocks * 2280

    Mostly I'm trying to show how the initial assumption "from shields down to full shields in 30 seconds" becomes a formula for shield capacity.

    Honestly, what you've got here is a great foundation. I personally recommend you go away and plug together a spreadsheet or something and actually look at how a "well rounded ship" would work out for you, how the numbers would balance, etc, and look at potential DPS compared to shield regen/etc, because having two "well rounded ships" that could never beat each other in a static gun fight would be ridiculous, yea?
    Ironically; the goal of my original post was to recommend that Schema goes away and plugs together a spreadsheet or something (develop his own formulas that ensure game balance, based on his own assumptions and his future plans, for the game he is designing).
     
    Joined
    Oct 13, 2013
    Messages
    109
    Reaction score
    81
    I like that power would have diminishing returns, but I have some issues with weapons having diminishing returns. Namely, it's the situation we used to have, which led to the obviously optimal strategy of hundreds of 1-10 block weapons rather than a single massive weapon, which was weird and caused lag. If the diminishing returns were global (ie, adding a block not connected to another block reduced the damage of the first block), then there would be some non-intuitive results of adding a secondary weapon or point defense turret. Why should the mere presence of a missile rack reduce the effectiveness of my main cannon? Why does a 10-block gun do less damage on a titan than on a fighter? Keeping damage standardized allows easier reasoning about weapon effectiveness.
    My other issue is that of power generators and efficiency, and it is purely logistical. If power generators produce more power when they are not in groups, you are penalizing those who use the handy mass-block-placement tools in advance build and rewarding tedious acts. In practice, placing power would become "put down a 1x10 sheet and delete every other block, rinse and repeat" which could take *hours* on larger ships.

    Aside from those issues, I fully support your formulas. The main thing I support, however, is the act of working backwards mathematically from the desired result. The current solution of leaving it up to individual servers to balance the game is bad because it leads to fragmentation. I want to be able to design a ship on one server and have it work as-is on another server in almost any case (barring, say, modded servers) without having to tediously refit my ships every time.
     
    Joined
    Jun 15, 2014
    Messages
    914
    Reaction score
    77
    • Legacy Citizen
    large ships should be a lot more powerful then small ships i don't like the idea of dimishing effects it makes building large ships pointless to build what needs to happen is the economy to be fixed
     
    Joined
    Aug 29, 2013
    Messages
    61
    Reaction score
    14
    Ironically; the goal of my original post was to recommend that Schema goes away and plugs together a spreadsheet or something (develop his own formulas that ensure game balance, based on his own assumptions and his future plans, for the game he is designing).
    Ironically, with a few more days pouring over the numbers and tweaking the offsets, multipliers and drop-off curves, you'd actually pretty much nail a good alternative to the current state of gameplay balance. I might even be able to help along the way =)

    large ships should be a lot more powerful then small ships i don't like the idea of dimishing effects it makes building large ships pointless to build what needs to happen is the economy to be fixed
    Economy is something totally different and doesn't address the balance in combat.

    I like that power would have diminishing returns, but I have some issues with weapons having diminishing returns. Namely, it's the situation we used to have, which led to the obviously optimal strategy of hundreds of 1-10 block weapons rather than a single massive weapon, which was weird and caused lag.
    You should then be considering limiting the number of concurrent weapon systems that can fire from a single computer - so no more 10,000 x 1block cannons!
     
    Joined
    Aug 23, 2013
    Messages
    379
    Reaction score
    65
    I like that power would have diminishing returns, but I have some issues with weapons having diminishing returns. Namely, it's the situation we used to have, which led to the obviously optimal strategy of hundreds of 1-10 block weapons rather than a single massive weapon, which was weird and caused lag. If the diminishing returns were global (ie, adding a block not connected to another block reduced the damage of the first block), then there would be some non-intuitive results of adding a secondary weapon or point defense turret. Why should the mere presence of a missile rack reduce the effectiveness of my main cannon? Why does a 10-block gun do less damage on a titan than on a fighter? Keeping damage standardized allows easier reasoning about weapon effectiveness.
    I only really looked at a single weapon. I'd guess that when there are 2 or more separate weapons (e.g. connected to different weapon computers) then the DPS for each weapon would be calculated separately (e.g. "weapon_DPS_for_this_weapon_computer = weapon_blocks_connected_to_this_computer**0.9 * ...."). I'd also assume that for a single weapon with multiple outputs you'd just divide the weapon's DPS by the number of outputs.

    My other issue is that of power generators and efficiency, and it is purely logistical. If power generators produce more power when they are not in groups, you are penalizing those who use the handy mass-block-placement tools in advance build and rewarding tedious acts. In practice, placing power would become "put down a 1x10 sheet and delete every other block, rinse and repeat" which could take *hours* on larger ships.
    I'd prefer to fix that problem by adding a "cut & paste" feature to the advanced build tool that (e.g.) lets you select a 10*10*10 group of blocks and copy it wherever you like. :)

    Aside from those issues, I fully support your formulas. The main thing I support, however, is the act of working backwards mathematically from the desired result. The current solution of leaving it up to individual servers to balance the game is bad because it leads to fragmentation. I want to be able to design a ship on one server and have it work as-is on another server in almost any case (barring, say, modded servers) without having to tediously refit my ships every time.
    Thanks - this is mostly what I'm going for. :)
     
    Joined
    Aug 23, 2013
    Messages
    379
    Reaction score
    65
    Ironically, with a few more days pouring over the numbers and tweaking the offsets, multipliers and drop-off curves, you'd actually pretty much nail a good alternative to the current state of gameplay balance. I might even be able to help along the way =)
    There are several problems with that idea...

    a) It's extremely likely that Schema has plans for new features (e.g. FTL, manoeuvring thusters, "AI crew/Dave" quarters, etc), and any of these things could throw the formulas out of whack. I can't prevent that without the ability to read minds or predict the future.

    b) I'd be extremely tempted to add features that Schema has no intention of supporting. A simple example is my "attenuated beam" idea that just happened to find its way into my formulas. A better example would be allowing space for fuel tanks and building them into the set of formulas (fuel and fuel tanks are something I really really want added to the game).

    c) It'd be a consistent set of formulas. What I mean by this is that you can't pick and choose (e.g. implement some and not others) and expect it to be balanced or sane.

    If I knew I wasn't just wasting my time I'd be very willing to do this. However, in that case I'd essentially be telling Schema what to do with his game like I was his boss or something, and I don't think Schema is willing to be controlled by someone who is (let's be honest here) just another "random nut-job" on the Internet.

    What I'm saying here is that the only person that can design the set of formulas properly and get them into the game is Schema.
     
    Joined
    Aug 29, 2013
    Messages
    61
    Reaction score
    14
    While I share your thoughts on this, don't forget there is a wider modding community too. By limiting changes to what we can change through the configuration available to us, we can all invent our own system and I don't see your work above as being that far from possible in the current version of the game - at least, until you get on to inventing your own systems like shield storage blocks. ;)
     

    Lecic

    Convicted Lancake Abuser
    Joined
    Apr 14, 2013
    Messages
    5,107
    Reaction score
    1,228
    • Thinking Positive Gold
    • Purchased!
    • Legacy Citizen 11
    Math isn't the only thing you can account for when balancing the game. If people battled with spreadsheets of statistics like an old table top game, I'd agree, but we need to remember how this stuff applies to actual gameplay.
     
    Joined
    Aug 29, 2013
    Messages
    61
    Reaction score
    14
    Oh I totally agree with you Lecic, but in order to provide something that's at least capable of engaging the player, you need to start with the base-line math. Without it, you end up with a half dozen systems that fight each other internally and fail either instantly or when applied to extremes (gigantism for example).
    By starting with a well formulated and well structured mathematical model (and I would be shocked if Schema & Crew didn't have that already!), you can introduce that to the playerbase who will go on to find the drawbacks and limitations (much to what we're all doing right now really) and propose solutions to problems being found.
     
    Joined
    Oct 13, 2013
    Messages
    109
    Reaction score
    81
    Economy is something totally different and doesn't address the balance in combat.
    I strongly disagree. The economy is what decides who can bring what kind of ship to a fight. Part of the reason the game feels so unbalanced towards larger ships is that there's no real cost to having a bigger ship except for the time it takes for you to build it (which doesn't apply if you download a blueprint from the internet). If a titan's incredible power is balanced by the fact that it was very difficult to obtain and losing it would be catastrophic, suddenly it's okay that its size allows it to win 9/10 battles without so much as chipping its paint. Because that last battle, where someone gets lucky, or catches the titan off-guard, or builds a smaller ship purpose-built to exploit some weakness in the titan's design (maybe a gap in turret cover or a vulnerability against long-range attacks) is *devastating*.

    What I'm getting at is that when the game has an economy, it becomes a lot more like Age of Empires or Civilization and a lot less like Warhammer. In Warhammer, you always fight between balanced armies, because there's no economy. You can't get a larger army than your opponent by having more efficient mines and bigger factories, so its critical that both sides are perfectly balanced.

    But we're dealing with a game that will eventually have an economy of one variety or another, which means that battles *won't* be fair and we don't actually want them to be. A stronger economy *should* allow you to field better spaceships, which means that bigger ships *should* defeat smaller ships. So I don't think that we should be worrying too much that titans are better than fighters, because there will be an additional hurdle in the future to acquiring one.

    We just need to ensure that a bigger ship is not *invincible* against a smaller ship, especially a specialized one. In Homeworld and Homeworld 2, an ion-cannon frigate (a highly specialized capital ship hunter) can do massive damage against a battleship or destroyer. That same battleship or destroyer can easily swat the ion-cannon frigate into smithereens, however, so its important to make sure you attack from the rear (cap ships turn slow) or with support, or when the cap ship is otherwise vulnerable.

    EDIT: I followed up this blurb with a more well-thought out one on this thread
     
    Last edited:

    Lecic

    Convicted Lancake Abuser
    Joined
    Apr 14, 2013
    Messages
    5,107
    Reaction score
    1,228
    • Thinking Positive Gold
    • Purchased!
    • Legacy Citizen 11
    I strongly disagree. The economy is what decides who can bring what kind of ship to a fight. Part of the reason the game feels so unbalanced towards larger ships is that there's no real cost to having a bigger ship except for the time it takes for you to build it (which doesn't apply if you download a blueprint from the internet). If a titan's incredible power is balanced by the fact that it was very difficult to obtain and losing it would be catastrophic, suddenly it's okay that its size allows it to win 9/10 battles without so much as chipping its paint. Because that last battle, where someone gets lucky, or catches the titan off-guard, or builds a smaller ship purpose-built to exploit some weakness in the titan's design (maybe a gap in turret cover or a vulnerability against long-range attacks) is *devastating*.

    What I'm getting at is that when the game has an economy, it becomes a lot more like Age of Empires or Civilization and a lot less like Warhammer. In Warhammer, you always fight between balanced armies, because there's no economy. You can't get a larger army than your opponent by having more efficient mines and bigger factories, so its critical that both sides are perfectly balanced.

    But we're dealing with a game that will eventually have an economy of one variety or another, which means that battles *won't* be fair and we don't actually want them to be. A stronger economy *should* allow you to field better spaceships, which means that bigger ships *should* defeat smaller ships. So I don't think that we should be worrying too much that titans are better than fighters, because there will be an additional hurdle in the future to acquiring one.

    We just need to ensure that a bigger ship is not *invincible* against a smaller ship, especially a specialized one. In Homeworld and Homeworld 2, an ion-cannon frigate (a highly specialized capital ship hunter) can do massive damage against a battleship or destroyer. That same battleship or destroyer can easily swat the ion-cannon frigate into smithereens, however, so its important to make sure you attack from the rear (cap ships turn slow) or with support, or when the cap ship is otherwise vulnerable.

    EDIT: I followed up this blurb with a more well-thought out one on this thread
    The problem with that is that NO ONE ever "gets lucky" or catches a titan off guard, or anything like that. It's simply, when it comes down to it, impossible for any ship that is noticeably smaller to take down or even damage a titan.