Brainstorm This: Crew Chambers (no crew)

[Nosajimiki]

Hmmm... I feel the OP had a great idea that is getting lost in what-ifs. Personally, the more I consider crew, the more they seem exploitable.

I particularly like the idea to make each chamber define what blocks & not what crew they need to be optimal. By doing this instead of workstations or complex crew support systems you can quickly make an optimally chambered ship to test it out, then when you have a nicely balanced ship, you can without reinventing the wheel, go back in and re-organize those rooms to look good... this appeals to both PvP and RP building since you don't need to polish it on your first draft, but does not prevent polishing to maintain balance either.

If you make this the first phased goal and make it work nicely, then you can latter try to add and ballance more crew-centric perfiral systems without convoluting the development and testing process with too many new mechanics all at once like the power 2.0 rebuild

 

[Zoolimar]

I particularly like the idea to make each chamber define what blocks & not what crew they need to be optimal. By doing this instead of workstations or complex crew support systems you can quickly make an optimally chambered ship to test it out

You need workstations for fighters. As long as you want for crew chamber system to work smoothly over all sizes.

 

[Lecic]

You need workstations for fighters.

No, you really don't. You can have a minimum chamber size where workstations aren't needed.

 

[Nosajimiki]

You need workstations for fighters. As long as you want for crew chamber system to work smoothly over all sizes.

Not really as long as you don't require supplemental blocks for chambers smaller than 16 blocks (2x2x4). This would make a simple freebee like how tiny turrets give you the 1st 50-mass w/o enhancers A few examples:

Small fighter with a 3 block chamber would just be the 3 chamber blocks with no internal space.

A gunboat with a 16 block chamber could feature something more like terminal stations where you have a solid floor and ceiling connect by a rod made of chamber strings but you'd have 6 central blocks to build your decorative terminal into (i'd image chambers would not require more than a 37.5% density of decoration).

Frigates and up would just expand to bigger and bigger inner volumes that will progressively go from things like the tiny rooms you might find on a submarine all the way up to large auditorium sized rooms on bigger ships.

 

[Captain Fortius]

It's worth noting that the reactor chamber elements are not chambers at all, they are bricks that buff systems via no clear, describable dynamic.

So true. It's another case of Cameras being called Cocpits for the early years of the game's life.

Anyone wanna cuddle my teddy bear? Ouch... I should have told you it's actually a snapping turtle, I just call snapping turtles teddy bears for some reason.

As for the meat of the topic itself, it seems like a well thought-out idea to me that might just work way better than what we see in the current dev builds.
An actual reward for empty space encourages having said space way better than a need for a longer ship hull.
Heck, at this point anything that doesn't need me to build reactor parts far away from the actual reactor would get my vote.
This take on chambers is also smarter and makes way more sense. Why does Schine always go with the awkward ideas?

So many times, I found myself wanting to build a life support room, or a nice shield generator station inside my ship, or the inner workings of a colossal cannon or sensor array, only to scrap the whole idea and fill it up solid with system blocks, lest I gimp my design down to be completely unviable for combat.
Building a nice internal framework and bolting inner and outer hull plates on it is even less likely.
...I still build interior space, but nowhere near as much as what'd be realistic.

It's worth noting that I'm more okay with cutting down my overly-wasteful interior plans rather than ever using the damnable stabilizers or having the geometry of my ships be influenced by them.

Basically: MacThule's idea > No encouragement for interior space > Reactor stabilizer range & glowy umbilical cord

 

[MacThule]

It would probably be better for Schine to look at this possibility now, rather than later.

Lancake - is this solution something schema might possibly be interested in?

 

[Sachys]

Basically: MacThule's idea > No encouragement for interior space > Reactor stabilizer range & glowy umbilical cord

Somehow, this all makes much more sense to me now.

O____o

 

[Lecic]

Somehow, this all makes much more sense to me now.

O____o

Wrong video, or....?

 

