Unification and balancing discussion

Discussion in 'Suggestions' started by geostar1024, Mar 22, 2019.

  1. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    In the interest of not taking over other threads with discussions of ship sizes and capabilities and the pro/con of unification of SVs and CVs, here is a thread for that purpose. I've tagged those who were active on these subjects in the alpha 9.5 thread we were just discussing things in: @Germanicus, @Sephrajin, @stanley bourdon, @vscuorzo, @krazzykid2006, @Combat Wombat, @Supay, @StyxAnnihilator

    My apologies if I missed someone or mistagged someone who didn't want to be here.
     
    #1
  2. stanley bourdon

    stanley bourdon Commander

    Joined:
    Oct 7, 2018
    Messages:
    310
    Likes Received:
    182
    I do not build a warp capable SV ever they serve no purpose in my gameplay. Nor have I ever needed (except in my first game) to leave the planet to get what I need to build my first CV. That CV is designed to carry my HV and SV and a moderate amount of cargo.
     
    #2
    SGP Corp and Germanicus like this.
  3. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    But what's the problem if someone wants to build an equivalently-sized ship out of small blocks instead of large blocks? Should that one change make any difference as to the performance and capabilities of the ship?
     
    #3
  4. Germanicus

    Germanicus Rear Admiral

    Joined:
    Jan 22, 2018
    Messages:
    2,673
    Likes Received:
    5,107
    As nice the uses of just one block size might be for smoother shapes... i.e., those HV/SV Block Sizes, the numbers needed to build larger Vessels would be ridiculous high.
     
    #4
    Sofianinho and Sephrajin like this.
  5. stanley bourdon

    stanley bourdon Commander

    Joined:
    Oct 7, 2018
    Messages:
    310
    Likes Received:
    182
    Again if the only difference is block size why? I must be missing something in your argument.

    If someone wants to build a 200-meter ship out of .5 meter blocks I guess I do not care but I do not want to see them be the same in all aspects. If there is no gameplay difference between an SV and a CV why put the developer time and effort into both?
     
    #5
    Germanicus likes this.
  6. IronCartographer

    Joined:
    Sep 27, 2017
    Messages:
    941
    Likes Received:
    1,279
    Just as it is possible to use blocks that are more than 1x1x1 for devices, so too could hull be placeable with larger blocks at a time, maintaining block count and data size/complexity even with a higher resolution grid.
     
    #6
    Germanicus likes this.
  7. Germanicus

    Germanicus Rear Admiral

    Joined:
    Jan 22, 2018
    Messages:
    2,673
    Likes Received:
    5,107
    Instead of Blocks which we put together, made of different material, my idea would be, like I read it several times in the forum before, by only planing Vessels in some sort of a VR, put together by hollow transparent Blocks, choose the kind of Material of which the outer and inner hull should be and plate it in sheets of metal, in all places where those "blocks" do not touch each other.
     
    #7
  8. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    My opinion: an attempt to create artificial division where none needed to be. They clearly had an idea about what the capabilities of ships of various sizes ought to be, but instead of creating properly scaled devices to achieve this with any block size, they chose to manually split devices between the different block sizes. We continue to have balance issues and inconsistencies as a result.

    It's an interesting idea, but would require rather fundamental changes the code that handles ship building. A similar effect could be achieved with different sized blocks (2x2x1 and 4x4x1 "plates" for example) without requiring any changes to the underlying ship-building process.
     
    #8
  9. IronCartographer

    Joined:
    Sep 27, 2017
    Messages:
    941
    Likes Received:
    1,279
    Even if you reduced the complexity (and build flexibility?) sufficiently to make it a 2.5D 'surface' (inner and outer hull), that surface would require curvature and a pixel size. If you're interested in viewing the internals nicely while building, one option is to 'shrink' the blocks in a virtual view while maintaining their positions--then you could see the entire ship at once through the gaps between them. :)

    Yeah, I wasn't part of the specific previous discussion, but have discussed this before.

    With the right rules per-device/behavior, there's no reason to have ships be divided by a different core.

    The same thing applies to downed Patrol Vessels.

    Every time a player behavior is blocked by arbitrary categories rather than a consistent set of rules, there is disappointment. There are countless players who have turned away from Empyrion in frustration at its artful yet illogical design. Balance is necessary, but I don't think vessel classification has ultimately helped, since each must be addressed individually. Meeting player expectations is easier if you have a global set of rules which each vessel naturally inherits its behavior from.

    Doing so would increase the playerbase size and health.
     
    #9
  10. DeadliestIdiot

    DeadliestIdiot Commander

    Joined:
    Aug 14, 2017
    Messages:
    71
    Likes Received:
    144
    Building off the idea of merging the two classes (puns! Haha!), how would you go about encouraging the SV fighter/runabout roles to differentiate themselves from the CV mobile base/heavy transport roles?

    My first thought is to look towards RCS limitations, perhaps via CPU, in conjunction with weight and volume mechanics (I assume here that thrusters are made to be consistent). In such a system, I think both small and large vessels could be useful in combat. The smaller, lighter vessels would not need much RCS torque to make them very agile. The agile small vessel would be a small, fast moving target. To make a larger vessel comparatively agile would require adding large numbers of RCS units (and thrusters) at the expense of offensive power and would still be a rather large target. A more sluggish large vessel, however, would be capable of carrying heavier armor and/or more layers of that armor, making up for it being an easier target. On top of that, the sluggish large vessel would be able to carry multiple turrets, mitigating the slow turning rate to some extent.

    The mobile base/heavy transport roles would naturally be dominated by the large, sluggish vessels due to the space the devices/carried vessels require and the space needed to supply sufficient power to store large amounts of cargo

    The runabout role would naturally fall to the lightweight vessels (large or small) due to the larger fuel burn needed to move a heavier vessel.

    (I'm sure I'm probably overlooking something, but that's why discussions like this are good)
     
    #10
  11. DeadliestIdiot

    DeadliestIdiot Commander

    Joined:
    Aug 14, 2017
    Messages:
    71
    Likes Received:
    144
    Addendum: Perhaps they could add a toggle to allow for a different control scheme for turning (my thought would be faster turning the closer the mouse gets to the edge of the screen) to ease the wear and tear on mice and wrists while piloting a heavy large ship
     
    #11
  12. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    Physics and self-consistent device stats are all you need for this. For physics, what needs fixing is the moment of inertia calculation (which right now assumes that all of the mass of a ship is spread throughout its volume); a proper calculation that actually takes into account the distance block is from the center of mass would provide massive differentiation between armored and unarmored ships (since the moment of inertia is proportional to R^2, armor should have a disproportionate affect on the moment of inertia because it's at the periphery of the ship). For device stats, RCS needs to consume a lot of power when active (and all RCS torque output needs to be scaled to block size), and armor blocks should have more mass relative to things like generators and fuel tanks.

    The combination of these two changes would be exactly the differentiation that's wanted: that large heavily-armored ships would turn much much slower than small lightly-armored ships.

    Requiring exposed thrusters would probably also be necessary, so that all ships would be subject to the square-cube law (the idea that the mass of a ship grows as the cube of its side length, while the area available for thrusters grows only as the square of its side length).
     
    #12
    Sephrajin likes this.
  13. stanley bourdon

    stanley bourdon Commander

    Joined:
    Oct 7, 2018
    Messages:
    310
    Likes Received:
    182
    I have no fundamental disagreement with this. It is actually 1 of my either-or options and perhaps I did not express it well. SV / CV either needs to be obviously distinct and separate or one continuous flow as you build bigger. But trying to have SV distinct and different when small but the same as CV when big seams a fool's errand.
     
    #13
    Sephrajin and geostar1024 like this.
  14. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    Ah, sorry, I may have misunderstood, then. Well, I'd vote for the one continuous flow, given the issues with trying to make SV/CV obviously distinct but yet not have weird balance problems and inconsistencies.
     
    #14
    vscuorzo and stanley bourdon like this.
  15. Ian Einman

    Ian Einman Captain

    Joined:
    Dec 12, 2017
    Messages:
    596
    Likes Received:
    1,077
    I'd be in favor of more of a unified system, but it is evident that Eleon would be disinterested in implementing this (not to mention the game engine is likely too far along to allow it).

    Personally, I have no problem with the division either. For example, it doesn't bother me that I can't have grow plots in an SV, and have to use a CV for that.

    But like others, I would agree that some limits are arbitrary. Since they are unlikely to actually truly unify the systems, it might be better to instead identify the limitations/annoyances of CV's and SV's that people would like to be removed. Here's my list:

    Annoying SV limitations:
    • T2 RCS. For a "fighter" craft, SV's turn way too slow.
    • Need to rebalance thrusters, in light of cargo mass. By "rebalance" I mean increase everything bigger than small thruster jet. There's many proposals out there already.
    • Please add the medical station to an SV.
    • Fix the SV detector (it is broken completely at the moment). Make it work in space, for finding asteroids.
    • I want a bigger warp tank, or ability to add multiple tanks. I'm OK with the range being limited to 15 (but would also be happy to see that limitation removed). But limiting how much I can store in a tank is super annoying, that is the wrong way to limit range.
    • I want mining drills on an SV. Definitely in space, for asteroids. But I don't see why we can't use them planetside. Having to mine with an HV is silly. At level 1 you can mine with your drone which can fly around, why not an SV? Mining drills and weapons could be in the same pool so if you make a mining SV it limits the weapons on it.
    • Please remove the limits on the mobile constructor, or have an advanced version. I used to be able to build bases, SV's, and HV's with the aid of a mobile SV/HV constructor but they removed too many recipes.
    • I hate the design of the O2 station. Please give me a design that works well on the side or back of a vehicle. A smaller version of the base/CV one would be nice. Right now if I try to stick it on the side of a vehicle it looks stupid.
    • A mobile repair station would be fantastic.
    • Bigger fuel and oxygen tanks, mirroring the T2 and T3 versions of the base/CV ones.
    • For SV's that you can walk around in, being able to install a bed or other furniture would be great.
    Annoying CV limitations:
    • Why can't I have solar panels on a CV? If there's problems with implementing that while moving, then just impose a restriction like "only works when the CV isn't moving".
    • I want to install a furnace in a CV. The thing is heavy, that is enough of a penalty.
    • Let me dock a CV to another CV, please. Hard to implement perhaps, but it would hugely improve the game for me to be able to dock smaller ships onto a larger huge carrier.
     
    #15
  16. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    5,750
    Likes Received:
    7,959
    Actually implementing unification is actually pretty simple: just create a large- and small-block version of every device (except devices that are simply too small to warrant taking up a full large block). I agree that Eleon currently seems to be rather set on their current approach, and I'd argue that's the main obstacle to this, rather than technical issues.

    All legitimate issues that need solving, though I'd note that unification would solve nearly all of them (detector excluded, but we need a proper sensor system anyway) at once.
     
    #16
    vscuorzo likes this.
  17. IronCartographer

    Joined:
    Sep 27, 2017
    Messages:
    941
    Likes Received:
    1,279
    Not quite that simple. Warp drives would need to have their capabilities more thoroughly defined, such that they used actual ship properties to limit jump mechanics. Currently you have the absurdity of a monster SV being able to jump with a smaller drive than a small CV's.

    Turret and weapon count would need to be limited by appropriate diminishing returns to create tradeoffs fluidly.

    Docking would need an actual, universal system, with appropriate restrictions to maintain gameplay balance. This would likely be the hardest part.

    Am I missing any other systems that behave significantly differently?

    All I can think of is how HVs care about center of mass, while CV/SV pretend mass is evenly distributed (is that still true?) but that's trivial.
     
    #17
    geostar1024 likes this.
  18. Ian Einman

    Ian Einman Captain

    Joined:
    Dec 12, 2017
    Messages:
    596
    Likes Received:
    1,077
    Doing it that way would work, but would also mean mean you'd have to specifically choose the large block vs. small block version ahead of time. What would be better is if you just built a "large constructor" and could attach it directly to either a small block or large block object, and it would do the right thing in either case. But then for some blocks like lights, switches, windows, etc. you might need to introduce large block versions.

    I probably misstated things when I said the engine would have difficulty with it - it probably wouldn't. But I think it is not that simple - @IronCartographer lists some of the issues, I'm sure there are more.

    I agree with your proposal, but there's a lot of evidence that Eleon's vision for the game is to have distinct vehicle classes, rather than balancing a more "universal" system where CV/SV/HV/BA is just determined by what devices you choose to use. I do not believe they will ever change their mind, which is why I just thought it was more useful to enumerate specific things I'd like to see changed without abandoning the current system. I think it is easier to get them to add a T2 RCS, than it is to completely abandon the CV/SV distinction.
     
    #18
    DeadliestIdiot likes this.
  19. Ian Einman

    Ian Einman Captain

    Joined:
    Dec 12, 2017
    Messages:
    596
    Likes Received:
    1,077
    I think that the short range warp drive should be able to jump anywhere within a system, and a long range warp drive should be required to go to different systems. Then just get rid of the 15 AU limitation.

    That, of course, depends on them implementing the concept of different systems, which has been talked about since forever, but there is still no movement on. One would hope a big release number like "Alpha 10" might include that concept but I've heard no noise about it, so I suspect it is not coming soon. (I would be very happy to be proven completely wrong.)
     
    #19
  20. ravien_ff

    ravien_ff Rear Admiral

    Joined:
    Oct 22, 2017
    Messages:
    3,588
    Likes Received:
    7,460
    So basically turn everything into a small grid, but add all the existing large-sized blocks and devices so they take up the same physical size and have the same stats as before? So a 1x1x1 sized large block would now effectively become a 4x4x4 sized small block, but it has the same stats and takes up the same physical space as the old large version?

    Hmm... Something to think about here. Of course such a major change might break all workshop content unless it can be converted over automatically.


    Even if we don't do this, I'd like to see gravity gens and a longer range T2 warp drive for SVs.
     
    #20

Share This Page