Fractal Softworks Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

Starsector 0.9.1a is out! (05/10/19); Updated the Forum Rules and Guidelines (02/29/20); Blog post: GIF Roundup (04/11/20)

Pages: [1] 2 3 4

Author Topic: Modding Guidelines  (Read 58020 times)

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2553
    • View Profile
    • Sc2Mafia
    • Email
Modding Guidelines
« on: February 11, 2015, 01:33:32 PM »

This post is meant to explain numerous observations, most of which are undocumented and discovered through analysis, trial-and-error, or word of mouth.  Feel free to discuss my findings and suggest more things to add.

Terminology
Should – A recommendation.  Not a huge deal if you deviate, but make sure there's a purpose for it.
Shall – A requirement.  You may deviate only if there is a compelling reason for it.



Ship Design
  • Sprite:
    • Ship volume should remain reasonably close to the average for its size classification.  A sprite with the visual size of a Dominator is visually recognizable as a cruiser, so the ship's classification ought to be "cruiser," to match.
    • The ship sprite should not be excessively large.  It is difficult to play the game with ships that are too large, the AI can choke, balance becomes an issue, effects can become problematic, etc.
    • Empty (full-alpha) borders on the sprite should be avoided.  However, you should leave 1 pixel on each border, to avoid texture filtering issues in some situations.  The extra pixels potentially use more video memory and can cause the AI to have trouble hitting the ship.  You do not have to edit existing sprites, however (unless it's way off), because you will potentially have to re-do the hull file.
  • Layout:
    • Weapon slot count shall not be excessively high.  Frigates do not have large slots.  Destroyers have up to one large slot.  Cruisers have up to two large slots.  Capital ships have up to four large slots.  For broadside ships, like the Conquest, only count one broadside (the larger one, if they are different sizes) for this figure.  These figures do not include built-ins, which can be balanced specifically for a particular ship.  Slight deviation is allowed in compelling circumstances, but too much of this is highly frowned upon.
    • Universal slots shall be considered significantly better than mono-type slots.  The potential for optimized or even game-breaking loadouts is much greater when universal slots are used.  Consider universal slots to be an advantage that compensates for some other weakness, such as below-average slot count/size (see the Doom for an example).
    • Weapon arcs should be kept conservative.  It is a significant advantage to have numerous converging weapon arcs; consider using hardpoints instead of turrets if the ship has numerous overlapping frontal arcs.
    • Weapon arcs shall not break the illusion of shape and depth.  A weapon should not be able to shoot "through" a section of the ship it would not reasonably have line of sight to, given the weapon's "3D" position on the sprite.
    • Universal, Synergy, and Composite slots should be used sparingly.  It is more difficult to balance these slots, and ships with these slot types are more difficult to outfit.  The fact that missiles can be put in these slots can lead to a huge alpha-strike build-up.  It helps to treat them as if they are more powerful Missile slots.
    • Hybrid slots should be used carefully.  Ships with hybrid slots are more difficult to outfit, and hybrid slots cannot be downgraded in size.  However, compared to the other mixed types, Hybrid is not as much of an issue.
    • Hidden weapons should be avoided, except on drones and fighters.  These slots tend to have more issues than other types of slots, especially if missiles are mounted on them.

Ship Stats
  • Structure:
    • Armor shall not be excessively high.  Fights with ships that have more than twice the armor of an Onslaught are uninteresting at best, badly broken at worst.
    • Mass should represent the ship's size and perceived weight.  Excessively high or low values can cause strangeness and erroneous collision damage calculations.
    • Hull points should represent the visual size of the sprite.  Durable or fragile ships ought to have hull adjusted up or down, respectively, but the baseline for hull is essentially how meaty the ship looks.
  • Ordnance:
    • Ordnance points should be sufficient to install a baseline weapon in every slot.  The baseline minimum is 2 OP for small slots, 8 OP for medium slots, and 16 OP for large slots.
    • Ordnance points for military ships should be sufficient to install a standard weapon in every slot and half-way fill vents and capacitors.  The standard is 5 OP for small slots, 10 OP for medium slots, and 20 OP for large slots; 10 OP for frigates, 20 OP for destroyers, 30 OP for cruisers, and 50 OP for capital ships.  The typical standard is to count the slots, add 5/10/20 OP for each of them (depending on size), and then add 15/30/45/75 OP based on hull size, though some ships will differ (particularly battleships, which add more like 115+).
  • Crew:
    • Skeleton crew should not be excessively low compared to vanilla ships of the same classification, unless the ship consumes supplies at an accelerated rate or otherwise has a built-in High Maintenance hull mod.  10 crew on a destroyer is probably not okay.
    • Skeleton crew should not be excessively high compared to vanilla ships of the same classification.  1000 crew on a cruiser is not okay, especially since this makes the half-crew-requirement perk way more powerful.
  • Logistics:
    • Fleet points shall represent the ship's combat capability.  Fleet points are used for many internal calculations, especially fleet construction and threat assessment.  Vanilla benchmarks include 6+ for high-tier frigates, 11+ for high-tier destroyers, 16+ for high-tier cruisers, and 26+ for high-tier capital ships.
    • Supplies per deployment shall represent the combat prowess of the ship, compared to vanilla ships of the same classification.
    • CR recovery rate should remain close to vanilla ships of the same classification.  Adjust up or down to a reasonable degree if the ship should seem more or less reliable.
    • Supplies per month should be equivalent to supplies per deployment.
  • Flux:
    • Frontal shield arcs shall be a multiple of 2.  Otherwise, omni shield conversion will not divide into a whole number.
    • Shield efficiency shall be reasonable.  In vanilla, extremely good shields have efficiency 0.6, average-to-good shields have efficiency 0.8, poor shields have efficiency 1, and terrible shields have efficiency 1.2 or greater.  Take into account flux capacity; a larger capacity makes for stronger shields.
    • Flux capacity should trend toward vanilla ratios.  These are 12.5x dissipation for frigates, 16.67x dissipation for destroyers, 20x dissipation for cruisers, and 25x dissipation for capital ships.  Adjust depending on balance.
    • Shield arc should be a common angle.  Angles used in vanilla include 45, 90, 120, 150, 160, 180, 270, 300, and 360.
  • Travel:
    • Burn speed should fall within vanilla limits.  Fighters: burn 9 to burn 11.  Frigates: burn 9 to burn 11.  Destroyers: burn 8 to burn 9.  Cruisers: burn 7 to burn 8.  Capital Ships: burn 6 to burn 7.  Note that burn 11 is exceedingly rare, reserved for only the best and the fastest ships.  The lower end of the burn range for any given ship class, particularly burn speeds below 8, is considered a significant disadvantage.  Many players would rather have a more expensive, weaker fast ship than a cheap, effective, but slow ship.
    • Hyperspace range should be roughly similar to vanilla.  Average ships travel 40-60 light years, efficient ships travel 80-100 light years, and clunkers travel 20-30 light years.  Tankers are exempt.
    • Fuel per light year should follow vanilla guidelines.  Frigates: 1 fuel per light year.  Destroyers: 2 to 3 fuel per light year.  Cruisers: 3 to 5 fuel per light year.  Capital Ships: 10 to 15 fuel per light year.  Significant deviations can cause metagame issues in the campaign.  Tugs are exempt, but should be around 5 fuel per light year per ship towed.
  • Description:
    • All ships and skins shall have a description in descriptions.csv or the .skin file.
    • All ship systems shall have a description in descriptions.csv.
    • The first paragraph of the description shall fit in the mouse-over dialog window without being cut off.
  • Price and rarity shall not be considered important balancing stats.  If the ship is simply better than other options in anything but a very minor or superficial way, it ought to be changed -- rare or not.  Logistics stats are a better last-ditch balancing tool.
  • Extreme weaknesses shall not be used to counteract extreme strengths.  Weaknesses can be worked around or avoided by a player, while the strengths can be ludicrously maximized with the right tools.  Particularly unusual ships also confuse the AI.
  • All ships that can be piloted by the player shall have a ship system.

Hull Files
  • Bounds:
    • Ship bounds shall represent a polygon.  Non-polygonal shapes (such as an hourglass made from only four points) cause undefined behavior.  Vertices or edges that overlap are allowed only if the edges do not fully cross over each other.
    • Ship bounds should be simplified in shape to avoid unnecessary points.  Collision detection can be slow if there are too many points on the bounds.  See the Aurora hull file for a good, if somewhat overzealous example.
    • Large hollow areas should be carved out of the ship bounds.  See the Paragon hull file for an example.
    • Overall ship bounds should be convex.  Large concave sections can cause AI issues.
  • Radius:
    • The center of the collision radius shall be reasonably exact to the ship's center of mass.
    • The collision circle shall encapsulate the entire ship bounds.
    • The entire shield circle shall be encapsulated by the collision circle.
  • Weapons:
    • Modular weapon mounts shall be centered on the graphical slot sprite, except where doing so causes awkward visuals or poor overlaps.
    • Built-in weapons with a painted-on sprite shall have an arc of 0 degrees.
    • Weapons of the same size and type shall not overlap.
    • Hardpoints should have an arc of 5 degrees.  For certain ships or situations with widely-spaced hardpoints, larger arcs (such as 10 degrees) may suffice.
    • Weapon overlap shall have larger weapons placed visually higher on the sprite than smaller weapons.  Larger weapons always render on top of smaller weapons.
    • Weapon overlap should be avoided where possible.  However, sometimes this is unavoidable or is visually acceptable due to the ship's "3D" shape.
  • Engines:
    • Custom engine styles shall be defined in engine_styles.json.  Defining inline engine styles causes confusion and is hard to support.
    • Engines should be 1 pixel out from the edge of the sprite.  However, some situations exist where a different distance (typically, towards the ship) is desirable.
    • Engine quantity should be minimized.  If multiple thruster trails could be combined without visual issue, do so; engines are computationally expensive.
  • Ships should not use TwigLib.  Use it only when there is a good reason to do so, because using it is a lot of extra work, can cause problems, and is hard to support.

Weapons
  • Description:
    • All modular weapons shall have a description and role classification in descriptions.csv.
    • All weapons with the SHOW_IN_CODEX flag shall have a description and role classification in descriptions.csv.
    • All built-in weapons that appear on a ship that can be piloted by the player shall have a description and role classification in descriptions.csv.
    • The first paragraph of the description shall fit in the mouse-over dialog window without being cut off.
    • Built-in weapons that appear on a ship that can be piloted by the player should have the SHOW_IN_CODEX flag, except in situations where this would not be useful (such as for redundant entries, e.g. mirrored weapons, or utility weapons, e.g. those used for TwigLib).
    • System/utility weapons that don't show up in a visible weapon slot and are not otherwise visible or useful to the player shall not have the SHOW_IN_CODEX flag.
    • Weapon role classifications should be standard.  Standard classifications include Assault, Close Support, Fire Support, Strike, Anti-Fighter, Point Defense, and Special.
  • Sprite:
    • Non-built-in weapons shall have a turret and a hardpoint version.  The hardpoint version may be the same sprite as the turret version, just aligned differently.
    • Weapon sprite alignment and barrel locations shall be correct.  Remember, the "origin" of a turret is the exact center of the sprite (50% from the bottom and left), and the "origin" of a hardpoint is a quarter-length up the sprite (25% from the bottom and 50% from the left).
    • Weapon sprites shall not be unusually small or large for their slot size.  Deviating from this causes overlap issues in many cases, and can just look silly.  Built-in weapons are exempt.
    • Empty (full-alpha) borders on the sprite should be avoided, except to enforce correct alignment.  However, you should leave 1 pixel on each border, to avoid texture filtering issues in some situations.  The extra pixels potentially use more video memory.  Do not edit existing sprites, however, because you will have to re-do the alignment and barrel offsets.
  • Range:
    • Unusually long-ranged ballistic and energy weapons shall have significant drawbacks.  For example, the Gauss Cannon has a elevated OP cost and is inefficient.
    • Ballistic and energy weapons should fall within vanilla range tolerances.  Small weapons are considered long-range at 700-800 range, medium weapons are long-range at 900-1000 range, and large weapons are long-range at 1100-1200 range.
    • Small missile weapons should not be LRMs.  Exercise extreme caution with small LRMs, because they are far more easily massed than other types of missiles.
  • Balance:
    • Price and rarity shall not be considered important balancing stats.  If the weapon is simply better than other options in anything but a very minor or superficial way, it out to be changed -- rare or not.  Ordnance Points are a better last-ditch balancing tool.
    • Armor penetration shall be considered an important stat.  Remember: higher damage per shot (or damage per second for a beam) means it penetrates armor better.
    • Burst damage shall be considered an important stat, especially for small and medium weapon slots that one might find on faster ships.
    • Weapon OP costs shall fall broadly near vanilla levels.  Small weapons: 1 to 9 OP.  Medium weapons: 8 to 15 OP.  Large weapons: 16 to 32 OP.  Exceptions may be made for top-tier weapons that are not usually available for purchase.
    • Extreme weaknesses shall not be used to counteract extreme strengths.  Weaknesses can be worked around or avoided by a player, while the strengths can be ludicrously maximized with the right tools.  The AI is also generally incapable of working around the limitations of weapons.
    • Weapons should use vanilla stats as a baseline.  Significant deviations from vanilla weapons should have a corresponding penalty elsewhere, such as slot size, OP, flux cost, range, and so forth.
  • Markets:
    • Weapons shall not have tier above 3 or below 0.  The only exception is if the weapon is not intended to be able to be purchased anywhere (except a custom market, presumably).
    • Weapon tier shall reflect how desirable the weapon is.  A top-tier weapon should be tier 3 while cheap/knock-off/degraded/inferior hardware should be tier 0.
    • Weapon prices should be within the same ballpark as similar size/tier/OP vanilla weapons.

DynaSector Compatibility
  • Weapon mounts that are intended to be mirrored shall have exactly identical arcs and exactly inverted angles.  For example, if one mount has angle 50 degrees and arc 120 degrees, the angle should be -50 or 310 degrees and the arc should be 120 degrees.  Otherwise, the randomizer will not mirror weapon assignments.
  • Non-mirrored weapon mounts (such as the middle of three medium ballistic hardpoints, two different pairs of small missile hardpoints, etc.) should have different angles or arcs.  For example, if mirrored pair A has angle 50/-50 degrees and arc 120 degrees, mirrored pair B should have angle 50.01/-50.01 degrees or arc 120.01 degrees.  Otherwise, the randomizer will mistakenly mirror weapon assignments to these slots.
« Last Edit: November 23, 2017, 12:50:27 AM by Dark.Revenant »
Logged

Thaago

  • Global Moderator
  • Admiral
  • *****
  • Posts: 4601
  • Quantum Mechanic
    • View Profile
    • Email
Re: Modding Guidelines
« Reply #1 on: February 11, 2015, 01:41:01 PM »

+1. A good set of guidelines. I especially like the emphasis on universal weapon slots: they are very powerful, especially when multiple mods are combined and the player has access to a huge diversity of weapons.
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 16580
    • View Profile
Re: Modding Guidelines
« Reply #2 on: February 11, 2015, 01:51:31 PM »

Very nice! Lots of useful information in a very concise form.

Quick comment:
Quote
The shield circle shall encapsulate the entire collision circle.

It's the other way around - any part of the shield that's outside the collision circle will not actually be hit.
Logged

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2553
    • View Profile
    • Sc2Mafia
    • Email
Re: Modding Guidelines
« Reply #3 on: February 11, 2015, 01:56:58 PM »

Whoops, I always put the shields as slightly higher than collision radius.  The difference was small enough that it was effectively imperceptible.
Logged

Alex

  • Administrator
  • Admiral
  • *****
  • Posts: 16580
    • View Profile
Re: Modding Guidelines
« Reply #4 on: February 11, 2015, 02:05:03 PM »

Yeah, it'd probably just look like shots hitting a little further inside the shields, but that already happens a bit anyway due to how far a shot can move within a single frame.
Logged

Wyvern

  • Admiral
  • *****
  • Posts: 2492
    • View Profile
Re: Modding Guidelines
« Reply #5 on: February 11, 2015, 02:06:38 PM »

One thing I'd like to add:

Shield efficiency and flux capacity are complimentary values; if you need to give a ship a huge flux reserve in order to use its weapons (vanilla example: the Conquest battlecruiser), you should probably also increase the shield efficiency number.  A ship with 10,000 flux capacity and .8 efficiency shields can take exactly as much incoming damage as one with 20,000 flux capacity and 1.6 efficiency shields.  The differences are obvious - the second one can fire twice as much before maxing out on soft flux - and subtle - the first one gains twice as much benefit from ordnance points spent on increasing flux capacity, while the second has a harder time recovering from damage it has taken (assuming the same flux dissipation rate).

Logged
Wyvern is 100% correct about the math.

Midnight Kitsune

  • Admiral
  • *****
  • Posts: 2691
  • Your Friendly Forum Friend
    • View Profile
Re: Modding Guidelines
« Reply #6 on: February 11, 2015, 03:09:31 PM »

Sticky Request for this awesome thread!
Logged
Stop trying to balance the game around a few minmaxers...
Programming is like sex:
One mistake and you have to support it for the rest of your life.

Tired of having your game crash because of out of date mods? Then click here!
Spoiler
Get Version Checker today! Now with 90% less hassle! Simply toss it into your mod folder, activate the mod like a normal one and BINGO you will now be informed of any and all updates when you start SS campaign up!
[close]

Protonus

  • Captain
  • ****
  • Posts: 398
  • The Nut. Yes, this one.
    • View Profile
Re: Modding Guidelines
« Reply #7 on: February 11, 2015, 04:17:22 PM »

Well, I'm moving away from the Universal slots anyway. They are quite tedious to begin especially when you have to insert ever-confusing set of weapons to it.

I might also be the blame for the existence of the post but I am actually quite happy to see it exist in some way, since new modders can actually have a reference for once.

Thanks for the guidelines, very much.


Question though: What if the Hull points are already in halve in comparison with armor, since Onslaught is bustling with a ton of hull health already, cutting it in half while double armor still remains similarly effective, yes? Of course, the resistance of armor and hull are taken to consideration.
Logged

Join us. We have cookies.

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2553
    • View Profile
    • Sc2Mafia
    • Email
Re: Modding Guidelines
« Reply #8 on: February 11, 2015, 04:35:35 PM »

Question though: What if the Hull points are already in halve in comparison with armor, since Onslaught is bustling with a ton of hull health already, cutting it in half while double armor still remains similarly effective, yes? Of course, the resistance of armor and hull are taken to consideration.

Not really.  Some weapons are designed to kill armor no matter what (torpedoes, mostly) and beyond that it seems weird for an entire ship to explode just from shooting a small weak point a few times.  Hull really needs to reflect ship size.
Logged

Wyvern

  • Admiral
  • *****
  • Posts: 2492
    • View Profile
Re: Modding Guidelines
« Reply #9 on: February 11, 2015, 04:51:19 PM »

Yeah; the relationship between hull and armor is rather odd and non-linear, unlike the relationship between flux pool and shield efficiency.

Of course, there are always interesting exceptions, like the Rock Fly from Ironclads; there it makes sense for a ship to have absurd armor and very little hull.  But it has absurd amounts of armor, not just double anything else.
Logged
Wyvern is 100% correct about the math.

Tartiflette

  • Admiral
  • *****
  • Posts: 2918
  • Toss a coin to your Modder, O' valley of plenty
    • View Profile
Re: Modding Guidelines
« Reply #10 on: February 11, 2015, 05:00:21 PM »

Reading that it seems that I bended a lot of rules.... But most of the most important ones are weaker on my ships (weapon mounts, hull, armor, flux dissipation, shield strength) witch compensate for the few stronger ones (speed, flux capacity, fuel consumption).

I only regret there is not much about the weapons themselves, since they are often a bad offender to balance too.
Logged
 

Protonus

  • Captain
  • ****
  • Posts: 398
  • The Nut. Yes, this one.
    • View Profile
Re: Modding Guidelines
« Reply #11 on: February 11, 2015, 06:09:04 PM »

I could trim some of the armor just a little bit, other than that, I guess I am at the right track.
Logged

Join us. We have cookies.

Dark.Revenant

  • Admiral
  • *****
  • Posts: 2553
    • View Profile
    • Sc2Mafia
    • Email
Re: Modding Guidelines
« Reply #12 on: February 11, 2015, 06:09:49 PM »

Added weapon rules.  Might add more later.
Logged

Protonus

  • Captain
  • ****
  • Posts: 398
  • The Nut. Yes, this one.
    • View Profile
Re: Modding Guidelines
« Reply #13 on: February 11, 2015, 06:29:42 PM »

Small missile weapons should not be LRMs.  Exercise extreme caution with small LRMs, because they are far easily massed than other types of missiles.

I've seen how this plays out. Just have a few set of small LRMs (while still bearing the same damage) can bring a nasty nightmare for anything that is not a fighter/frigate/destroyer out of said fighter/frigate/destroyer.

Should small LRMs exist, they should go damages below SRMs or simply used for distraction purposes.
Logged

Join us. We have cookies.

etherealblade

  • Commander
  • ***
  • Posts: 134
    • View Profile
Re: Modding Guidelines
« Reply #14 on: February 11, 2015, 07:49:41 PM »

This is very helpful to those who are starting anew as well as veterans.  ;D A common core will help everyone's unique mods mesh well with each other and overall enhance our starsector experience.
Logged
Spoiler

[close]
Pages: [1] 2 3 4