[Sachys]

Wrong video, or....?

Umbilical cord: "for fun" (then face of embarrasment and shame ~ Schine). Of course what happens after in the video, is not whats happening now on the dock. O____o7

 

[Zoolimar]

No, you really don't. You can have a minimum chamber size where workstations aren't needed.

Not really as long as you don't require supplemental blocks for chambers smaller than 16 blocks (2x2x4). This would make a simple freebee like how tiny turrets give you the 1st 50-mass w/o enhancers A few examples:

I would prefer to have 1 block workstation with no additional things, space, crew or whatever, instead of adding bounding box lines for each 2x2x4 chamber.

For fighters 1 block should be enough to get the full effect. On the other hand if you want to have only bounding box lines it will take at least 3 blocks for a bounding box with 1 free space.

 

[Nosajimiki]

So I've been trying to think of ways to exploit this system (and the discussed variants of it), and so far I have not come up with anything that can't be cut off at the pass or offer reasonable balance anyway. Some of these have already been addressed individually, but I wanted to address them all

1: Fill the chamber with system blocks: Not sure if this needs to be fixed since there are disadvantages to high density ships anyway, but you could make "empty space" one of the optimal characteristics of a chamber. IE: a shield chamber might need 10% motherboard, 10% crystals, 10% shield blocks, and 30% empty space. Ofcourse, needs should never add up to 100% to allow for creative freedom, but this way you still need to leave something empty.

2: Open Gally: By not walling off your chambers, you could make one big open floor plan eliminating the need for hallways and many otherwise unneeded walls. This may not be a problem though since putting all your chambers that close together would expose you to critical system lose if it gets drilled. If this proves to be too good of an advantage though, "decompression" mechanics would help fix it.

3: Hard to Destroy: This has already been addressed in a few ways, but I think that temporarily disabling the chamber when a shot passes through it is the best solution. This makes getting shot in a chamber a valuable critical hit, even if it is not destroyed.

4: Crew Exploitable: If real crew are added, they should be there to prevent efficiency fall off on larger ships and NOT to boost stats. The main thinking here is balancing small and large ships. A fighter with a bunch of 1-4 block chambers should not need 10 crew to man those chambers. This also means that very large chambers can have multiple crew assigned to them without exposing the system to exploits where people fill their ships like slave transports to get the most bang for their buck. Also, in a fall-off mitigation model, there is a "right" number of crew per chamber which adds more nuance to the design element of your chambers and crew quarters.

5: Overlapping Chambers: building chambers inside of chambers simply needs to be not allowed. Since a chamber has to detect all the blocks inside of it anyway, you can have chambers become disabled if they detect another chamber block type inside of its area.

6: Docked Chambers: Now here is the tricky one. Currently all chambers connect to the power grid, but that is SOOOO bad because it means they all arbitrary scale in size based on power. So if you have a ship that needs a huge reactor to power its larger weapons, you then for no reason need a huge chamber to buff your tiny shields. If they Modified systems instead (which has often been suggested), then scale would make more sense, but there are tons of design pitfalls there in terms of inheriting attributes. If you inherit everything, then your docked drones become a major hindrance on the main ship, but if you selectively inherit, then you open up a lot of possible exploits.

I've thought of a lot of variants of this mechanic, and I think the best way to address this is to make chambers and reactors have an increasing return with size (similar to current power capacitors) but have all other system blocks give a diminishing returning with size. Then to pair this with selective inheritance. This means, 1 big chamber or 1 big reactor = more efficient than a bunch of little distributed ones. So, if a docked thing is a fighter, then it needs it's slightly less efficient chambers and reactors onboard which are offset by more efficient primary systems. However, if it is a turret, it would benefit more from centralized chambers and reactors, not because you are forced to do it that way, but because a single 6x6x4 chamber is better than 4 3x3x4 chambers. This would encourage players to choose to inherit their turrets and not their drones selectively putting the entire chamber system and powergrid into the main ship which seems to be the goal of Power 2.0.
[doublepost=1515522505,1515520470][/doublepost]

