Suggestion: An overly verbose examination of "wobbly rockets" and joint simulations

[Kavaeric]

Folks on the Discord said I should type up my thoughts on wobbly joints, so here they are. As a disclaimer I'm merely a design student and not a game developer. I'm especially not a programmer so some of my assumptions about performance may be wildly wrong. I have at least been playing Kerbal Space Program on and off since at least v0.11 or so, so I'd like to say I have a fair amount of experience and remember much of the time before autostrut and mods like KJR.

Getting everyone on the same page

Before I dive in I want to make sure everyone reading this (dev or player or otherwise) understands the distinction between "wobbly rockets" and "destructible joints", because I think it's a major reason why, when I read conversations on Discord or elsewhere, the debate on wobbly rockets goes around in circles endlessly. For the purposes of this:

• "Wobbly rockets" refers to how part joints are simulated as springs, i.e. the nature of how joints have a lot of give and elasticity, giving rise to non-structurally sound rockets that bend like a wet noodle.
• "Wobbly rockets" does not cover the actual strength of joints or the fact that they are breakable. You can have a game with structural failure at part joints without the elastic spring simulation.

Or, to summarise ahead, my suggestion is for KSP2 to move away from having flexible joint simulation while still retaining the characteristics and spirit of having wobbly rockets.

I'll also take the time to point out that the devs have acknowledged and have committed to improving the joint system such that certain joints are much stiffer, namely how parts inline parts stacked serially should have "little to no flexing", among other things:

Quote

Our team shares the community view that overly-wobbly rockets are a major issue in KSP2 (it is number 10 on our top-ten issues list). We have introduced a number of mitigations to address aspects of that issue (altering inertia tensor values to decrease joint issues that emerge when high-mass and low-mass parts are connected, introducing various bespoke multi-joint augmentations to areas of known over-flexibility), but we still see this as an area where major improvement is needed.

For whatever reason, a large number of people I've seen discussing this topic believe that the devs aren't interested in changing the joint system as it stands now in EA KSP2/KSP1, and operating off of this misconception. I don't think it's productive and I'm not really interested in discussing this with folks who need to put words in people's mouths to get their point across. I'll also point out any criticisms I have that are shared by the KSP2 dev team.

The case against wobbly rockets

I'll try my best to avoid stating the obvious while acknowledging issues that others have pointed out in the past. Nonetheless, I've tried to best condense my own reasons why I think wobbly rockets (as in, flexible, elastic joints, not breakable joints; see above if you need a reminder) are detrimental to KSP's gameplay visions as they stand now (again, acknowledging that the final iteration in KSP2 is not going to be how it is right now), based on my experiences of KSP1:

• Flexible joints are frustrating particularly for new or inexperienced players, as it is an unintuitive and difficult-to-mitigate barrier to launching early rockets. In my time helping new players on various servers and communities, one of the biggest sources of difficulty for getting into orbit for the first time is wobbly rockets, and not in the ways more experienced players playing modded or tweaked versions of the game might expect. I've seen it happen many times where a new player in a Discord call has designed a rocket that seems perfectly capable of flying straight and stable, but the small deflections caused by springy joints can lead to a cascading instability. The most common example in my experience helping new players is when micro-oscillations suddenly compound into an unrecoverable situation:
  
  
  
  It's a big source of frustration because it's almost impossible to really account for until it's too late: the fluctuations are so small that new players can easily miss them, and once they become obvious it's often too late. Newer players early in Science or Career mode often also have only a limited selection of parts to help control and stabilise. Additionally, inputs via keyboard or even through overcompensating SAS can make the oscillations worse. It becomes a unintuitive source of failure and frustration for new players.
   
