Computational Units resource proposal

Discussion in 'Suggestions' started by geostar1024, Jan 10, 2018.

  1. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    4,857
    Likes Received:
    6,647
    There have been a number of proposals aimed at lifting the hard cap on weapons counts by introducing some variant of a control points system. The thought occurred to me that we could have a more general version of this, applicable to all devices (not windows, obviously). Thus, what I propose is a computational resource (called Computational Units, or CU for short (alternate name suggestions are welcome)) that would be provided by a new type of device similar to the existing core, and would be consumed in varying amounts by device according to its computational needs.

    The base unit is the CU and is roughly equivalent to 1 PFLOPS (to have something concrete to tie all of this to). All cores start off providing 10 CU (so the starting efficiency is 2 CU/kW, and 1.25 CU/m^3). Ideally, one could just add additional cores (which would have the added benefit of making combat less focused on coring ships) to get additional CUs. I'd also envision a 2x2x2 T2 core that provided 100 CU (for 60 kW).

    CU-hungry devices would mainly include constructors (precise positioning of atoms), weapons systems (tracking and firing upon fast-moving targets), and propulsion/navigation systems (get a warp jump calculation wrong and you might fly right through a star. . .). Preliminarily, I'd propose the following:

    constructors:
    • small constructor: 4 CU
    • large constructor: 8 CU
    • advanced constructor: 20 CU
    • furnace: 10 CU
    • food processor: 4 CU

    weapons:
    • turrets:
      • sentry: 2 CU
      • HV:
        • gatling/rocket: 3 CU
        • homing rocket: 4 CU
        • laser/plasma: 5 CU
        • artillery: 10 CU
      • CV/BA:
        • gatling/cannon: 5 CU
        • flak/rocket/laser/plasma/drill: 10 CU
        • homing rocket/repair: 15 CU
        • artillery: 20 CU
    • fixed:
      • SV/HV:
        • gatling: 2 CU
        • rocket: 3 CU
        • laser/plasma/railgun: 4 CU
        • homing: 5 CU
      • CV:
        • laser/plasma: 5 CU
        • rocket: 10 CU
    thrusters:
    • SV/HV:
      • directional: 1 CU
      • medium: 2 CU
      • jet: 3-5 CU
      • warp drive: 10 CU
      • warp drive tank: 2 CU
      • hover: 1 CU
      • T2 hover: 3 CU
    • CV:
      • directional: 2 CU
      • medium: 4 CU
      • large: 7 CU
      • XL: 12 CU
      • warp drive: 50 CU
      • warp drive tank: 10 CU
    rcs:
    • SV/HV: 1 CU
    • CV T1: 5 CU
    • CV T2: 25 CU
    misc:
    • generators:
      • SV/HV generator: 1 CU
      • small generator: 2 CU
      • large generator: 5 CU
      • T2 large generator: 25 CU
    • ventilator: 1 CU
    • repair bay: 50 CU
    • automation/logistics module (speculative): 100 CU
    • shield emitter (speculative): 10 CU
    • shield charger (speculative): 5 CU
    • shield capacitor (speculative): 5 CU
    The foregoing values aren't completely balanced (since the underlying devices aren't completely balanced), but this should illustrate the general idea. Notably, one can construct a simple SV or HV armed with a single weapon without needing to expand the vehicle's computing power (ditto a simple base with a large constructor). Also, devices that are switched off don't consume CU, which gives some tactical options (for this to work optimally, I think devices/systems (particularly weapons) probably should have finite startup/shutdown times, but this is not strictly necessary). The overall goal is a flexible system that lets device count limits be lifted, but also discourages spamming of devices without proper support.
     
    #1
  2. Brimstone

    Brimstone Rear Admiral

    Joined:
    Dec 11, 2017
    Messages:
    1,294
    Likes Received:
    2,761
    Granted it's rough, but I like it. It could even work with my hardpoint block idea- the "systems" in the HP block could even add a couple points to the vehicle's total capacity, but not enough to completely offset the cost of the weapon itself. Your CU system mimics the computational load of firing solutions, mine mimics SI in a sense... now just to convince the rest ;)
     
    #2
    Tyrax Lightning and geostar1024 like this.
  3. Exacute

    Exacute Rear Admiral

    Joined:
    Feb 17, 2017
    Messages:
    1,021
    Likes Received:
    726
    Mm, I think I like the idea.. The concept of more vaguely, and logically, enforcing limits like this seems clever; Having it in the end not being a hard-limit, but rather a realistic approach to what you can support power-wise..
    I'm a little afraid that it will turn into a crazy grind for power-ressources, but if the baseline is balanced towards 'low-input' for 'what-is-considered-the-desired-limit', I think I'm totally into the idea of CUs.

    The added benefit of having larger vessels having multiple cores, seems like a good bonus aswell
     
    #3
    Tyrax Lightning and geostar1024 like this.
  4. Hummel-o-War

    Hummel-o-War Administrator
    Staff Member Community Manager

    • Developer
    Joined:
    Jun 15, 2015
    Messages:
    8,295
    Likes Received:
    12,147
    In terms of efficiency, maybe the CU/kW ratio needs to drop with additional cores placed? So it does not lead to a linear grind of increasing the size of a vessel.
     
    #4
  5. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    4,857
    Likes Received:
    6,647
    Indeed; a square-root dependence on the number of cores might be just the thing missing. Perhaps the total CU could be given by:

    CU = 10*sqrt(# of T1 cores)+100*sqrt(# of T2 cores)

    The coefficients (10 and 100 here) can then be tweaked to suit a target "largest" build.

    A couple of interesting consequences of this system:
    • BAs are the big winner, since they don't have to support propulsion systems (even momentarily); and by corollary, CVs are the biggest losers, and are greatly handicapped on planets (where they can't turn off their propulsion systems while firing weapons).
    • This would greatly limit the shenanigans that could potentially happen with shields in the future
     
    #5
  6. Exacute

    Exacute Rear Admiral

    Joined:
    Feb 17, 2017
    Messages:
    1,021
    Likes Received:
    726
    Does seem like a reasonable approach, yeah.. I'm sure the proper values will be figured with some trial'n'error down the line.
     
    #6
    Tyrax Lightning likes this.
  7. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    I would Strongly Dissuade adopting this. Defensive combat systems, Turrets are considered that, Are Not Designed to have a spin up time. Don't add a Mac Guffin to simulate someone caught with their pants down. The attackers will exploit it ruthlessly and the victims defenders will always resent the artificial limitation. Losing scenario.
    Let catching people with their pants down simulate catching people with their pants down.

    One note for CV's, this could be used to lift atmo weapon restrictions. "Fire or use your shields..... or Adama Manuver WEEEeeeeeeeeeee!"

    I LIKE this Idea. Good initial idea and fleshing out. *picks up a 3lbs hammer* Now lets get to work ;)
     
    #7
    dichebach, Tyrax Lightning and Malekh like this.
  8. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    We know the Max theoretical size of vessel/structure allowed. figure what would be reasonable at max capacity/size and scale from there?
     
    #8
    Tyrax Lightning likes this.
  9. Captain Jack II

    Captain Jack II Rear Admiral

    Joined:
    Nov 1, 2016
    Messages:
    2,508
    Likes Received:
    3,727
    I'm on board as long as the mechanic to control power to devices gets some attention too. The control panel is confusing, limited, and doesn't always work right. Even now, without CU, trying to manage power to devices is frustrating.

    When there is more CU demand than is in supply, do devices explode, go haywire, or just stop working? Can cores overload? - back to control of devices, as in MP, a member of your crew turning on a toaster at the wrong time could potentially cause an entire ship to crash.

    If added cores have decreasing efficiency, won't we basically be trading a device cap for a core cap?


    Defensive combat systems do take time to come online... it's just that those systems are always online. I Love the idea of a device power up (boot sequence) delay... not a spin up time that delays functionality once online, but bringing more complex systems from no power or standby, to a ready state, should take a few seconds at least.
     
    #9
  10. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    It wouldn't be in an unpowered state. It would just be computationally Idle. Yes if the weapon system is Unpowered it should take some small amount of time to become functional. If it is just computationally Idle the reaction time should be measured in Milliseconds.

    I Currently find the fire fire wait wait wait fire fire etcetc cycle that currently exists so Nonsensical that it feels exactly like what it is. An arbitrary balance restriction. Adding More of a wait cycle would be counter productive in my estimation.
     
    #10
    runlykhel and Tyrax Lightning like this.
  11. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    It would require a pretty extensive rework including but not limited to; A way to set groups that need to be powered/allocated processor time together, effects for not having enough for either besides just having it ALL not work (sporadic tracking, mistimed shots, non-catastrophic misfires, slower constructor processing, material waste, etc), And (this part I think would sell it to the general population) A Benefit to having More power and or CU available than you need. I think this last one will encourage people to not just max out their CU usage to their maximum capacity.
     
    #11
    Tyrax Lightning likes this.
  12. Exacute

    Exacute Rear Admiral

    Joined:
    Feb 17, 2017
    Messages:
    1,021
    Likes Received:
    726
    Good question. I think it should depend on the device. I see your concern, but on the other hand, I think of 'Artemis' (a space-ship-sim), where one of the roles are engineering, dealing with power-management.
    I think you'd want to have a member of your team assigned to doing that (ideally in a cool way, so the UI should def. get some love). it wouldn't be mandatory, but would def. help this issue out, while encouraging for multi-person-roles on a ship ;)

    As far as what happens, I think it should default to basic-navigation, when overloaded, where the 'AI-focus' would be to set the ship down safely (if on a planet), while the systems go haywire/shut off, untill it got fixed. I don't think anything should explode, or cause fatal damage to the ship (such as crashing 'kinda would'), but it should def. leave the ship at a heavy disadvantage (imo)

    Yes. We would be trading a hard-cap, with a logical cap, in a way. There is no point where the increasing cores (from geostars suggested approach anyway), where it would return NO benefit adding more: It would just get more costly, as you would gain less from doing so. Hence self-regulating, while not actually being a cap.
    I think this idea is way better, because it is not artificially limiting, and offers a reasoning meanwhile.

    Indeed. No-power to -some-power, should take a little, to make managing more complex (and fun). But standby to active should effectively be instant (imo), as it is supposed to be ready-to-go, but use a little less power, while not actively used.

    Well. Ideally it should be a constant 'fire' 'wait' cycle, where 'wait' is the 'reload-time' of the weapon. How many 'fires' before 'wait', should be the weapons capacity, although for the most time, that would be 1:1, for projectile based. Laser-based, should be more based on a 'cooldown' to not 'overheat' (imo), that you *CAN* push through, but damaging the weapon doing so.. I think that would be a nice little thing, adding now we're speaking weapons ;)
     
    #12
    Tyrax Lightning and geostar1024 like this.
  13. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    I am OK with weapons having a fire and rest cycle. This is how they work (being a Jackleg Gunsmith I Understand This). Currently it seems Excessive is all.

    OOOH! on that Note: Perhaps having an overage of processing power brings up the effectiveness of turreted weapons, tracking accuracy, Lead accuracy, reload time etc! Giving actual Credence to Quality over Quantity!
     
    #13
    Last edited: Jan 11, 2018
  14. Captain Jack II

    Captain Jack II Rear Admiral

    Joined:
    Nov 1, 2016
    Messages:
    2,508
    Likes Received:
    3,727
    The space between should... I say should because sometimes my turrets just stop firing and I don't know why, and that is indeed frustrating, but reload time, cooldown time, power up, those are all important to the tactical side of things. Vulnerabilities must exist, though they need to be player manageable.

    Back on topic:

    Not sure how having 2 or 3 cores would take the focus away from coring a structure. If a structure has 3 cores, destroying one will likely cripple it anyway. Which leads me to my next question.

    If a structure has 3 cores and all systems are operating, and 1 core goes away... what happens?
     
    #14
    Tyrax Lightning and Hicks42 like this.
  15. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    Also CU could be used to judge the efficacy of potential ECM and ECCM (Electronic Counter-Measures and Electronic Counter-Counter-Measures) Systems that May or May not exist in the future... but it would be Nice.

    It wouldn't be Destroyed when it lost one of the multiples it would just lose CU and therefore capabilities would degrade.
     
    #15
  16. Exacute

    Exacute Rear Admiral

    Joined:
    Feb 17, 2017
    Messages:
    1,021
    Likes Received:
    726
    Partially, I agree. I'm not sure having it be a direct relation is ideal.. It is def. an idea to have it cripple some infrastructure, based on this, but I *think* the best approach would be having it being an actual radius from impact-sorta deal.. Some sort of field ECM could be interesting having that effect CU in some way.. Mm, I like the idea..

    Indeed. Having several cores doesn't make cores less-valuable. It will still be viable targeting cores, if your intent is to take over the ship/structure. Ideally, loosing a core should be configurable with logic, to disable some systems, to not render the ship useless instantly, but rather just giving it a disadvantage upon loosing it.
    (like 'only activate, if CU>number' should be a logic condition, or something along those lines.. Maybe.. It's an idea anyway ;)
     
    #16
    Tyrax Lightning and Hicks42 like this.
  17. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    4,857
    Likes Received:
    6,647
    I quite like this idea! Especially with the diminishing returns model I proposed, it would reward players for installing spare CU (aside from the obvious redundancy benefits).

    I had initially envisioned the device just ceasing operation and going into an idle state. That would probably be ok for weapon systems, but it might be too drastic for propulsion systems. Maybe in the event of CU scarcity, weapon systems would have an extremely low rate of fire (and put out less damage if they're energy weapons) to reflect that target acquisition and tracking is having to be done using the weapon's built-in computer; similarly, thrusters would produce considerably less thrust, and generators would have reduced output (though that could set off a chain-reaction of CU-and-power loss if power and CU priorities weren't set properly).

    Yes, you are correct; I was conflating unpowered with being idle (but still powered), when those are properly two separate states. The situation I had been thinking about was a player choosing to turn off the power to a system to prevent it from consuming CU, but that now seems a bit silly.

    Right. We basically need a priority system for CU just like we need for power; anything with too low a priority would simply idle.

    Also, having many cores would make larger ships substantially more resilient, and possibly let players feel better about fielding them, if they know that someone can't just drill through to the (one) core to disable them. Also, POIs would undoubtedly benefit from this; multiple cores might even discourage me from just drilling them out :)
     
    #17
    Tyrax Lightning and Exacute like this.
  18. Hicks42

    Hicks42 Rear Admiral

    Joined:
    Dec 4, 2016
    Messages:
    1,320
    Likes Received:
    3,345
    I did not communicate this idea effectively, I mean the amount of CU available for the task would govern the effectiveness for spoofing missiles, screwing with their tactical sensors etc.. and mitigating their attempts to do the same to you. The only thing I think that should decrease raw computational power of a core is destruction/incapacitation of components of that core. No damper fields please.
     
    #18
    Tyrax Lightning and geostar1024 like this.
  19. geostar1024

    geostar1024 Rear Admiral

    Joined:
    Jan 24, 2016
    Messages:
    4,857
    Likes Received:
    6,647
    Awww, but that means there's so many Star Trek episodes we couldn't recreate :p.
     
    #19
    Tyrax Lightning and Hicks42 like this.
  20. Brimstone

    Brimstone Rear Admiral

    Joined:
    Dec 11, 2017
    Messages:
    1,294
    Likes Received:
    2,761
    Well, kinda- I want EMP warheads, especially by the time shields arrive. Have them kill power for anything in AOE for 5-10 seconds to simulate recovery and reboot.. but make them hella expensive so they're not being spammed about. Maybe dumbfire with timed detonation... and also always affect friendly units too.
     
    #20

Share This Page