I would prefer to have 1 block workstation with no additional things, space, crew or whatever, instead of adding bounding box lines for each 2x2x4 chamber.

For fighters 1 block should be enough to get the full effect. On the other hand if you want to have only bounding box lines it will take at least 3 blocks for a bounding box with 1 free space.

Ah, I see where this miscommunication happened. You are thinking that the space is just what is inside of the chamber and not inclusive of it. If the chamber includes its own lines then a single chamber block is a 1x1x1 chamber. We were saying don't make ppl put things in them until they reach 16 blocks which is when you can start building the 2 x 2 x 4 chambers as described above.

I think where we may disagree (not sure) is that there needs to be some manner of linear growth from 1 block up 16 blocks up to 50,000 and beyond.

Basically we are saying that everything between a small drone and a gunship that may not need the chamber sizes of full rooms still need to abide by linear growth to account for it's bigger size. ie: a 100 mass light fighter might be able to do 1 block chambers, but a similar 800 mass bomber might need 8 block chambers to be fair. (this could just be a 2 x 2 x 2 block if you so chose since there is no internal room for decor. But then your 1.6k corvette would need something like the 2 x 2 x 4 terminal stations described above to remain optimal. Your 10k frigates might need 5 x 5 x 4 proper rooms. and your 500k battle ships could have huge multi-story chambers in the 50 x 50 x 20 range. The idea is to make it all scaleable.

Now, what may be a good idea is to give chambers a computer control block similar to other systems. This would allow for more linking options and crew pathfinding nodes which would perhaps be an important detail latter down the line. This block would need to be next to or inside of the chamber though in order to prevent exploits if it is used as a path-finding element for crew. But in this case, adding more than one per chamber would significantly complicate the way starmade does inheritance between blocks. Instead, for bigger rooms, there could just be the one "real" console and several decorative ones.

 

[Lecic]

1: Fill the chamber with system blocks:

Why not just disable system blocks within the chamber area? If people want to use them as decor they could, but there'd be no advantage to it.

And why require any decorative amounts at all? The bare requirements should just be the number of crew stations that chamber needs, and then people can decorate them however they please.

 

[Zoolimar]

I think where we may disagree (not sure) is that there needs to be some manner of linear growth from 1 block up 16 blocks up to 50,000 and beyond.

Basically we are saying that everything between a small drone and a gunship that may not need the chamber sizes of full rooms still need to abide by linear growth to account for it's bigger size. ie: a 100 mass light fighter might be able to do 1 block chambers, but a similar 800 mass bomber might need 8 block chambers to be fair. (this could just be a 2 x 2 x 2 block if you so chose since there is no internal room for decor. But then your 1.6k corvette would need something like the 2 x 2 x 4 terminal stations described above to remain optimal. Your 10k frigates might need 5 x 5 x 4 proper rooms. and your 500k battle ships could have huge multi-story chambers in the 50 x 50 x 20 range. The idea is to make it all scaleable.

Now, what may be a good idea is to give chambers a computer control block similar to other systems. This would allow for more linking options and crew pathfinding nodes which would perhaps be an important detail latter down the line. This block would need to be next to or inside of the chamber though in order to prevent exploits if it is used as a path-finding element for crew. But in this case, adding more than one per chamber would significantly complicate the way starmade does inheritance between blocks. Instead, for bigger rooms, there could just be the one "real" console and several decorative ones.

That is literally what was being discussed and outlined on previous pages.

The only difference is the basic block was the workstation and not the bounding box outline.

So fighters needed only workstations.

Light ships needed workstations and some space around them designated by a bounding box.

Medium ships - workstation, space, crew guy.

Large ships - multiple workstations, a lot of space and multiple crew members.
_________________
If the size of the needed space is >0 workstation must be within this space.

 

[Lecic]