• Simulated joints runs counter to a game about presenting design and engineering concepts in an accessible ways. One of the odd things about structural stability is how much on "vibes" it goes off of in KSP1: the game will calculate things like TWR in or out of atmosphere or how much dV each stage your rocket has depending on payload and fuel/engine properties, and countless details about mass, fuel consumption, and even impact strength are exposed in the VAB. My assumption was that this was meant to ensure that any failures the players experienced were due to mistakes on their fault and not because the game obscured information it had. Hence, it's always been strange how it was difficult to answer questions like "how heavy can my radial boosters be before these radial decouplers give out and I need to consider adding reinforcing struts?"
  
  I realise it's probably not possible now given how joint stresses are simulated on the fly and not an inherit property of each part—nonetheless, maximum loading capacity for critical attachment points like radial decouplers not being listed feels like a very strange departure from what a player is led to expect from in-game parts documentation.
   
• Spring joint simulations are very taxing on hardware and is difficult to program. This one I admit is more guesswork based on limited experience of how games are programmed, but from my understanding simulating a lot of joints as flexible soft-body springs is very expensive, at least as described by the devs themselves. From what I know it also often lends itself to cascading problems: some users have reported how the small gap created in between two parts that are bent from each other causes increased drag, compounding situations like the one mentioned previously. I can also imagine it leads to a lot of headaches regarding collision boxes and krakens.

To reiterate, I understand that KSP2 devs share many of these concerns and that they are aiming to change this joint model for KSP2; this is merely my attempt at zeroing on the specific problems of the current model.

The case...for wobbly rockets?

I think it's also worth pointing out to ourselves that there are certain gameplay opportunities to wobbly rockets that we need to keep in mind, even if they are compromised in the current state of KSP1/2. I want to take a nuanced approach to these though and try to drill down what these benefits are, though, since it will inform how a new solution can be designed for KSP2.

