Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Crew Requirements and Equipment Meta Balance

Discussion in 'Balancing' started by Ilithi Dragon, May 5, 2017.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. Ilithi Dragon Trainee Engineer

    Good Morning/Afternoon/Evening Space Engineers!

    In this thread, I intend to address not individual block balance issues, but rather the larger, meta-level balance that affects ships, and ship and equipment design and functionality, as well as related issues that affect the cost-vs-effectiveness and viability of designs in survival mode. Though individual block or component capabilities and balance issues may come up, it is not my intent to address those issues, but merely to use them as examples or to demonstrate or describe a point.

    So, I'm sure you've all seen the underlying problem I intend to address. You spend weeks, designing and crafting a new ship design, carefully and painstakingly laying out its decks, and crew spaces, adding, ripping out, and re-adding a powerful array of weapons that fits in seemlessly with the ship's overall design and hull form, maybe even adding to the stylization of the design. You armor it, run it through merciless live-fire destructive tests, re-armor it, reinforce weak areas, and test it again. Weeks of effort go into creating a beautiful and capable ship, focused on efficiency, efficacy, and elegance, and when you are finally finished, you have a sleek and low-profile corvette or frigate, a fast and deadly destroyer, or an elegant and devastating cruiser.

    Proud of your creation, and its smooth design, you go to show it off to your friends, and they all oooh and ahhh over its elegant or aggressive lines. Then, of course, you have to test it in combat against your friends' personal creations, so you all spawn your ships in, creating an armada of beautiful and deadly warships, ready to battle it out to see which one is the superior design, or how effective each design really is.

    But we all have that one friend. He spawns in a brick. A literal, hollow brick of armor, that contains four Big Bertha uber cannons, a bunch of gyros and reactors, and four Titan engines. And then he smashes everyone, because his ship is nothing but weapons and engines, with a single control panel for the pilot to drive it.

    Even with just stock parts, you still see this problem. The ships that are just bricks of rocket launchers, backed by engines and gyros, with a cockpit block slapped on top. The problem also extends into Survival mode, where someone will build a ship that is nothing but weapons and engines, and a minimal cargo system to supply the guns and reactors, and in straight combat be much more effective than a ship that was built to be realistically viable, with crew support accessories, living and access spaces, etc. Alternatively, you can get equal combat capability for far less resource investment (the real concern in Survival mode) by building a ship that is just weapons and engines, and much smaller and less expensive than a realistically viable ship or craft.

    My solution to this problem is to make those crew support accessories into actual, useful equipment. To implement the full, idealized version would require a moderately complex system of crew efficiency buffs and penalties, but the basic system would, at least on paper, not function much differently than the current atmosphere system.

    The idea is to require crew support systems - at the most basic level, bunks and beds - in order for equipment to be able to function. Each component would have a crew requirement to be able to function, so that for that component to operate, it must be connected to a space that has a pressurized atmosphere and is connected, via pressurized compartments (ignoring doors and hatches) to crew support equipment that provide a number of crew per piece of equipment (further expansion could have a minimum requirement for basic function, and another requirement for full function). Ideally, each component would have a "local control panel" (similar to the conveyor connection) that would have to be exposed to a pressurized compartment, connected via other pressurized compartments, to crew support equipment.

    An addition to this would add a low level rate of repair to any block that is exposed to a pressurized compartment connected to crew support equipment. Not fast enough to make any significant difference in combat, but enough to make having part of your equipment exposed to a pressurized compartment worth-while for after-action repairs, and to make crew support equipment more valuable and worth making space for.

    That is the most basic implementation of the idea.

    Further expansion of this would add a data/power line block system, that would connect individual components to control panel/cockpit blocks, creating a data network within the ship. Each piece of equipment could be assigned to multiple control panels (so you could have redundant control points, in the event your bridge is destroyed, or a data line is severed in combat), but each control panel can only be connected to a limited number of equipment blocks. Each control panel could be "operated" by a single crewperson (reducing manning requirements for larger ships), and allowing players to put armor between external systems, like weapons and engines, and the people tank. Equipment blocks could also be linked to computer blocks, which could then be linked to control panels, further reducing manning requirements. Both could also potentially increase efficiency of the equipment, thus adding a notable data network and computer core support system to the internal design of the ship if the designer wants to maximize efficiency, durability, and minimize crew requirements (which would consume supplies) over the basic functionality of having each component be directly manned.

    An additional refinement could be added with a "Battlestations" or "General Quarters" command, that would allow components and consoles to be locally manned, for a short time, without a pressurized connection to crew support equipment, allowing components on a ship to continue functioning, at reduced effectiveness, and for a short time in the event that data lines and crew passageways are severed in combat, but the local control stations still have atmosphere. Optionally, the full local manning of all equipment and consoles could be based on the number of crew support available (first all consoles are manned, and then equipment is locally manned, but if there is not enough crew to do so, not all equipment will be locally manned).

    Equipment that is damaged to the point of being broken, or otherwise non-functional, would not actively draw on crew.

    This would make the flying-brick-of-weapons designs nonfunctional outside of creative mode testing (like the atmosphere system, the option should be available to turn crew requirements on and off in the game world settings), and give an added layer of design consideration for ships, particularly in Survival mode.

    This could even be leveraged into a means of making habitable planet ground bases important, in Survival - crew require food and other consumables to function and survive, and if the ship runs out of those consumables, the crew stops functioning, and so the ship stops functioning. Ships, space stations, moonbases, etc. can have equipment that produces SOME food/consumables, for substantial space and energy costs, but habitable planet bases can build farms and other equipment that produce large volumes of crew consumables with much lower space and energy requirements, allowing your habitable planet base to become a vital breadbasket to support the ships, stations, and bases in less habitable environments.

    This would be a large scale project for the Devs, even for the basic implementation, let alone the full implementation, and I'm not sure if the consumables resource requirement and production, which could create significant supply networks and potential trade economies between factions on persistent Survival servers, is within the scope that Keen is intending for the game, but even the basic implementation outlined above would make support systems for the ships MUCH more vital and important, both for combat and non-combat craft, as to have anything more functional than a drone would require substantial support systems to support the "crew," and more sophisticated drones would require more significant and complex data networks to properly manage and operate themselves. This would add an additional layer of complexity, as well as a new dynamic to Survival mode, and make "realistic" ship designs more viable than the weapons/cargo/drill/etc.-brick-with-engines designs.
  2. PLPM Junior Engineer

    Nevertheless. It does rely on A LOT of things that are not present in the game and would need a different layer of calculations and complexity.

    I was thinking along the lines of a food-generating block. A programmable block/remote control block that looks like an engineer in a flightseat, it would need to be in a pressurized environment to work along with the "food-generating block" having food in it (Kind of how like power consumption and uranium works), These "Fake" crews would have more advanced functions than the "normal" blocks (For example, auto-pilot function would be reserved to a crew-looking remote control instead of the normal one).

    And we do need to nerf gat walls and such.
  3. Ilithi Dragon Trainee Engineer

    Yeah, that is the big downside. I'm not sure what scope and scale of things of this nature that Keen is intending to put into the game, though I think that something along these lines will be important, particularly in Survival mode.

    Alternatively, to a system that paths crew support systems to equipment via pressurized compartments, you could go with just the data net that slaves equipment to computer and console blocks, and then just have each console consume a "crew" resource, that is generated by crew support systems (like bunks, etc.), which consume food and oxygen (when in the presence of oxygen - this could also be applied to consoles - they need "crew" and atmosphere to run). You could then add kitchen/supply spaces that produce food items from raw food materials.

    You'd end up with a multi-tier resource consumption system producing a similar effect, which is something that can be done with the engine as it stands now, plus an additional data network block group, similar to the cargo/conveyor block group.
    • Like Like x 1
  4. SilentShadow Apprentice Engineer

    If we get NPCs with reasonable pathfinding, a system to have them assigned to a bunk (passenger seat?) for recharging would be a good. Then some type of crew management to have them assigned to a control seat or perhaps repair duty (repair blocks within x radius of waypoint relative to grid) plus an assigned container or connector for parts.

    The advantage would be the ability to have them control turrets and target thrusters or other areas you designate.
  5. Ilithi Dragon Trainee Engineer

    If actual NPC crew were added, that would cover most of what I'm trying to accomplish here. All you'd have to do, then, is just implement a crew requirement system, possibly with data lines linked to computer and console blocks, like I suggested above, and then have crew to run the control consoles and repair everything.

    Is Keen planning on adding such a feature in, eventually?
  6. SilentShadow Apprentice Engineer

    It would be nice if NPCs were introduced. Right now I view it as a pipe dream of mine. The dream that the FPS goal in their road plan would include friendly and hostile NPCs.
  7. 31emanual Trainee Engineer

    Crewed stations could prevent brick spam, but i'm not sure if Keen wants to emulate Pulsar Lost Colony. NPCs would be great too, but if they're not added soon they may never be in the game. One solution could be to make turrets function worse without a crew, or maybe have them require sensors or more power to function crewless. Buffing oxygen could help too. Maybe have the helmet obscure your view.
  8. Greyson_XMG Apprentice Engineer

    I have long theorized about crews.

    I have made ships with fancy crew quarters, and lots of amenities for crewmen. I call them Crewships. From a purely functional standpoint these are currently USELESS.

    No reason to have a habitat. No reason to have crew quarters. No reason to have passenger berths. No reason to make the inside pretty. No reason to have an inside.

    In spite of this, it is fun to grab a furniture mod and make them anyway. I think about how an actual crewman could contribute to game-play.

    Having crewmen man the guns. Have crewmen standing watch over ships sensors and sounding the alarm if a unknown ship approaches. Performing R&D and making better ship parts. ..... flying the ship to a given location. .... making emergency repairs. Making a mess in the ships galley. .... backing up the plumbing. and so on..

    BUT from a programing standpoint it is difficult to bring them in. But some limitations to them could make them easier. Making them limited to operating in pressurized environment. Just because a NPC exists doesn't mean they can use a space suit. THUS maintaining a pressurized environment then becomes a necessity. Sheep to be looked after.

    IF KEEN goes in that direction.
  9. SilentShadow Apprentice Engineer

    If KSH ever moves to that level of interaction, then I suppose an intermediate dev step would be passenger service. An optional objective of going to a station, interacting with the station to view/accept transport request (distance, # of pax, cargo (baggage) coordinates, space, moon, or planet, and of course payment).
  10. piratep2r Trainee Engineer

    Some of this is engineering compounded by a lack of complex physics.

    What do tanks (sorta) look like in reality? A brick. Oversimplified, but true. Why do they have sloped edges, and why do they have a single large gun instead of a million rifles taped together? Because if your armor is good enough in the real world, an incoming shot may fail to penetrate and do little or no damage. Sloping helps this, and bigger (and faster) incoming rounds are harder to defend against.

    Contrast this with SE.

    Doublethick armor just has 2x as many "hitpoints," as single thickness, which has no real equivalence in the real world. So thickness is all that matters, and sloped armor is a waste in SE.

    Any weapon does the same general "kind" of damage (generally), so if a pistol does 1 pt of damage and your mega cannon does 1000, I do as much damage as your mega cannon if I shoot you 1000 times.

    I would hope KSH would address the problem by factoring sloping into damage physics calculations, and creating some sort of penetration value. This would create some benefit for a few large guns (instead of gatling walls) as well as force bricks to have sloped armor.

    The end result, though, would be an engineering one, and instead of gatling bricks your'd probably get heavy cannon wedges. Which I think would be much better, but still might not satisfy many people's desires to have "cool looking" ships.
    • Agree Agree x 2
  11. Ilithi Dragon Trainee Engineer

    Well, even in SE, sloping and big guns have advantages over not. Not as much as in the real world, but it is still there.

    Sloped armor is useful when you're trying to squeeze armor strength out of a limited weight budget. Well-designed slopes can also reduce the effectiveness of large explosive weapons, by reducing the surface area exposed to the blast radius. My friends and I have also witnessed missile-type shots deflecting off of sloped armor, though we're not sure if this is an intended design feature of the game, or due to lag/netcode issues.

    Big guns still have a substantial advantage in SE, as well, though less so the heavy-single-shot, gattling-type weapons (due to the nature of how the engine handles shell/object impacts, weapons with the gattling gun as a foundation will never penetrate more than two blocks deep, regardless of modded firepower). Hard-hitting, missile-type weapons can cause major to catastropic damage with a single shot, and weapons that fire high-DPS rapid-fire streams concentrate damage better than an array of slower-firing weapons that provide the same DPS, because that naturally spreads the delivery point of the damage across a larger area.

    Generally speaking, though, you are right in that the way the game deals and models damage needs to be improved, and a number of issues stem from that (not least of which is the limited options it leaves available to modders), but even if those problems ARE fixed, it still doesn't resolve the underlying problem of the flying-armored-brick-gun, because players will still be able to strap an absurd number of BFGs to a set of engines, slap a coat or two of armor on it, and put a pilot chair in the middle somewhere, and call it good. 99% of the craft will be dedicated to weapons and engines, and so in combat it will invariably out-perform any equal-sized ship that is built with a crew in mind, because the player won't have to worry about adding in all the extra space and weight and power draw that crew support systems require.
  12. piratep2r Trainee Engineer

    I don't really know what you are talking about. SE has two main vanilla weapons - gatling and missile launchers. There are no "big guns" in the game at all, unless you start adding mods. Given that almost anything is possible (within the realms of the damage system KSH has set up... I am aware that it is difficult or impossible to cause an explosion at the end of a bullet), bringing mods into the discussion doesn't really add much to the discussion. I mean, a small grid nuke launcher mod sort of throws all this "armored brick" discussion out the window anyway, so what is the point? If you are talking about PMWs, then maybe. You can obviously get penetration off of small and large grid torpedoes, but they open a whole host of other problems.

    I do fully agree with your comment about gun/launcher grids - "weapons that fire high DPS streams concentrate damage better"... it just seems to go against your comment that "big guns have a substantial advantage."

    Agreed; this comes down to "form follows function" in my mind, so I see as evidence that the "engineer" in "space engineer" actually *means* something.

    Finally, if your original suggestion ever was put into place, we'd have "bricks with air, showers, and bunk areas" rather than beautiful swan ships, right? And don't get me wrong, I actually kinda like the ideas you put forward, at least as a toggleable setting. I just don't think they would discourage people from building bricks in any way. The bricks would just be ever so slightly larger to accommodate the minimum requirements for pressurized auto-self repair (or whatever the bonus is). Min-maxing is not a game thing, it's a life and engineering thing. Which brings us back to tanks (IMO).
    • Agree Agree x 1
  13. Sea_Kerman Trainee Engineer

    One of the most efficient designs for a spaceship, if you don't care about centrifugal gravity or isolating crew space and reactors is...
  14. Bumber Senior Engineer

    Isn't there an issue with micro-debris (i.e., space dust) slowing you down?

    Although, it's not a particular (pun not intended) concern with SE's terribly low speed limit.
  15. piratep2r Trainee Engineer

    [/QUOTE]Isn't there an issue with micro-debris (i.e., space dust) slowing you down? Although, it's not a particular (pun not intended) concern with SE's terribly low speed limit.[/QUOTE]

    Here is a link to the fastest man-made objec launch (afaik): the new horizons interplanetary probe: https://cbsnews1.cbsistatic.com/hub...-47d7-466a-9c62-ae505a2ab453/nhspacecraft.jpg

    It's currently moving at about 16 km/s. Note the shape!

    Using gravity assist, probes can get even faster. Here is Juno, which was arguably the fastest moving man made object for period: https://img.purch.com/w/660/aHR0cDo...1MzEvb3JpZ2luYWwvanVuby1qdXBpdGVyLXBvbGUuanBn

    Juno was moving at about 74 km/s at fastest.

    (short answer: no, not enough dust to make a difference over solar system distances)
    Last edited: Aug 18, 2017
Thread Status:
This last post in this thread was made more than 31 days old.