That is literally what was being discussed and outlined on previous pages.

The only difference is the basic block was the workstation and not the bounding box outline.

So fighters needed only workstations.

Light ships needed workstations and some space around them designated by a bounding box.

Medium ships - workstation, space, crew guy.

Large ships - multiple workstations, a lot of space and multiple crew members.
_________________
If the size of the needed space is >0 workstation must be within this space.

But a workstation implies a manned (or at least optionally manned on small ships that will still have decent efficiency without it) terminal. Wouldn't it make more sense for the basic block to be the chamber frame?

 

[MacThule]

So I've been trying to think of ways to exploit this system...

This is exactly what I was looking for - some perspective - because when this idea hit me it seemed almost too perfect. Very good analysis, to my eye - I love all the points you went over in this. Docked chambers are definitely going to require a lot of finesse to pull off, but so has docking in general, so it follows.

I completely see the reasoning in #4, and I almost agree, but have reservations about heading off drone-swarms, which would almost certainly make a showing during first release of something like this before being balanced out.

I really love the idea of crew as a counter to efficiency fall-off from scale on large ships. It would also be nice to see them as at least a factor in improving system stability, offsetting outages, preventing overheats, etc - especially on larger ships (fighters will have to wait for R2D2 droids to offset their outages... )

By making crew an offset to efficiency loss rather than a buff, we would automatically give the maximum performance rate to ships beneath the threshold for crewed compartments if they had well-arranged chambers. This could be off-base and set up a major imbalance, but I'm not entirely sure that allowing small ships (particularly player-manned ones) a natural edge would be all bad.

More importantly and a bit more meta here - it would serve to incentivize building small for newer players; which would be vital to improved new-player conversion, IMO.

The learning curve is already damn steep. A crew system like this would shift the curve into full vertical. A new player attempting to build a super-complex manned vessel, where just the reactor system itself takes an hour to lay out, would yield pretty high odds of a rage-quit and perma-hate... So by making crew itself about falloff in chamber function and offsetting outages and overheats, the advantage of larger vessels becomes more durability and resilience at the cost of block economy, the edge for smaller ships becomes extreme cost-efficiency (per-component block value would be better) and much greater simplicity of optimization at the cost of being easily crippled and or destroyed.

This way, novice players can be happy getting maximum return on their components keeping things to a max size of gunship/corvette/escort, and would be able to do a lot of basic pirating, trade, exploration, mining and escort work without having to grok the entire set of interlocked dynamics at play. After some time doing that and growing adept at system integration, it would be a new challenge and puzzle to figure out how to use crews to strive for similar optimization levels from larger and larger vessels, a task probably best approached in teams.

Of course if the answer to crew effect on chambers were that it offset efficiency falloff, as suggested, then in order to prevent droneswarm spam used to exploit the simpler and more economical small ship dynamics, we would need severe, hard fleet limits, with expansion tied into the presence of at least one small capital ship with a fleet bridge compartment/chamber that gave it fleet command abilities at varying levels. That way nuggets would either have to solo it or maybe be able to command 2-4 wingmen, but for larger forces one would eventually have to explore the intricacies of building larger ships, and in order to keep those large ships from being very inefficient one would want to learn how to properly crew a vessel.

All that sounds like a great end-result, but you know that until it got all the way there the community would be losing its collective mind about OP small ships due to chamber efficiency falloff on larger vessels. Not sure if we could endure such a thing for 6-18 months (or years or whatever, right?) until it was sorted...

 

[Nosajimiki]

This is exactly what I was looking for - some perspective - because when this idea hit me it seemed almost too perfect. Very good analysis, to my eye - I love all the points you went over in this. Docked chambers are definitely going to require a lot of finesse to pull off, but so has docking in general, so it follows.

I completely see the reasoning in #4, and I almost agree, but have reservations about heading off drone-swarms, which would almost certainly make a showing during first release of something like this before being balanced out.

