Balancing ship modules (range, sensors, speed)

from GalCiv3 Forums

One of the frustrations in a space-based 4X game is lack of "borders" and the inability to control those borders.  This goes all the way back to the MOO2 (Master of Orion II) days where towards the end of the game, no home world was safe at all and you had to constantly move a home fleet around from world to world whenever you detected an inbound invasion fleet.  There was no way to interdict, slow-down, capture, force engagement on those fleets except by being at the spot where they landed.

There are a few problems within the current GC3 ship module game mechanics:

1) Some modules like +range and +sensor are very inexpensive, leading to the ease of abuse by stacking half a dozen or more on a hull.

2) Some modules should scale in cost based on the hull size.  Specifically +range and +speed, and maybe +defense.

3) The effect of stacking is linear, making them difficult to balance.

There are a few traditional solutions to this:

A ) Nerf the power of a particular module, or make it a lot more expensive

B ) Outlaw stacking of certain module types.  Or only allow stacking up to some limit.  Things still stack linearly up to that point.  Or force certain types of modules to fit into slots, then limit the number of slots on a particular hull type.

C ) Introduce a second and third limiting variable into the mix, which certain modules make use of.  For example, instead of hulls just having "capacity/structure" points where you treat the ship like a bag that you fill with goodies, some goodies also consume "power" points (in addition to capacity points), while other modules consume "complexity" points.

So if you have a ship with 100 power, 100 complexity and 100 structure -- then a "drive" is generally a large structure, consumes a lot of power, but has a low complexity.  A weapon system, OTOH, probably moderate consumes power but with higher complexity points, while life support mostly consumes lots of structure with low power/complexity needs.  

D ) Use "diminishing returns" on certain module types.  The first module (sorted in descending power) gets you full power, the second module works at a reduced fraction, etc.  This has always been my favorite system because it's easy to apply and developers can adjust the calculation to achieve various soft-caps on stacking.

A severe version of module stacking would be to use a factor of 0.5, which means that every additional module is half as powerful as the one before it.  So instead of 10+10+10+10+10 = 50 points of power, it calculates out as 10 + 5 + 2.5 + 1.25 + 0.625 = 19.375 points.  Now there's no point in stacking more then 2-3 of a particular module, unless you have lots of capacity to spare.  So instead of a ship range of 50, most ships will run with a ship range of 17.5 (3 stacks) until the empire researches the next tier which gives 15 points per module.  Some examples of the 0.5 factor for stacking (3) modules and (6) modules.

Module Power=10 - 17.50 (3) vs 19.69 (6)

Module Power=15 - 28.13 (3) vs 29.53 (6)

Module Power=20 - 35.00 (3) vs 39.38 (6)

Sample spreadsheet:

https://docs.google.com/spreadsheets/d/1crbfax7uEnsoHQZrStIrPmpu3ZcBnlK9ZuoryCAJn7g/edit?usp=sharing

A factor of 0.5 puts the upper limit that a ship can receive from a particular module tech (i.e. range 9 life support) at two times the base value.  If you want to allow stacking up to three times the base value for some module type then use a factor of 0.67; to allow a maximum of four times the base value use a factor of 0.75.

Suggested factors for various modules:

+range - factor=0.62, so that a stack of (3) gives a 2.00x boost, but that fourth module only gets you to  2.24x.

+speed - factor=0.825, a stack of (3) gives 2.51x, stacking (4) gives you 3.07x and stacking (6) gets you 3.91x base speed.

+sensor - factor=0.75, stacking seven only gives you 3.47 times the base strength instead of 7.00x.

+defense - factor=0.9, stackable up until about depth 10, but you only get 6.51x instead of 10x the base strength

These factors should be placed in the XML files for tweaking.  Players who don't like the change at all can change the factors back to 1.00 in the XML.

The primary benefits are:

- Engine tech becomes slightly more important.  If you want to go faster, then you need a higher base module speed from technology improvements rather then just stacking two or five more of a lower tech engine on the hull.

- Life support tech become much more important as you can only stack 3-4 on a single hull before it gets cost-prohibitive.

- Sensor power and fog-of-war gets a slight nerf.

- Stacking defense modules gets a slight nerf.

- Gives another dial (factor) that can be used for game balance, or racial traits.  One race might be better at a particular module type stacking then another race.  Race X might be able to shave 25% off the stacking penalty so that instead of a factor of 0.6, they get a factor of 0.7 for that module type.

10,221 views 5 replies
Reply #1 from GalCiv3 Forums Top

Honestly, that's overtly complex.

 

The major problems are relatively easily solved with two changes:

  1. Disallow sensor stacking. Sensors (excluding the Survey modules, which are already one-per-ship) of all kinds are only allowed one-per-ship.  The additional change then is to have several additional sensor packages available later in the Sensor Tech tree section.
  2. Drive and Range modules should be scaled by Hull Type. The fact that they don't right now is dumb; you're telling me that a drive is the same size for moving something that has 10x the mass of another ship?  Same for Life Support.  Both merely need a tweak to increase their mass roughly 25% for each increase in Hull size.  Leave stacking alone.

 

I dislike "diminishing returns" models for two main reasons:   they're hard to get a quick grasp on because the multipliers are always hidden, and it's a overtly complex solution compared to the much more straightforward one of caps and properly balanced modules.

 

That is, you have to properly balance the modules (for mass/cost/manufacturing) anyway, so why add a complicated scaling factor where it's not needed?

 