• Wobbly rockets provide feedback to the player as to the viability of their craft design. In addition to watching many new players fumble with the micro-oscillation problem, I've also noticed a lot of players who discovered the importance of structural stability for large craft through the flexible joints. There have been times when I've watched a new player strap two SRBs to their core stage with a single decoupler each and watching them bow inwards due to the amount of thrust they are dealing with. Aside from them finding it funny (which we'll get to in a bit), it does also provide visible (if exaggerated) feedback to their design: you need a heftier joint or more reinforcement.
  
  This does get diminished by how the joints can feel so elastic that they seem unbreakable, because it suggests your rocket is made out of indestructible bundles of rubber bands, which may undermine attempts to suggest limitations in the structural strength of joints. Nonetheless, I believe that any new solution should at least retain (and improve) how this system is valuable in the form of feedback.
   
• It's fun and funny. This point might be more contentious, but I think in hyperfixating on this specific point from June 16th's upnate the community (and maybe even the devs) failed to find the nuance in the statement. See my above distinction between having wobbly rockets vs having destructible joints: here, I don't think that wobbly rockets and flexible joints themselves are necessarily part of KSP DNA, but rather the experience of trial, error, and comedic mishap. Having played this game for very long and seeing players of different intents and backgrounds play, I don't think I recall much in the way of people finding fun in how rockets act like slinkies, but more with watching their designs fail is spectacular or unexpected ways, with boosters spinning rapidly or what not. I think this sense of finding joy in the sandbox of failure can be preserved without necessarily having flexible joints!

Armchair game designer Kavaeric hypothesises a solution

This is the point where I go into armchair video game designer mode and try to come up with a concept that satisfies the points, which summarised are:

• The new solution should be intuitive to understand and not cause unexpected or unforeseeable vehicle failures for new players.
• The new solution should work with the game's intent of giving players as much (or as little) information as they desire when constructing their rockets.
• The new solution should be performant and scale well with many parts.
• The new solution should provide avenues for the player to discover design flaws in their designs, both for players who prefer to scrutinise their craft in the VAB/SPH and for players who like to experiment and watch what happens in flight.
• The new solution should not run counter to the game's spiritual and aesthetic/comedic tones of failure and mishap on the road to success.

Interestingly, my source of inspiration for a possible design solution is from the KSP Early Access cinematic launch trailer. Specifically, this moment where the SRBs of the first rocket come off:

Despite the trailer not depicting any of the craft bending like a funfair inflatable guy, I think the vibe of the trailer still feels very kerbal in terms of the ways the craft fail structurally, don't you think?

Animation also gives some pointers. I'm a fan of the film The Wind Rises (2013), which has a few moments where aircraft shake themselves apart from the stress. Miyazaki exaggerates the stress, bending, and motion of the aircraft, which could be a source of inspiration on how to depict structural failure of a craft in KSP2.

Additionally, my modded KSP1 game includes Ship Effects Continued, which adds to the soundscape of the game by introducing rattling and vibration sound effects when a craft is experiencing significant structural forces, such as during launch or re-entry. I think collecting all these as inspiration, I can start to visualise an updated system for joints for KSP2:

• Joints are rigid. They do not flex and they are not simulated as flexible parts.
• Each joint on a part has a value that represents the maximum stress it can take. Generally, smaller parts have lower thresholds, as do radially-attached parts.
• Attaching a part without using an attachment node (usually the top/bottom node but also the other directions if using a hub connector part) incurs a strength penalty.
• A joint breaks when the lower stress number of the two parts is exceeded.
• If a joint is close to breaking, an animation is interpolated in along with sound effects that signal to the player that something is wrong, similar to how the radial decoupler in the trailer rattles violently before detaching.
• Struts are special parts that boost joint strength to parts they are attached to, increasing the floor of breakage. The system can still allow for autostrut for advanced players who still desire it (e.g., if building vehicles that have parts stacked and clipped into each other for aesthetic purposes) while not making it necessary for players who do not play in such ways.

This new system should provide the following benefits:

• Joint stress does not result in microdeflections or deforming that can cascade into bigger problems, lessening the learning curve for new players by avoiding situations where their rocket breaks apart for no reason.
• Joint stress is now a very easily quantifiable concept as it is a single part stat that can be exposed to the more engineering-oriented player rather than something that needs to be simulated in the game.
• Players who are less technically-minded or experienced and rely more on trial and error receive clearer and better feedback in flight on weak structural joints of their rocket, and can better identify and correct them.
• Audio feedback now adds a new dimension of atmosphere and feedback for players, especially if the the player is in a situation where they don't have a clear view of their entire craft (e.g., in IVA).
• Rockets will still break up and explode if it is poorly designed or if its structural considerations were under-specced.
• The system should work both for players who prefer the core Kerbal tone of exaggerated comedic mishaps (we can still watch Fleas fly around like fireworks), while being tweakable enough for modded players to depict these kinds of failures more conservatively.
• Joint simulation has been simplified making it less expensive to simulate and overall improving performance of the game especially for extremely large craft.
• Watching a rocket shake itself apart will probably be its own special form of joy.

As a bonus, for advanced players, when compared to spring yjoints the proposed static joint system should be simple enough (at least for my amateur non-programmer brain) where new analysis tools in the VAB can be added. This will not only add depth to the game for those looking to endlessly tweak their designs, but also can expand the potential of Kerbal Space Program as a STEM educational game by providing an approximation of static linear truss analysis, a concept very common across all areas of mechanical and aerospace engineering. Below is a simple sketch of how this approximated system can be presented to the player:

It is also possible with this model to apply a simplified model of stress/strain, where increased stress does not directly break parts but slowly fills a "strain" stat. More stress fills the stat faster, and when the stat reaches a maximum threshold the joint breaks. Increased strain could then be tied to a random deflection transform to represent the deformation of the joint.

In conclusion I think shifting to this static joints system in lieu of the spring joint system currently implemented in both games will be an improvement in terms of a gameplay, aesthetic, and programming/performance overhead perspective. While again I'll give the disclaimer that I am not a game designer nor do I have any specific training, I think that at the very least peeling back the layers on why a feature feels needed or otherwise can lend itself to insight on new avenues for gameplay design solutions.

clickbait title: top 5 reasons how wobbly rockets torched my crops and poisoned my water (you will not believe #2)

Edited July 6, 2023 by Kavaeric

[Toastie]

I think this is pretty epic and amazing.

[AzuryxxVORTEX]

I do agree, this sounds quite interesting! 

1. It destroys the need for wobbly rockets to have silly ksp momentos

2. It brings KSP2 closer to the cinematic's mechanics- Which is quite frankly very cool. 

3. Adds a bit of realism and "immersion" whilst still staying in the theme of KSP

And overall, if you fly well, you won't be victim of it. So, it's a win-

Really hoping to see this go up, it's a well thought idea. 

[Starseeker]

A very solid proposal - the stress-calc visualization would definitely be helpful! One thing that'd have to be kept in mind is how the simulation would know which engines should be considered as applying force, though that could probably be pretty easily done using a selector that tells it "calculate for stage X".

[S1lenced7]

This is very close to what I had in mind, however you’ve put it into words very well and went above and beyond with the illustrations.

This is the type of system I’d choose over springy joints

[Lyneira]

Thank you for this great write-up! I'm especially interested in the proposals for presenting part stress information better in the parts catalogue, VAB and through visual and audio cues. Regarding performance, I do wonder how much can really be gained since to calculate stress on each joint, you still need to propagate forces from impacts, wheels, drag and thrust throughout the vessel.

I'll also reiterate my desire here for such a system to allow for parts to be connected in loops, allowing rectangles, triangles, toruses etc to be built much more stable (to share stresses over multiple joints) and for true multi-docking port connections between vessels. It might even be a necessity to enable players to build structurally sound vessels when going ambitious.

Edited July 6, 2023 by Lyneira

[S_Coriolis]

I think that would be fantastic, the rocket keeps heading in the direction you want, the SAS will struggle less AND you still get the explosion after a cinematic vibration after doing things you shouldn't.

We need a voting system for suggestion so that goes to the top !

[Datau03]

I like the idea and this is very well written! Maybe they could add parts which can flex a little but have a higher maximum stress before breaking, for example special radial decouplers, but they should only be optional

[Skitles]

Hi!

I think it is worth concidering the paragraph after your quote:

As a person who has dive-bombed more than one physics meeting with an exasperated "can’t we just make the joints stiffer" comment, let me assure you that in true KSP fashion, this is not a problem with a simple remedy. We’ve got very capable people on the case, and we will arrive at a good solution.

(On mobile and don’t know how to include the link…) 

It is worth considering how you calculate stress in a static linear truss system, and how it is calculated with computer software, as Nate mentioned increasing stiffness is not going to solve the problem.

The main equation used for these calculations is hookes law: (highly simplified)

For a spring it is:

Force = Stiffness * deformation

This can also be used for calculating stress in a static linear system as:

Stress = E * Strain (E is the linear stiffness of the truss, or just the stiffness factor)

(Strain is the change in deformation, and what causes the wobble)

 

The softwares work by calculating the total deformation (strain) of every part of the rocket, and from that calculate the total stress.

if we were to say that no deformation is allowed, (no wobblyness) calculating the stress would not be possible, as the deformation (strain) is defined as 0.

so when you calculate the stress the equation looks like this for a joint in a rigid system:

Stress = E * deformation 
deformation = 0 

Stress = E*0=0

Now since we are working in a 3D space, you are calculating the deformations in all directions, so it could be possible to say that deformations in X and Y is not allowed, but Z is allowed, allowing stress to be calculated.

(stress would be significantly higher in the Z direction in this case as it now needs to cover the stress in X and Y, and could be harder to calculate for the software than allowing deformations in all directions)

Hope this is understandable as I wrote it on a mobile, but the short version is that calculating the stress on a system that is fully rigid as you proposed is likely going to require a full re-write of the physics engine, and going away from the standard method today as it currently is not possible.  

[Sylvi Fisthaug]

Kav for president 

[whatsEJstandfor]

Obvs, I agree with every single thing in this post. You're a hero for laying it out so thoroughly and convincingly. The idea of being able to do a static analysis and show the user where the weak points are is simply chef's kiss.

  

3 hours ago, Skitles said:

The softwares work by calculating the total deformation (strain) of every part of the rocket, and from that calculate the total stress.

Are you sure that's how the calculation is done in KSP? That sounds backwards to my intuition; it seems like stress should be computed first, and strain then computed based on that.

Edited July 6, 2023 by whatsEJstandfor

[Skitles]

1 hour ago, whatsEJstandfor said:

Obvs, I agree with every single thing in this post. You're a hero for laying it out so thoroughly and convincingly. The idea of being able to do a static analysis and show the user where the weak points are is simply chef's kiss.

  

Are you sure that's how the calculation is done in KSP? That sounds backwards to my intuition; it seems like stress should be computed first, and strain then computed based on that.

Hi!

I am not sure that this is how KSP runs the simulations. That is up to the devs to say.

I do work with FEM simulations, and it would be a smart way to include every ”element” (evey single part of the rocket), vector loads, (engines etc) and other physics (heat, air resistance etc) into one single complex mathematical differential equation  to solve. And calculating the strain (deformations) from all applied physical affects is the ”standard” solid mechanics way of doing it.

you can easily calculate stress, entire model deformations, etc from the strain. If you solve for stress you would need to back-track the solution to find strain-dependent properties. 
 

Now most of the reason FEM solves the strain and not stress is not relevant to KSP, as you say. But there is a LOT more material, knowledge and help available if you use an already developed method for this type of calculation and why i belive this is (to some degree) how they run the physics simulation. 

[Kavaeric]

Hi all, thanks for the feedback. I chatted with @whatsEJstandfor on Discord and while this is jumping ahead, some thoughts on how to integrate strut placement into the static/rigid joints model.

We also briefly mentioned other games to take precedent from: PolyBridge is the most famous contemporary example, but folks might remember playing West Point Bridge Designer or Pontifex. It was what suggested to me that much of the performance overhead of larger vehicles in KSP(2) is from the spring joint simulation, and that moving to a more static physics implementation would accomplish much the same thing while being much more performant.

Edited July 6, 2023 by Kavaeric

[Sea_Kerman]

I think that the actual geometric placement of the struts should matter, in that making triangles and trusses is good.

[Lowi_Sace]

I hope the devs see this point because it sounds like a great solution. A real rocked does also not flex. For scenarios where some flex is expected (for example whings) the part itself could have some flex and not the joint.

A simple stress/strain model would also add challenge and fun failures to the game. Could also be implemented in the game modes the game already provides (easy, medium, hard). Could be indicated with a bar similar to the heath damage in KSP1. Also some kind of simple animation (like in the trailer) would be very cool. Giving the player in advance a indication that something is not going well.  Followed by joints breaking, losing control and the rocked falling apart due to high forced

In case of boosters I always found struts very ugly. Would like if the devs would include a easy method for detaching an booster with multiple radial decouplers (like in on top and on bottom)

[Clóvis]

I don't know if thats is possible to be implemented as is, but seems like a good start for the devs to think in a less anachronistic more reasonable way to solve the wobbly problem at hand.
I hope the devs get to see this and take  at least an inspirations about what to do.

 

[dr.phees]

If the devs want to keep the wobbly rockets, there should be a toggleable, researchable node, that makes connections much stiffer. Maybe even two nodes? Stiff and Very Stiff?

Why not integrate it into the science development, research tree? All discussions are over, and everyone can finally be happy.

[AngryBaer]

I find some small amount of flexing helps give a feeling for how heavy a craft is. If you've ever looked out the window while flying in an airplane it's often surprising how much the wings bend. It makes sense because they were built for that purpose, rocket stacks perhaps not so much. So a lot of this would have to include some kind of material science for each part. I think poorly built wobbly rockets should just tear themselves apart violently much quicker instead of turning into noodles. Or perhaps stay connected just long enough to be funny before failing.

[Lyneira]

On 7/11/2023 at 6:39 PM, dr.phees said:

If the devs want to keep the wobbly rockets, there should be a toggleable, researchable node, that makes connections much stiffer. Maybe even two nodes? Stiff and Very Stiff?

Why not integrate it into the science development, research tree? All discussions are over, and everyone can finally be happy.

This is not a solution because in sandbox mode it is effectively the same as the current hack of increasing joint stiffness in the config file. The developers have already said that raising joint stiffness alone is not an acceptable solution. Further, when it comes to science and exploration mode, now an identical vessel can behave differently from game to game based on what technology you happen to have unlocked. This adds pitfalls for both players and developers alike when sharing vessels and/or bug reports. Anything is better than inconsistent vessel behaviour.

Edited July 13, 2023 by Lyneira

[Clóvis]

@dr.phees I stand for what i said before:
 

On 7/1/2023 at 3:42 PM, Clóvis said:

Wobbly rockets are not fun and should be removed. That said, if wobbliness is to become a feature it needs to be reliable and controllable, and not an wild stupid random thing that is only there for annoying reasons and to impede you to make the rockets you want. I mean, if wobble is feedback for a too long rocket, or a poorly designed aerodynamics, or you forgot to configure the stage and one of the four planned thrusters didn't ignite, or if you misaligned something something, if its used as feedback for something useful that is bad if you do with an rocket and its possible to understand and avoid it from happening because there is a physical based gameplay plan for it to be happening the way it happens I think is acceptable to have it in the game, and even could be a fun opportunity for game youtubers to generate content. But the way it works now its just frustrating and time consuming, making planning a rocket not as fun as it could be.

 

But as a complement I will add that wobble as a feature could also be used like: you messed up your ship and it should already have exploded, but, I will let it wobble a bit before i destroy it because I'm a tolerant game to player's messy stuff...

[dr.phees]

10 hours ago, Clóvis said:

But as a complement I will add that wobble as a feature could also be used like: you messed up your ship and it should already have exploded, but, I will let it wobble a bit before i destroy it because I'm a tolerant game to player's messy stuff...

I like that.

[RocketRockington]

Love the suggestion.  I proposed the same thing elsewhere.  Unfortunately, I think that the KSP2 team has decided against this sort of thing - because (and no offense here) it's very obvious idea if you wanted to not use spring-system joints.  My feeling is that the KSP2 team would already have thought of this and discarded it because they wanted the lol-Kerbal Wobble effect, and we're going to be stuck with some form of it forever.  The fact that some players can't wrap their head around change too and argue for wobble just reinforces to them that 'hey, maybe it's a controversial idea, so why put the effort into changing'.  Unfortunate. I think there'd be more gameplay to tuning a well designed Polybridge/bridge builder based strength system than the current system where all the joints are essentially the same strength and the only option the player has is to slap more struts onto the craft. 

[Clóvis]

@RocketRockington

Your guess is as good as mine, but I'm not sure if this is necessarily the case.
Making a game is a complex endeavor and the team might have to prioritize other systems instead of wobble. I say this because of the released info we have of the development.
The develop team have a more advanced build in wich there are already advanced systems like colonization and probably science, interstellar stuff and things we don't know about.

Second, the wobble might be a complex programming problem they are not sure is a priority to them or the community, besides an strong vocal minority.

We also don't really know how much marketing and corporate stuff have a say in this systems and if they believe wobble is considered an strong brand characteristic for the game.

If my guess is correct, they might be waiting to understand if wobble is really something they want to change to improve the game or the marketability of the game, or if there is another priority that might bring a more successful. Also, wobble, although very annoying for a share of the community, isn't really game breaking. The recently patched SoI trajectory bug was way worse than wobble.

I think the develop team are really exploring a way to solve this matter, but I'm sure there are more pressing things to be looked at. So, don't loose hope yet.

 

Edited July 15, 2023 by Clóvis

[DoCDoC]

A bit wobbly is fine, I understand that the dev's strongly believe that it is in the DNA and for a small part I agree , but maybe it should be adjustable by the users in settings. I for one think it is still a huge negative to the game and a part of the reason for many negative steam reviews.

[Vortygont]

I thought how improve situation with wobbly rockets, but save wobbles as some feature. Wobbles could happen only after crossing a certain level of detail stress where spring physics will turn on. It would look like your craft start to deformate after huge stress. So with this solution wobble begins almost only in situation when craft certainly will be damaged by heavy stress, but with wobble it will look like more gorgeous