I really love the idea of crew as a counter to efficiency fall-off from scale on large ships. It would also be nice to see them as at least a factor in improving system stability, offsetting outages, preventing overheats, etc - especially on larger ships (fighters will have to wait for R2D2 droids to offset their outages... )

By making crew an offset to efficiency loss rather than a buff, we would automatically give the maximum performance rate to ships beneath the threshold for crewed compartments if they had well-arranged chambers. This could be off-base and set up a major imbalance, but I'm not entirely sure that allowing small ships (particularly player-manned ones) a natural edge would be all bad.

More importantly and a bit more meta here - it would serve to incentivize building small for newer players; which would be vital to improved new-player conversion, IMO.

The learning curve is already damn steep. A crew system like this would shift the curve into full vertical. A new player attempting to build a super-complex manned vessel, where just the reactor system itself takes an hour to lay out, would yield pretty high odds of a rage-quit and perma-hate... So by making crew itself about falloff in chamber function and offsetting outages and overheats, the advantage of larger vessels becomes more durability and resilience at the cost of block economy, the edge for smaller ships becomes extreme cost-efficiency (per-component block value would be better) and much greater simplicity of optimization at the cost of being easily crippled and or destroyed.

This way, novice players can be happy getting maximum return on their components keeping things to a max size of gunship/corvette/escort, and would be able to do a lot of basic pirating, trade, exploration, mining and escort work without having to grok the entire set of interlocked dynamics at play. After some time doing that and growing adept at system integration, it would be a new challenge and puzzle to figure out how to use crews to strive for similar optimization levels from larger and larger vessels, a task probably best approached in teams.

Of course if the answer to crew effect on chambers were that it offset efficiency falloff, as suggested, then in order to prevent droneswarm spam used to exploit the simpler and more economical small ship dynamics, we would need severe, hard fleet limits, with expansion tied into the presence of at least one small capital ship with a fleet bridge compartment/chamber that gave it fleet command abilities at varying levels. That way nuggets would either have to solo it or maybe be able to command 2-4 wingmen, but for larger forces one would eventually have to explore the intricacies of building larger ships, and in order to keep those large ships from being very inefficient one would want to learn how to properly crew a vessel.

All that sounds like a great end-result, but you know that until it got all the way there the community would be losing its collective mind about OP small ships due to chamber efficiency falloff on larger vessels. Not sure if we could endure such a thing for 6-18 months (or years or whatever, right?) until it was sorted...

Keep in mind that large ships are already nerfed. They turn slower, they take more damage, shields already suffer from fall-off ROI, small weapons deliver damage more efficiently than larger ones due to damage charts, and they are much harder to power. My suggestion is just to further punctuate this fall-off by default and allow a good crew system to bring them up to or better than the current fall-off curve.
[doublepost=1515538208,1515536834][/doublepost]

That is literally what was being discussed and outlined on previous pages.

The only difference is the basic block was the workstation and not the bounding box outline.

So fighters needed only workstations.

Light ships needed workstations and some space around them designated by a bounding box.

Medium ships - workstation, space, crew guy.

Large ships - multiple workstations, a lot of space and multiple crew members.
_________________
If the size of the needed space is >0 workstation must be within this space.

Non-physical bounding boxes theoretically work, but I doubt they will be as easy to visualize when laying out your ship. I don't think I would be upset if things got implemented that way, just not sure if it would feel as natural. Computer/system relationships is already an established convention so it would mean 1 less thing on the learning curve to worry about.

 

[MacThule]

Keep in mind that large ships are already nerfed. They turn slower, they take more damage, shields already suffer from fall-off ROI, small weapons deliver damage more efficiently than larger ones due to damage charts, and they are much harder to power. My suggestion is just to further punctuate this fall-off by default and allow a good crew system to bring them up to or better than the current fall-off curve.