On the subject of balance, a lot of the sensors/engines/lifesupport need a drastic rebalance. As it stands, pretty much all of them are just linear improvements.  That is, a Level 2 engine costs about 25% more than a Level 1 engine, provides 25% more speed, has 25% more mass, etc.  This is what leads to the problem of multiple lower-tech engines rather than higher tech ones.  It's particularly evident in Life Support.

A properly balanced progression would do something like a 25% increase in speed, for a 10% increase in mass, at a 35% increase in cost, for each tech level.

Reply #2 from GalCiv3 Forums Top

Sensor stacking has been repeatedly supported by Brad as someone who loves his sensor boats.  I don't think that removing stacking will be a successful suggestion for redesign.

Also, what you react to as a "frustration", I see as an intriguing challenge.  Effectively, I am defending borders without land troops, as I see it, and that is a very different kind of challenge.  So, I am not convinced how much needs fixing here.

ObjectDock - Access shortcuts and frequently used applications from an animated dock.
Reply #3 from GalCiv3 Forums Top

My problem is that is it could quickly take some fun out of the game if you restrict speed and range too much. You already balance your ship by selecting either an extra range module or an extra weapons module. If you start having artificial caps/reductions then it takes the choice away from the player.

At the end of the day who is to say that an alien species can't stack their ships full of long-range sensors and telescopes and specialise in seeing across the universe? 

Reply #4 from GalCiv3 Forums Top

Quoting trims2u, reply 1

The fact that they don't right now is dumb; you're telling me that a drive is the same size for moving something that has 10x the mass of another ship?

What evidence would you care to provide for the supposed dumbness of a space-warping device's size being unrelated to the size of the object which is using said device to propel itself? You are not talking about a drive system which is accelerating an object according to classical Newtonian physics; indeed, it's entirely possible that to an observer within the region of distorted space generated by the device, the object being moved by the device would not appear to be moving at all. Instead, you are talking about a device which may be distorting space to such a degree that a distance of several lightyears may appear to be a distance which can be traversed in the space of a single week using propulsion systems which cannot exceed c, or which appears to move the destination to the ship rather than the ship to the destination.

I do not disagree with the idea that ship drive systems need to scale with hull size to some degree, but this is for reasons of game balance, not 'realism.' I know of no real reason why a space-warping device that can make a distance of multiple lightyears traversible within a week should necessarily need to be significantly larger on large ships than on small ships.

Quoting trims2u, reply 1

Disallow sensor stacking. Sensors (excluding the Survey modules, which are already one-per-ship) of all kinds are only allowed one-per-ship. The additional change then is to have several additional sensor packages available later in the Sensor Tech tree section.

I have a couple of issues with this suggestion.

Firstly, you're restricting the design space. If I can only put one sensor component on a ship, I either have a sensor component on the ship or I do not; I cannot freely trade between speed, sensor range, and travel range to come up with a balance that I feel is good for whatever purpose the ship is to perform with this limitation. By removing the ability of the designer to trade between these three aspects, you are removing the distinction between an exploration vessel (which wants a balance of speed, range, and sensor range) and an observation vessel (which wants just enough speed to not take excessive amounts of time to get into position, just enough range to go far enough forward to be useful, and as much sensor range as can fit elsewhere).

Secondly, by limiting the attainable sensor ranges without similarly limiting the attainable speeds, you run a great risk of making sensor range virtually worthless. A sensor network that cannot provide at least one turn of warning before an attack hits something valuable is a sensor network whose only value is in the information it provides about the composition (weapons, defenses, hull sizes, number of ships, maybe ship roles) of another empire's fleet (and this information can be obtained by means of scout ships at least as easily as it can be obtained with a much larger sensor network), and your proposal regarding drives will only cut ship speeds by ~50% or so depending on what exactly is meant by increasing the capacity requirement of a drive component by 25% for each increase in hull size. Even with the most generous interpretation of a 25% increase in component size with each increase in hull size (drive components on Huge hulls require 1.25^4 ~= 2.44 times the hull capacity that the same components would require on Tiny hulls), you can still easily fit four or five Stellar Folders onto a Huge hull without severely negatively impacting its performance, as by the time you have access to Huge hulls you can also have a bonus of ~100% to hull capacity (40-50% from specialization techs in the construction branch, about another 50% from a Hyperion Shrinker, perhaps another few 5% bonuses per Helios Ore, and perhaps another 10% per Design Revolution event). 5 Stellar Folders require about 220 capacity at 2.44 times standard size (and this presumes that the player has not obtained any of the drive size reduction specializations on the way), giving the ship a base speed of 31 before modifiers; a Huge hull probably has ~500 capacity by the time you unlock it, and can potentially see its hull capacity increase further.

Thirdly, you are potentially removing a large part of the cost to providing a sensor ship with other capabilities. If the sensor suite does not fill up the hull, there is little reason for me not to provide the sensor vessel with whatever other capabilities I can fit into the hull that I feel are worthwhile; thus, if the sensor suite is sufficiently small, my sensor ships may well be full-fledged battleships without suffering any significant reduction in performance in either role. Even if the sensor suite is large enough to discourage that, I may be able to have high speed, long range, and wide-area sensor coverage all on the same ship whereas under the current model each of these things can only come at a cost to one or both of the others.

Reply #5 from GalCiv3 Forums Top

If the goal is to introduce a soft-cap on ship speed, then Military Starbases should also be looked at. In my current game I'm flying Constructors around my empire with moves close to 100, with only 2 Drivers installed (granted, they are Stellar Folders, but still). At least it is harder to sustain such speeds in enemy territory over several turns.