I would hope that a dynamic like this one would permit for meaningful compensation of any current or future nerfs essentially at the cost of a more involved design & engineering process. This would make mega ships viable for committed, thoughtful players, while simultaneously allowing even further nerfs if necessary to hamstring casual trolls seeking to overpower everyone with spam-made doom bricks and and meta-exploitations.

Non-physical bounding boxes theoretically work, but I doubt they will be as easy to visualize when laying out your ship. I don't think I would be upset if things got implemented that way, just not sure if it would feel as natural. Computer/system relationships is already an established convention so it would mean 1 less thing on the learning curve to worry about.

My feelings exactly. I would be absolutely fine with a bounding box to define functional interiors, but believe that since computer/system is an intuitive, known dynamic it would ease both implementation and adoption. Also, it hinges directly on physical blocks, and something about that sounds more stable to me.

 

[GalactusX]

Many good ideas and suggestions have been exposed here ... but I think everyone is forgetting a PRIMORDIAL thing ... crew is totally non-existent and absolutely stupid ... if the NPC could talk, they would say, please, kill me, I'm more useless that a stormtrooper sniper ...

 

[MacThule]

Many good ideas and suggestions have been exposed here ... but I think everyone is forgetting a PRIMORDIAL thing ... crew is totally non-existent and absolutely stupid ... if the NPC could talk, they would say, please, kill me, I'm more useless that a stormtrooper sniper ...

That's why there are no crew in this suggestion...

 

[petlahk]

-They could exert a lot of influence on build metas if they were actually chambers. As in spaces. Rooms. Either fully enclosing empty space, or non-colloidal blocks fully enclosed by hull/armor.

-They could exert a lot more influence on build metas if they also needed to be adjacent to a certain number of block faces of the system they affect (ie thrusters, factories).

-They could exert a lot more influence on build metas if they also needed to be tied into the reactor by conduits or hallways. And maybe to each other, depending on their role.

-They could exert a massive influence on build metas if all three of the above were true and they needed to enclose, as chambers, a substantial capacity of 'empty space' in order to function optimally.

I think even just these first 4 points would go a long way to making their building more interesting.

But on to the rest about how they should be more like decorative + functional spaces rather than just masses of blocks. It's always been very confusing to me that the starmade devs haven't tried to implement the sorts of complex multiblock structures seen in minecraft. After reading your proposal I realize that this would be the perfect way to do so.

But, the system of "How does it check and determine if the inside is an inside and not just a clump?" is a bit trickier. Also "How do you determine what is necessary to the system while still making it simple?"

I'm thinking that first something like cube-rooting the number of blocks needed per reactor size would help, but still keep the block numbers slightly higher than that cube root.

Secondly, the bounding boxes should definitely be determined by the system blocks. But I think that those system blocks should still be one of the key sorta factors I guess? Obviously, you need the interior bit, and I'm getting to that, but if you don't have the minimum system blocks it still won't work.

Next, the actual bounding. You determine the bounding with the system blocks as you showed. But I'm thinking that there should be two checks. The first check would be a simple sorta LoS check between the bounding boxes. Just to make sure that along the three axis there are walls. These walls wouldn't affect the next part.

And finally, there could be two more requirements. The first might be a set of chamber specific computers or screens. These would especially be necessary in the NPC update, but they could also serve as another easier-to-hit point of failure. But the main point here is that there should be a check to make sure the bounded area doesn't exceed a maximum mass. This would ensure that you can't just fill the empty space up with other systems like weapons so that you can achieve maximum weight/size savings.

The walls determine the crew area, and the "interior mass" check makes sure you aren't sorta exploiting the mechanic.
[doublepost=1525376440,1525376246][/doublepost]

• How do you (fairly) determine damage to the chamber?

• How do you keep the decorations inside from EITHER being dead weight OR being something that you stuff in as many of X block as possible?

I think I just accidentally addressed your second point there Valiant. Months after the post was posted, and before reading through the 3 pages of comments.

Also. I think point one could be really simply addressed by damage to the required walls.