Search the Community

I don't understand why anyone in the community is mad at Nate. Did he make some bad decisions? Sure. But the bad decisions that he made were not the ones that effectively killed KSP, 2 it was the idiocy imposed on the devs by the higher-ups., all the secrecy, not letting the KSP1 devs talk to the KSP2 devs, etc. IMO the problem is that TTI has Management that regard coders as interchangeable office-workers rather than as skilled artists - and being a skilled coder really is an art, due to the complexities involved in coding. Anyway, from what Shadowzone said in his video, I can only shake my head in wonder at the level of incompetence in the TTI Management that they can take a much loved franchise like KSP, with a generally intelligent and well-informed community that nokws what it wants, and posts about it in these forums, then go and ignore the community, and make hiring, and working conditions guaranteed to result in failure and annoy/upset the community.. If anyone should be fired, it's the management above Nate for dooming the project to fail by their idiotic decisions. It's that management that lost TTI $70 million, not the devs.

Hello! It’s been a while! I know that many of you have been wondering about the status of KSP2, so I thought I’d give you an update on how things are going. We have an incremental update on the way! The v0.2.2.0 update will address a number of common user experience issues, some of which have been causing frustration for quite a while. In many cases, a thing that was reported as a single bug (Delta-V calculations being incorrect, or trajectory lines being broken) were actually half a dozen or more closely related bugs. We identified a series of issues that we believed were negatively impacting moment-to-moment gameplay and the first-time user experience, and we dug deep into those bug clusters to make meaningful improvements. Some of those issues include: Parachutes don’t deploy reliably (doubly true when fairings are in the mix) Fairings don’t protect their contents from heating Trajectory lines in the map view sometimes disappear (often related to erroneous designation of craft as “landed” when in flight) Landed vehicles fall through terrain during time warp Maneuver nodes refuse to allow the player to plan beyond the calculated Delta-V allowance, which in many cases is an incorrect value We’ve submitted changes to address a number of these issues – in the case of the last one, we’ll just be letting you plan beyond your current dV allowance while we continue to improve our Delta-V accuracy over the longer term (there’s a very challenging set of problems to solve in the pursuit of accurate Delta-V projections for every possible vehicle that a player can make, so this is something we’ll likely be refining for quite a while). For this update, we’ve also prioritized a new kind of issue: in some cases, the first-time user experience is undermined by a failure of the UI to clearly communicate how to progress between phases of gameplay – put simply, we sometimes put new players in a position where they don’t know what they’re supposed to do next. We’ve received a huge quantity of very helpful user feedback in this area since the For Science! Update. For example, since most of us are seasoned KSP veterans, it never occurred to us that we hadn’t fully communicated that “revert to VAB” is a very different thing from “return to VAB.” We received a rash of bug reports from people who were confused about having lost progress after completing their missions and reverting to VAB. Yikes! Similarly, the lack of a clear call to action when a vehicle can be recovered frequently left new players staring at a landed vehicle and not knowing there were more steps to follow. We’ve made some UI changes to address issues like this, and we think the flow has improved as a result. Another usability issue that even catches me out on occasion -- trying to do illegal actions (for example, parachute deployment) while in time warp states other than 1x. In fact, we believe quite a few bug reports we’ve gotten about actions being broken have actually been the result of people attempting to do things under time warp that weren’t allowed. This is an area of ongoing work for us – not only do we need to do a better job of communicating to the player when they’re warping, but we also need to make clear what actions are and are not allowed under both physics and on-rails time warp. We’ve made some small UI changes to increase the player’s awareness of their time warp state, and we’re looking forward to seeing if those changes feel good to you. I know we talk a lot about the value of Early Access, but this is a great example of how your reporting helps us target our efforts. We still haven’t nailed down the exact date for this update, but we’ll notify you here once we’re on final approach. Most of our team continues to be pointed squarely at the Colonies update. We’re making a lot of progress this month on colony founding, the colony assembly experience, and colony gameplay mechanics. There are lots of interesting problems to solve here – some are super obvious (colony parts exist at a wide range of scales, and the Base Assembly Editor – the colony version of a VAB - needs to feel equally good when you’re connecting a small truss or a giant hab module). Other issues – for example, how vehicles interact with colonies on both the systems and physics levels – come with a lot of edge cases that need to be satisfied. We remain very excited about the ways colony gameplay will move KSP2 into completely new territory, and we’re definitely eager to see what our legendarily creative players do with these new systems. In parallel with our colony work, we’re continuing to find significant opportunities to improve performance and stability. We just made a change to PQS decals that got us huge memory usage improvements – mostly VRAM (this one is still being tested, so it won’t go into the v0.2.2.0 update – but I was just so excited about the improvement that I had to share): And of course, while all this work is going on, Ghassen Lahmar (aka Blackrack) continues to make big strides with clouds. Here’s a peek at some of the improvements he’s working on today (yep, that’s multiple layers)! And because the VFX team can’t ever stop making things better, they’ve begun an overhaul of exhaust plumes to bring them more in line with reality (which thankfully is also quite beautiful): Thanks as always for sticking with us as we work through each challenge – we couldn’t be more grateful to have your support as we move toward the Colonies era! Nate

I am not in the gaming industry, just normal software dev. And I don't know much about how it works in the gaming industry. But let's say I have a company A which is interested in a contract from B. I pitch the stuff and get the project. And afterwards I am like: "I have no idea how to do any of this, can I talk to the people who did this before?". That is so braindead mismanagement I am unable to comprehend this. Maybe for some weird reason this is normal in gaming but they should have clarified that before. And then I go like "Hey, we will be doing the stuff you wanted and much more, like multiplayer. We don't even want more money". And after all of that stuff hits the fan I am like "booo, they didn't help us and didn't give us more money". How on earth does that work? Is gaming industry some magical place with other rules?

Vitriol doesn't make this argument any more sound, not that it had any substance to it to begin with. We can talk about which game you like all day, but if you wanna talk objective stuff like the technical side, there's no place for opinions there. KSP2 is a broken, unplayable, badly designed mess, left incomplete and wincing painfully on the ground after being unable to gather interest, sales, or any sort of trust in whatever might come out of it long term. This is not to say that KSP1 is perfect, far from it, but hey, one is still being played by thousands, with a myriad more playing hyper modded saves, making vessels in the thousands of parts, adding planets to it, clouds, obscene levels of detail, gigabytes worth of parts, mission packs, entire mechanics, and it refuses to break under all of that except for some very specific cases.

I've been out of the loop for a little bit. Thanks for the pages, @Mister Dilsby! It is deeply satisfying to see 'Evil' Bob coming to talk to Kerbfleet. It just seems so right somehow. Happy landings!

Felipe wanted to make something other than KSP, to grow his career as a game developer rather than being stuck on one project forever. Squad wasn't interested, so he left to make what is now KitHack. I don't think he ever made much off of KSP. We know now that the KSP2 team was forbidden to talk to anyone on the KSP1 team, so yeah, your points are entirely irrelephant. And yet new planes are still designed using many of the basic engineering principles the Wrights worked out. Wind tunnel testing to confirm engineering assumptions. Independent 3-axis controls. Lift/drag ratio, and optimizing wing shape for it. Their work still matters. And Kerbals are still central to KSP2. Felipe's childhood personification of little bits of tinfoil as Kerbals remains the reason the franchise works. He knows a thing or two about the ever-elusive "fun" part of games. I'm sure the team would have reached out to him had the Take2 corpos not lost their damn minds.

At least all the KSP players will know which was the original and which was the knockoff... *** "Radio silence" is a term I hate to describe KSP2's dev team, but there's really no other way to explain what's going on. As of when I'm writing this, it is May 24th, 2024. The last time Nate Simpson logged on the forums was April 26th. The last time Nerdy_Mike posted was April 25th. The last post by KSP2's Twitter was on May 1st. That tweet said "We're still hard at work on KSP2. We'll talk more when we can." The last Discord update from a dev was on May 1st as well, promising the Discord and Forums would remain active. The last post by any developer (as far as I know) was CM Dakota who said: "Creating that human connection has always been one of the biggest goals of mine as a CM. Fans of the game only become fans of the studio by developing that sort of connection with the team. In my opinion, too many CMs act as some kind of wizard behind the curtain, when really a CM should just feel like another community member. Glad to hear I left an impression and kept you engaged with the community. Thanks for playing our game" Nothing more since then. Take-Two is claiming to not have shuttered Intercept Games, but seeing as Take-Two has some much bigger games under its belt that are also much more profitable from a "big-shot corporation" standpoint, it's not unlikely that KSP2's devs took a big hit at best. Just look at the numbers comparing some of T2's games to KSP2: Per Steam Charts for April, GTA V had an average of 95,401 players. Read Dead Redemption 2 had an average of 17,732 players. And KSP2 had a peak count of 903. I'm not really sure where I'm going with this. If Intercept Games is shuttered, there's not much chance T2's going to make a new studio, because that would be Studio #3 after Star Theory and Intercept. Not to mention that KSP2 is not even close to their more successful games. Even if Intercept Games wasn't shuttered, they had to have been hit hard by the layoffs. Hell, so of the Day 1 devs may even be gone now. KSP2 may never be what it would have. I feel like I've come off as one of the more optimistic about KSP2, but this is probably the darkest time of KSP2's development ever. It pains me, but KSP2 is probably over. This is backed up partially by speculation though, so take what I have to say with a grain of salt.

Including Iridium Next, New Horizons, Haven-1 and soon many more! (Check roadmap for what is coming) Join me on Discord! (DEV talk only) Tundra Exploration pics: Tundra Technologies pics: Planned features Roadmap Known issues "No tank type named 'RR_CryoMLOX' exists" means you have RR but not CRP, or you have RR, CRP, and WBI classic stock, and the WBI feature isn't working right. Make sure you have RR 1.16! Required Mods Kerbal Reusability Expansion (For the F9 legs and grid fins) B9 Part Switch (For part switching) Module manager (For all your module manager needs) Recommended Mods FreeIVA (So you can fly around inside Rodan and Gaira-1 parts! Modular Launch Pads (For those awesome towers) Waterfall (For those amazing plumes) Smokescreen (Realplume NOT required!) Flight Manager for Reusable Stages (For landing your F9 first stage) Omega482's Stockalike Structures NTR (For your Ghidorah landing needs) Basic DeltaV - Basic Orbit by DMagic (For better understanding of how much fuel you have to land all your crafts safely back) Tundra's Space Center (To launch from LC-40!) Near Future Solar (For the Solar Panel plugin if you want full 180 degree tracking) Not supported Mods Atmospheric autopilot FAR (Version 7.0 looks to perform a lot better) Beta versions on GitHub A very special thanks to @Beale, @CobaltWolf and @Nertea for the help and advise they gave me to make something awesome. And @DiscoSlelge for creating those awesome patches! And a massive thanks to @ValiZockt, @Rock3tman_, @Nessus_, @JadeOfMaar, @Starwaster, @neistridlar, @SofieBrink and @Infinite Monkeys for the help they gave me making this mod perfect! Changelog: Any of the configs are distributed under CC-NC-SA-4.0 License. All Textures/models/plugins are distributed under All Right Reserved License. SootyShaderLoader is based on the custom shader importer by shadowmage and modyfied by DMagic with custom modules and settings.

Those who only come on the forums to talk smack about KSP are cheating.

Just catching up after having been away for a while. Amazing video. I do think Nate deserves real blame, because of his role as creative director. When you're in charge, it's on you. But as far as his direct actions, other than wobbly rockets I'm not sure what to blame him for; the font maybe. Wobbly rockets were bad though. I've been the lead on a project to fix an unsalvagable code base inherited from people you can't talk to. While we were eventually victorious, I have to say firmly never do that, unless there's really no other way. Our excuse was that we knew that some of the worst, most bizarre bits of code represented behavior that had been negotiated with customers, but in hindsight it may have been better to risk losing those customers than the expense of continuing with that code base. It still seems to me that the deeper problem with the coding side was the lack of best practices. There were bugs in core functionality they shipped with that never should have been allowed into the daily build, let alone production. The worse your code bade, the more important this sort of thing is.

Like the majority of the community, I am sickened by what is happening. I feel like we got bamboozled, even worse now than when TT put the game on sale 3 months after selling it at a premium price. I was pretty vocal then that it smelled fishy, and that it reeked of greed that the company would sell it at $50 to those of us who wanted it right away, but then decreased the price as a "sale" to get more buyers. It sounded like they were fishing for more revenue to justify keeping the lights on, and some of us were pretty loud about that. Couple that with the complete lack of communication we had to go through. EA, at its core, is supposed to be a way for developers and consumers to interact while a product is being developed, right? They push out an incomplete game, we buy it, we give feedback, they communicate that they've received feedback and are implementing x fixes, we get the updates, we give more feedback, they talk to us, round and round we go. Right? Not here. Not with KSP2. We begged for the company to talk to us. Tell it to us straight; we aren't going to be upset if you have to delay or come back and say that things aren't going the way you wanted them to. Just talk to us. That's all we asked. And they refused. They got our money and then left us in silence. Sure, we got a dev blog about this lighting issue, or eclipses. We had, at one point, the KERB to tell us what they were working on...but then they took issues off that list before stopping it altogether. All told, we were taken for a ride. And we paid for that privilege. The company said "Hey, we've got this thing that isn't done yet, but give us cash and we'll call it EA and you'll eventually be rewarded". And like horses to water, we lined up and shelled out our hard-earned money. Which they took, and then gave very little - if anything - in return. We paid for the right to be ignored and shut out of development news. We paid to have the community fractured, friends yelling at each other, and the company laughing at us the whole way. We paid to go through this. This exercise is exactly why I didn't get into EA releases with other games that are in my library. I only 1 time before entered EA or a beta-playing phase of a game before, and that was for Harebrained Schemes' Shadowrun. Which went off without a hitch, by the way. But even with that good experience, I had read too many times where things just fell apart and didn't work. Heck, I was close to going in on Cyberpunk, and I'm glad I didn't. But KSP? I couldn't resist. My better senses were telling me to wait, but my heart over-rode them. And Take Two broke it. All told, and to finally respond to what you wrote (I took long enough to get there, didn't I?), I doubt anyone gets a refund. Doesn't matter if you went Epic or Steam, the refund "rules" are pretty clear: less than 2 hours played, less than 2 weeks after purchase. And TT will hide behind that as a way to make sure they don't have to fork the cash back over to Steam or Epic. It would be a nice gesture if they did...but it won't happen. That money is already pocketed and spent (so to speak). So what can we do? Nothing. Not a damned thing. Sure, we can post and protest. Sign one of the petitions going around right now. Take up coding and try to create your own game if you must (even I downloaded the Unreal Engine last night and am going to give it a whirl). But nothing we do is going to amount to anything. We aren't going to change their minds, we aren't going to get our money back, we aren't going to be able to save the franchise or the studio or the employees who are out of jobs. Nothing we do in the end will matter. Where does that leave us? Hopefully being cool to one another. Perhaps talking about KSP1. Maybe finding other games to enjoy. But KSP2? Gone before your time, and we barely knew ye.

That statement alone tells me he was the absolute wrong choice to lead this project. I'm all for realism with joints; some flex, breaking under intense strain, maybe a slight jarring here or a minor shift there if you are being too overzealous. But to just have a wet noodle flying through the atmosphere, and then try to sell it as both necessary and fun? He has no clue. Which a lot of us in the community have been saying since day 1. We were told continuously that they wanted our feedback, and that the bug reports were good, and that we were important to the end product. And then they clammed up and just pushed out whatever they thought was great, the community be damned. Bugs be damned. Heck, the game itself be damned, so long as the art and marketing departments were happy. I think this actually boils down to "How much of the code itself is salvageable, and how much has to be tossed and redone". And depending upon your personal preference for how much code you think it takes to make the game salvageable, it could go either way. I guess that, without knowing what the code itself looks like, and only looking at what the game is today...:shrug:? I have no words. Hard agree. Because I'm a software person myself (automation jockey mostly, but I dabble), I've actually downloaded and fired up Unreal. Followed a small tutorial, and I've got a planet rotating in space near a star! Hey, that's big news for me! Anyhow, from what I understand Unreal is far better equipped to handle some of the physics than Unity is. I just wonder how much of developers avoiding Unreal has to do with it being from Epic? That was probably the most eye-opening thing I learned from this video. I've seen my fair share of management imposing stupid rules on their teams in the name of business, but to be told you can't even talk to the former developers? Don't look at the previous code and learn from their mistakes? That alone should invoke firing of the entire board.

"You cannot NOT communicate." The long silence was in itself a way to communicate corporate's disdain for our community. The silence also made people more willing to talk to me because they wanted the story to be heard. Had PD/T2 decided to be super open and transparent and honest, we would not be at this point.

Thank you very much Shadowzone. No empty buzzwords, no hate, no half truths at all. But all the haters will feel confirmed by now. No statement after WARN, no statement after earnings call, not even a hint after you gave Nate a chance to talk over Zoom. Too bad. Yeah, I still wish it's best for it's completion. At this point I also hope there won't be any violence happening to them. That's quite possible for developers these days.

Writing as I watch so this is more a disorganized stream of consciousness: He should not have said the "you won't feel validated if you think the devs suck" and only 10 minutes later state how they were forced to hire juniors with no experience that didn't even play the first game. It's also very funny to see how it indeed was prohibited to ask the people that knew, much less consult with someone like HarvesteR. This also explains why they hit pretty much the exact same walls. It's HILARIOUS to me they might've pitched a re-engineering of the original game code with none or little knowledge of it and much less asking the people that worked on it about it. Talk about overpromising and underdelivering, something Uber was known for from previous titles. It was also really easy to guess that T2 really did see Kerbal as a golden egg goose, good to have confirmation. I still believe it was... until they absolutely ruined it by believing overpromising amateurs on their bid and then placing the dumbest restrictions upon them. Add Nate being a serial overpromiser, and them banning scott manley! It's like they took every step and precaution to set themselves up for failure. It's no wonder some of us saw them as completely arrogant when they refused or were prohibited to consult or ask anyone with a smidge of knowledge of the franchise, and then proceeded to make the same or worse mistakes. Continuing with hilarity. "This focus of visuals resulted in more fundamental design and gameplay decisions to take the back seat" AHAHAHA, as if the game looked any good. Yes, it has some modern fx and shaders, but to be a mess just to look like that? Incredible. "Nate believed the difficulty introduced by wobble would be necessary to have a fun game." Absolute clown. At least ShadowZone understands wobblyness in real rockets, even if he uses that to make a dumb case about "teaching engineering". No, enabling parts to clip into each other or otherwise exploding out of the blue does not teach engineering, it teaches cheesing. Couple that with the statement saying he was actively steering stuff away from realism specifically to dumb it down... yeah... no wonder. At this point (16 minutes) we arrive to the public reveal, yet there's no mention of any feature being complete even by the original Uber Entertainment, so either they did believe they could finish before the release, or they were already in the cycle of misleading that they had a full game when in reality they, at this point, had a bad frankenstein of KSP1. This is also known to be the point where the revolving door starts at, even after the transition from ST to IG. A revolving door filled with amateurs and juniors, hired under secrecy and now, we know also hired for minimum price. At last we also have confirmation that they were working with the original codebase ST was using, so pretty much another "I told you" to the clowns stating they magically started a new game from scratch after the merge. To further pile up on this, it seems I also was right on pointing out the "multiplayer build" we got screenshots from was indeed the original one, and not some magical new build they started after the merge. By minute 28 we get a second confirmation of this... They really didn't, at any point have a single one of the features developed. It's also a good warning story that, with multiplayer engineers being fired so early on... the long term product was dead long before these current days. My key takeaways, in comparison/opposition to SZ: Read the forums. It was impossible to miss what the community wanted... yet somehow T2 and then IG/PD/Nate did horribly. Early Access is for customer integration and feedback. If you don't care about feedback, then don't do Early Access. It seems we'll never get that font changed now... Dumb down accessibility, not the game itself. Games are hard because systems are most times loosely explained, or in the case of KSP1 have literally no explanation. Fix onboarding and you don't need to make everything inconsequentially easy to the point your game is a mediocre mess that elicits no emotional response. You can't make a product this complex with amateurs. You can't work on someone else's code without the ability to consult them... specially if it's the mess we know from KSP1. Stop using Unity. Unless you come out with something revolutionary, the public perception is always negative when you announce your project is in Unity, specially from a fanbase that's been dealing with its limitations and misuse for 10 years. Stop listening to Nate. KSP2 is dead.

Amazing video, thank you. I always thought there was a huge imbalance between the KSP2's presentation and playability - the bit about the creative lead focusing on the art clears that up a lot. I really liked the "We need to talk about Nate" section - it was necessary given things that people have said here and on Reddit. Banning the developers from speaking to Squad still has me in disbelief. Did the the people involved in the KSP2 project provide any input on what they thought was the future of the game?

The problem for Take Two is that they are in a position whereby anything they do is doomed. There are only 4 scenarios that play out for them this morning. Scenario 1 Take Two comes out with an announcement indicating that yes, the studio is closing, but they are going to continue development under a new studio. So sorry that this had to happen, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry and we promise things will be better from here on out. The community will respond with varying levels of "you went through this with Star Theory" and "you have continuously delayed this game" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 2 Take Two comes out and completely dismisses the rumors and stories, indicating that things are just fine and there is nothing to worry about. So sorry about the misinformation, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry and we promise that this will not impact KSP2 in any capacity. The community will respond with varying levels of "we've been asking for more communication" and "you have lied to us in the past" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 3 Take Two comes out and flat admits the project is canceled. So sorry this had to happen, and right after we gave Nate the green-light to talk about an upcoming patch, but we're truly sorry to anyone who purchased the game. The community will respond with varying levels of "we told you this would happen" and "you made all these promises" and they'll raise pitchforks and burn TT's buildings to the ground. Scenario 4 Take Two says and does nothing. No explanations, no messages, no communication. The community will respond with varying levels of "why aren't you telling us what's going on" and "we just know it's canceled so rip off the band-aid" and they'll raise pitchforks and burn TT's buildings to the ground. There is nothing that Take Two can do in the immediate future - today, tomorrow, perhaps the coming weeks? - that will ease tensions and make this all right. Unfortunate for them, and unfortunate for the community.

Some more of Bruvell, this time with the various landmark buildings outside of the Downtown. One issue I have with these drawings is that they're lacking in detail though, unlike the last ones. Erie Bank Stadium, home of the Bruvell Team! Why are they called the team you ask? Well, when Bruvell applied for expansion team, they were unable to turn in a proper name before the deadline. So the NFL ended up naming them the Team. They have won no Super Bowls. The stadium is mostly inspired by Lincoln Financial Field (Philadelphia), but also takes a little bit of inspiration from Highmark Stadium (Buffalo) too. "WKYS, the sound of Bruvell! Tune into 88.7FM for Sports, Music, News, Talk, and more! Everything you need for your commute to work, or to relax too at home. WKYS, Bruvell's go to radio station since 1941!" A little bit of history and radio knowledge is involved in this one. Firstly, the way radio works in the U.S. is that every station east of the Mississippi begins with W, and every station west begins with K. Afterwords is a random assortment of digits from 2-4. In the world Bruvell's in, Erie, PA simply doesn't exist. Bruvell's taken its place. However, both share a history. 1941 is when the first radio station came to Erie, and 88.7 is between the frequencies 88.1 and 107.9, the frequencies of FM radio given to Erie. And, WKYS is an actual station in D.C., but in this world that radio station also simply doesn't exist. Bruvell Central Station, the main hub of all rail activity in Northwestern Pennsylvania! The main transport companies that operate here are Amtrak and Bruvell Regional Transport, and is a connection point between the Northeast corridor, Pittsburg, and Ohio. It's mainly inspired by 30th Street Station (Philadelphia), but also takes a bit of inspiration from Newark Penn and New York Penn. As you can see, this drawing's still a WIP.

That one really falls in with the things I was wondering, so that was great. And thank you very much for the detailed answer! I've seen so much talk about how Unity was the wrong choice, that it makes you wonder why they used it in the first place, but the change in scope after starting in a place where it had advantages, does make sense, and seems like it certainly led to problems when they ended up at place where they were making something with an engine that no longer made sense for the project, but were likely in too deep, and probably couldn't get the time/budget/manpower approval for an engine change, even if that was on their minds as something they wished they could do. By the by, what do you think of their solution for precision at the scales of distance being dealt with? There was a dev diary about the problems with necessary floating point precision being impossible at the distance scales being dealt with, without resorting to methods that increase computation cost impossibly high, so essentially they had a little bubble of higher precision simulation around the craft being controlled, in order to get the precision necessary for things like docking. Judging from the explanation, and the overall logic of the problem, it seems like this would be necessary, and your answers would lead me to think you would go in a similar direction, but curious about if you think that's one they got right, or if there was a better alternative.

I feel there was a balance they failed to hit (talking about direction as in the general sense of the finalized vision for the game). The heavy work on tutorials already tells you they were going for "we take this niche game and make it accessible to even more people, it'll definitely sell more." FS! followed on that by simplifying and linearizing the tech tree and having science be a single magic button, where you can absolutely skip even the timers so long as you hit it every time it flashes. Lastly, they also wanted to tell a semi-linear storyline through missions, discoverables and their lore. That part was really good, the new user onboarding was a magnitude better than KSP1. On the other hand, the game really required a strong technical foundation because by the time the difficulty curve of rocket launches and SSTOs is over, almost every player just goes big. Here is where to me they completely failed, by making a game that doesn't support this second bit. Of course now it'll all be woulds and coulds, but it's not hard to see that even without colonies we were already still finding the limits very easily (another example, another one, another). 8000 parts might sound like a lot on that bug report, but that's about a constellation of satellites, a couple rover missions, and a Jool 5 vessel. Meanwhile the game was supposed to allow you to do that on multiple star systems, whilst supporting trust under timewarp... and just no, the game could never be able to do that with the foundation it has. Also, as a last nail in the coffin, they forever handwaved the explanation of how Rask & Rusk (the binary system) were going to work. So yeah, we have a game built on flimsy foundations that they just outright refuse to talk about (remember the promises of HDRP and the system that'd replace PQS? I do), we have only the most basic stuff (yes, science and a tech tree is very basic, deal with it) implemented and none of the complex problems, and not just that but whatever little we have is already making those foundations quake... That's why you can google me saying "technologically bankrupt" multiple times. The balance they failed to implement in game by only including stuff for new people and nothing for veterans, was the same thing behind the scenes: they were doing only the easy stuff whilst completely neglecting the complex stuff and much less having the stones to talk about it. At this point I doubt they even had a plan past "cut everything down as manageable as possible", which is what net us all in one parts, gimped heating, the horrible coordinate reset on ground vehicles, and so on. I doubt they dropped anything in favor of a feature that probably never existed (yes, I saw the screenshot). I'm closer to believing they used multiplayer as an excuse to drop anything too complex/deep that might've further gimped the game's performance.

It's a little bit hard to be certain in retrospective. I said a few things about that already, but some expectations we've all had about where the engines are going in 2020 have came to be, and others not so much. The landscape change quite a bit, and it's hard to now talk about it without the benefit if hindsight. In a similar vein, what we know about the project has changed. Even just talking about what is believed to be the scope of the KSP2 plan in 2017, 2020, and 2023 are likely to have been quite different. So there are quite a few blanks to fill in with any number of plausible options. Lets start with a slightly different hypothetical, one that's almost plausible, albeit very unlikely given the ownership chains and realities of the game market. Say the game goes on ice. About a year from now, my boss tells me, "Hey, Kat, <our company> is in talks with T2 to rebuild KSP2 under license. Want to take this one?" In this hypothetical I have a pretty good picture of what sort of resources and budgets we'd be operating with, as well as have specific people in mind for some of the work. And unless I have to be very scrappy with this, like I get only a skeleton team and just need to make the best of it, I would scrap the code and rebuild everything in Unreal. This is despite the fact that I have access to some amazing Unity engineers in our organization. The mid-2024 reality of Unity vs Unreal is that this is a better route. In part, I'm taking into the account the disaster areas of the KSP2 and that a lot of the code would have to be scrapped anyways, but it's a little bit bigger than that. The advantages of Unreal for KSP2 are quite enormous. I'm not usually this generous towards Epic Games, but they have made several bets and investments in tech that have payed out. Crucially to KSP2, the three areas that are important are the physics engine, procedural placement, and large worlds. Chaos physics is good right now. It is better than Havok and quite a bit easier to use in your flows in Unreal than importing Havok as a middleware. That last part's just the advantage of it being already integrated, of course, and not a dig at Havok. Going with Chaos in 5.4 would eliminate a lot (not all!) of the problems with simulation stability and networking. If you were to start building KSP2 code base from scratch today in 5.4, there is zero reason not to have multiplayer enabled from the go and do all of your testing in server-client configuration. In a similar vein, basically all of the work that Intercept did for planet tiles, painted procedural biomes, and origin relocation for interstellar scaling comes out of the box with Unreal 5.4. We are talking probably the past four years of Intercept's work, about half of their team, possibly more, were building stuff that just comes packaged with 5.4. And it's better. The performance is better, the stability is better, there are more features and options... Note that this all hinges on some assumptions I'm making about the content, and that we'd be able to port over the art and tech art work that was done on planets and rocket parts over. I'm prepared to scrap the code, because in about a year of development we can be fully caught up, and have almost all of the problems fixed "for free" because they are already fixed in the engine. But I'm not prepared to scrap the art in general, and there's a lot of fiddly planet-building work that's gone in, much of which we haven't even seen yet, and throwing that away is a much more expensive proposition. So if we were just starting KSP2 clean today, no contest - Unreal, if we're trying to salvage parts of KSP2 (which is more realistic) I still want to say Unreal, but I'm making some assumptions which might change under closer examination of what's there in the dev folders. Alright, sorry about the long preamble, but that is to set up the question of what would be the correct choice for Intercept in 2020. With hindsight in mind, still Unreal - no competition. Without, there's a lot we didn't know back then. Unreal 4 was well established, and we have seen a lot of 5.0 previews to know what Epic is promising us, but there were a lot of undelivered promises in 4, so grain of salt. I started evaluating Chaos in late 2020, and it was raw then. I think in early 2020 when KSP2 dev work started, my realistic options would have been Havok or Havok. I sort of understand why "Lets use Havok in Unity," wasn't the go-to for Intercept, but I think I would have been prepared to take the risk on ECS and DOTS even if decision was made to go with Unity. PhysX just comes with way too much baggage, and Intercept has rather predictably struggled with it. The only choice besides Havok was building custom, and as fun as that would be, I don't think I'd get a sign-off on the extra budget. So Havok it would be. Now the actual choice of Unreal vs Unity would have been a little tougher back then. The team had experience with Unity and the advantages of taking parts of KSP1 that do work fine or work well enough as temps to bootstrap some parts of development are pretty clear. So it looked like a decent enough choice on the surface but. The big tipping point is what we didn't know about the scope of KSP2, but that was clearly in Nate's mind back then. I'm pretty sure that one meeting with Nate about the art/design direction of the game would have made it clear that scalable, procedural environments for the planets with modern visuals was a big part of the 2020 pitch. And with that in mind I would have pivoted hard towards Unreal. The reason is that the proc gen stuff was already in 4. In a somewhat early form, but we've seen it in shipped games by that point. Unreal 4 also supports tiling and virtual texturing out of the box, which I know are major boons to large world development. One thing I absolutely had in my bag in February 2020 is a year of working on building these features for an in-house engine and I would feel like shaking anyone who says, "We're going to build all of that in Unity." To Intercept's credit, and part of why I'm probably less critical of them than most people here, they made that part work, and it's a monumental amount of effort. Just that alone would have probably freed up2-3 engineers and a tech artist to work on other things in KSP2 for 3 years until EA release. And even Unreal 4's implementation of these things is a bit better peformance-wise. So you'd have better framerate, Havok out of the box, and all the things that would get fixed/built with the extra technical people freed up from that work. That would already put KSP2 in a much better place, and this is just from things that would have been known to me in 2020. Looking back, it's clear that going with Unreal 4 in 2020 would have led to a switch to Unreal 5 in late '21, early '22 and make things even better. There are still a lot of things that needed to be done differently in KSP2 in terms of architecture to make it stable and performant as a game overall, but the engine choice would have been a leg up. If you look at the speculation we've had around early 2020, you might even find some posts from me unsure on whether Unity or Unreal is a better option, but a lot of it was coming from our best guesses on the art/design directions back then, and a lot of that came from by-then outdated articles and previews. tl;dr, a well informed and competent TD in 2020 should have chosen to go with Unreal. Going with Unity was a big mistake, and likely caused by the narrow experience of the technical leadership at the time, who knew Unity almost exclusively. Do keep in mind that I am saying that with the advantage of hindsight, as much as I try to compensate for it. Rolling back to 2017, we're in a completely different world. Not only is the tech different, with a lot of the features that would make Unreal a clear winner still very early in development or even entirely as unannounced plans on the roadmap, but also the scope of the game was different, as far as we know. I'm not going to spend too much time going over this. Assuming that I understand correctly that the pitch for KSP2 was, "Take KSP1, make it look shinier, add a star system, and do some cool colony-building gameplay," Unity was the right call. You'd be able to reuse much of the work that KSP1 team did, both under HarvesteR and later with new tech team at Squad. And while at the time it would have meant steaking with PhysX, we're also talking about a smaller game where a lot of KSP1 patches on top of that would have been adequate. Especially if multiplayer wasn't planned at the time. So I think Star Theory's plan for KSP2 was fine and probably would have panned out if the scope didn't expand so much. We'd probably get KSP2 in 2020, and it'd probably look like KSP1 with some visual and interstellar mods and colony gameplay. Hopefully, with some loading issues addressed, since ST would need to improve on them for interstellar. It'd be fine, and most KSP1 players would probably jump over to it. In terms of general changes I would make compared to how KSP2 seems to have been developed across both iterations, I'm just going to run through bullet points. Introduce compound rigid bodies. It'd be exposed to Chaos/Havok/PhysX as a single rigid body, but we'd be able to compute the stress on implied joints between the actual component parts of it. So if any limits are exceeded, it can still break, and if it crashes into the terrain, parts of it could be destroyed rather than all of it at once. I've mentioned advantage for colonies, but you can also use it for physics LoDs and crucially for things like a tank with a decoupler or docking port on it. The latter parts are very light compared to the tank, making the joints flimsy. Turning this into a single rigid body would make all the joints so much more stable even if we're talking about KSP2 2017 and we're doing this in PhysX. So many physics problems would just not. Don't rely on game physics for any part of orbital motion simulation. The CoM of every ship should be on its orbital element rails, with any external forces (sum total of all engines or a binary planet situation) added together and applied to the ships in this bespoke simulation. So even if you're focused on a ship, yeah, it should be simulated for any rotation, part flexing, joint stress, etc. But the net force applied to it should go to the external, bespoke orbital mechanics sim that just moves the ship's CoM. And in your local view, the ship's CoM should be reset to that position on every frame to nulify drift from any Kraken forces. Energy and momentum should be conserved, full stop. Build the data representation incrementally, testing along the way. Playtesting, QA testing, and unit tests everywhere. The KSP2 data mess looks like the team that worked on saved games, editor, and actual simulation never talked to each other. I don't know how that happened, I wasn't there, but I'd like to think I can avoid that kind of a disaster. It's just bad. There are also performance considerations that are graphics related. I'm not a graphics engineer, though. And I don't know how much of what we've seen in KSP2 is really a tech problem, and how much is just tech art not having had an optimization pass. It's very easy to make a quick and dirty shader that does the job but is awful on rendering performance, and you see a lot of that in early alphas. Given that EA is pre-alpha, I'm not sure how harsh I should even be on this. But the bottom line is if there were tech issues, I don't know if I'd know how to fix them. But I also don't really need to. The most important bit is knowing how to find people who can do these tasks. I think a lot of bad calls in that regard were budget restrictions, but it also seems like tech leadership at Intercept hasn't done an ideal job of it. So that's sort of the final part of it. And as a final note, a lot of what I wrote here is criticism, but I know where some rakes are hidden, and I don't know how many rakes Intercept avoided that they knew about that I don't. I think I could have made a much better KSP2 from the purely technical perspective whether I was given the TD on it in 2017 or 2020. Would KSP2 be a better game overall? I don't know. It'd be less broken, but would less broken KSP2 that looks like garbage and has almost unusable UI and editor be better? (Not saying as a necessary cost, but purely as a hypothetical, knowing that these are areas where my own expertise wouldn't be enough.) I don't know. So don't levy all of that against ST or Intercept. This is purely a list of ways that would have been available to make things better if somebody with the right talents was on the team, but everything's an opportunity cost.

Building with FAR 101 – Barebones Basics First off, I''d like to thank tetryds, both for advice and corrections he provided in the course of writing this tutorial, as well as the awesome BAD-T tournament he is running that led me to write this tutorial in the first place, that it might be of some use to those who want to enter but might not be familiar with FAR . With that out of the way, lets begin. Ferram Aerospace research is a mod that aims to bring real-world aerodynamics and aerodynamic principles and mechanics to KSP. As a result, building an aircraft is now a bit more complex than in the rather more forgiving stock aero model, as planes must now be built to take into account various real-world aerodynamic design considerations. This will not be a comprehensive overview, it won't tell every trick in the book on how to make a competitive performance dogfighter, but it should adequately cover the basics sufficiently to build a successful subsonic aircraft that avoids plowing into the ground seconds after launch. Lets start by building a basic airframe: This consists of a KAX D-25 radial engine, a structural fuselage, an inline cockpit, a liquid fuel tank, and a tail adapter. Now, before we add some wings, we should first know where the Center of Mass (CoM) is. This is important, as it will greatly affect wing placement and aircraft balance later on. On the sample craft, the CoM is here: Also activated are the Center of Thrust and Center of Lift indicators. Now, the CoL indicator here looks different from stock; there's no arrow. In FAR, the CoL functions similarly, but not identically, to Stock. In stock, it indicated the net direction of lift provided by lift forces from the wings and other lift surfaces, in FAR, its simply the Aerodynamic Center. It can still be used to get a rough approximation of craft balance, but for learning precisely how a craft is balanced requires the FAR editor readouts, covered later. So lets add some wings: With wings on, it's looking more like a plane, but there's still some work to do. Control surfaces need to be added, and the plane balanced – as seen the CoL is slightly ahead of the CoM; this plane will want to pitch up, potentially leading to a stall and possibly crash. For a successful, easy to fly craft, the CoL should be behind the CoM, the aircraft should want to naturally pitch slightly downwards while in flight without control surfaces. To correct the imbalance, there are a few available courses of action: The mass of the craft could be shifted forward, the wings moved farther back, or the empennage lengthened to shift the tailplanes back and offer better leverage on the craft once control surfaces are added. A quick craft re-arrangement later, and : A bit unorthodox, perhaps, but serviceable. The wings were moved back, and the structural fuselage behind the engine was moved to behind the fuel tank, which puts all the heavy things at the front of the craft. As a bonus, the main wings are now on the CoM, which will help with performance, as the main wing is the point the craft will want to pitch up or down; the closer the CoM is to this axis, the less leverage needed to affect pitch. Additionally, the main wing is also located on the fuel tank, which means as the craft files and the tank is drained of fuel, the overall CoM of the plane will more-or-less remain where it is. Knowing where the Dry and Wet CoM on the craft is good to know. If the CoM shifts too much as fuel is used up, it may result in the plane becoming unstable. To control the aircraft, control surfaces are needed. Lets add some: The craft now has a pair of ailerons, a pair of elevators, and a rudder. The ailerons are located at the main wing tips, and provide Roll authority, the elevators are on the horizontal tailplane and will control Pitch, and the rudder on the vertical one will control Yaw. keep in mind the principle of leverage; ailerons/elevons (control surfaces that control both Roll and Pitch) that are located near the fuselage will be less effective at rolling the craft then if they were placed further down the wing, likewise, the further from the CoM the elevators are the more efficient they are at pitching the craft. Elevators placed inline with the CoM won't have any effect at all (i.e. if the ailerons in the picture were set to control pitch, they would have negligible effect due to how close to the CoM they are).. By default, a newly placed control surface will be set to respond to Pitch, Roll, and Yaw commands; while leaving control surface inputs default generally speaking won't keep you from flying, it may cause the craft to do weird things, since the rudder will be trying to pitch or roll the plane, the ailerons will be trying to adjust the craft's Yaw, and so forth. To adjust the control surface's inputs, right click on it to get a context menu: Std. Ctrl is the control settings needed here. Flp/splr controls flap and spoiler settings, covered later, and curWingMass is how much the wing weighs, with Mass-Strengt... 1 is the wing/control surface structural strength, also covered later. Clicking on the Std. Ctrl button opens a new menu: A few more options than in stock, no? Pitch %, Yaw %, and Roll % are pretty explanatory, these control that respective input. The 100 means that at present this surface will fully deploy in response to an input. This number can be changed from -100 to 100. having a Pitch at less than 100 means the surface will only deploy partially in response to an input, and a negative setting will have the surface deploy upside down, useful for things like front canards and so forth. AoA% is the Angle of Attack percent. Instead of reading a P/Y/R input, it reads the crafts current AoA while in flight, and dynamically deflects the surface in response to it. This can be set from 200 to -200; useful for things like wing slats or having a plane that could automatically pull out of a dive, that sort of thing. Brake Rudder sets if the control surface can be used for affecting Yaw like an A.I.R.B.R.A.K.E.S. part – perfect if you want to make a Ho-229 /B-2 type flying wing, this lets you maneuver without vertical rudders. Ctrl Dflect is important. This determines, in degrees, how far a control surface deflects. The lower the number, the less deflection, and the slower the pitch/roll/yaw effect propagates in flight. Because FAR models aerodynamic stress failures, or in other words, too aggressive a maneuver and the wings rip off, being able to adjust the control surfaces so they don't result in a 15 G turn and Rapid Unplanned Disassembly of the craft is vital. The other, less immediately fatal thing adjusting Control Deflection will do is help prevent stalls from overaggressive maneuvering. Too much control authority for your elevators and you risk pitching the craft's AoA too far from prograde, resulting in at best higher drag, or worse, throwing the aircraft into a stall. A lifting surface stalls when its cL falls too low; in other words, when a lifting surface stalls, it drastically reduces the amount of lift it generates; too little lift, and the craft falls out of the sky. Now, what about the Flp/Splr setting? Lets take a look: Clicking the Flap setting will designate the control surface as a Flap; flaps are useful for take off and landing, when extended, flaps provide greater lift at lower speed; they also cause more drag. Flaps shouldn't be extended much or at all in normal flight. When a control surface is a flap, extending/retracting can either be done via right click menu while in flight, or via action groups. Clicking the spoiler button actives that surface as a spoiler. In KSP, spoilers are basically airbrakes; they are automatically added to the Brake action group, and when the brakes are activated, the spoiler will deploy. Be careful when placing spoilers; place a spoiler in the wrong place or upside down, and you may discover that rather than a brake it is instead acting like a flap or an elevon and affecting the craft's flight differently than intended. Now, lets talk about Mass-Strength. Mass strength adjusts both the mass and the strength of a wing. The stronger the wing, the more aerostress it can take before catastrophically failing. The slider goes from 0.05, for a wing that is basically made out of paper mache and prayers to 4.0 for a wing made out of adamantium. For a a spaceplane, a wing setting of 0.4 or so should generally be sufficient, for a subsonic stunt/sport craft doing acrobatics at low altitude, a higher wing strength is recommended, something like .6 or so for a light weight craft. Keep in mind, that a wing strength that works for turns at 100m/s might not be sufficient for puling out of a dive at 240 m/s. While there is nothing wrong with a higher wing strength, keep in mind that stronger wings are heavier; the standard Wing Connector A, with a strength of 0.05, weighs 15 kg, the same wing at 4.0 strength weighs 1237 kg! With a basic plane built (yes, it still needs things like landing gear, but those are unneeded for now), its time to see how well it will fly (theoretically). To do this, open up the FAR editor window in the SPH/VAB by clicking on the FAR icon in the toolbar. When this is done, it brings up this: This is the Flight analysis graph, which will display some information on the flight characteristics of the craft in various flight regimes. Currently here it is set to AoA analysis, which will show how the craft will handle at various angles of attack. It can also be set to show how the craft will perform at various mach numbers by clicking on the Switch to Mach Sweep button. The numbers at the bottom adjust the parameters to be tested. By default it is set to examine the craft from 0 to 25 degrees AoA, at an airspeed of mach 0.2 The side bar buttons are craft and environment settings. Want to know how the craft will fly on Laythe? Select it from the celestial bodies menu. You can also see how the craft will fly when flaps and/or spoilers on the craft are deployed. Lets see how the example craft will fare: The mach value has been adjusted to 0.35, (around 120m/s), and the upper AoA limit has been increased to 50 degrees. The graph displays a number of lines: The green line what the craft's lift/drag ratio is as the craft sweeps from 0-50degrees AoA. Looks like the craft will get the best lift for the lowest drag at around 5 degrees AoA. The Blue line is coefficient of Lift – how much raw lift does the craft generate. The blue line goes steadily up until about 35 degrees AoA, and then starts falling. As the line goes up, the more lift the craft is generating. The tip of the cL curve at 35 degrees is important, this is the point the craft will begin to stall. The red line is drag. As AoA increases, more wing surface area is exposed to oncoming air, generating more drag. Here, the line increases until about 40 deg. Of note is the area around the intersection of the red and blue lines. At 35 degrees, L/D increases slope slightly, and at 40 degrees it begins to plateau, combine that with the the correlating decrease in cL and it shows the aircraft stalling at 35 degrees and coming to a full stall at 40, pitching the aircraft that far up should be avoided. With stalls, main wings are the easiest to stall out, other lifting surfaces like tailplanes are a bit harder. The final line, the yellow line, is a measure of craft stability. The lower the line, the more the craft will want to return to a neutral state. Here it steadily goes down, looks like the craft will automatically recover from an AoA induced stall of the wings and bring the nose back down to a prograde vector. The value of the line factors into this; the steeper the slope of the line, the more aggressive the return to a neutral state. the more aggressive this movement, the higher the G force the airframe is subjected to, the more G's, the stronger the wings will need to be. The second page of the FAR editor window that is important is the Data/Stability Derivatives. This page can be access from the drop down menu in the upper left currently reading Static Analysis going to it, and: A bit scary and technical, isn't it? Lets walk through it. At the top there is a planet selector (again, if you want to know how the plane will do on Laythe/Duna/Eve, or for the suicidally insane, Jool). The next is altitude, in kilometers, from sea level. As atmospheric density and temperature change, so to does aero performance. The last is speed, in mach, for the same reason; higher mach results in different aerodynamic considerations and fun engineering challenges like dealing with the trans-sonic region supersonic drag, which won't be covered here. Lastly, flap/spoiler settings can be set. On to the numbers. The Calculate Stability Derivitives button has already been clicked, so the stats have data to them. The first set of numbers at the top are technical data about the craft. Of note is the wing area, which can be used to determine the craft's wing loading. The higher the wing loading, the more mass per square meter the wing is supporting, and the stronger the wings have to be, but higher wing loading also means less drag. Lower wing loading means the craft has more drag, but is also potentially more maneuverable, dependent on control surface settings. Also of note is the level flight numbers,which tell the the chosen mach speed in m/s, AoA, and the coefficient of lift for level flight at the selected planet, altitude, and speed – in this case, the craft needs to have an AoA of ~2.4 degrees when flying at ~119m/s (the input mach 0.35) for level flight at sea level. The coefficient of Lift can also be used in conjunction with the static analysis graph, go back and look, and the cL of .157 shown here will correlate with the blue line on the graph. Next up are the Longitudinal and Lateral Derivatives, each of these reference a particular type of movement about an axis. These should be green, any numbers in red indicate the craft will exhibit an unwanted behavior, and the higher the green number, the less that particular kind of negative craft behavior is a concern. In particular, lets look at Mw. This number tells how much a craft will pitch up in neutral flight. The number is -.114, which means the craft will very slowly pitch down in normal fight, which is to be expected with the CoM head of the CoL. But what if we moved it? Lets see what happened: Mw is now red, with a value of 0.08. the craft will now want to pitch up in normal flight. It wont pitch up very fast, but it is still a motion that will have to be actively corrected through trimming the elevators or applying active inputs to them every so often. As with higher numbers being good when green, higher numbers when red is bad, the higher the number, the worse the detrimental effect. When a number is red and very low, it isn't the end of the world, and can easily be corrected by the control authority the plane has. For numbers bigger than around 0.5 - 1.0, a redesign of the craft is suggested to reduce the number, or even better, make the value in question green. In many cases this will be minor tweaks to wing and control surface placement. In the case of large numbers (3.0 - 4.0 and above) major structural redesign will be necessary.

People do not like to admit culpability in a situation like this & Nate is ever the spin master. Anything taken from Nate will always be "We did an amazing Job. Things were out of our hands" or something similiar. Where I personally do not think that the responsibility lies with the individual developer. Even if it did, No one will come out and say "we did a bad job" .. "it's our fault" The game WAS pushed out in a rather poor state and could support the Parent say this outcome and was preparing for it.. but I'm just saying.. Nates literal job is to talk a good game.. and he's good at it.

Out of curiosity, especially since you clearly have, likely, the most (and most relevant) experience in game physics programming out of everyone who frequents this forum: if this were your project and you were in the position were you got to make the decisions, what game/physics engine would you use (for sake of relevance, say, both if it was started now and for if it was started in the 2017-2020 range, like ksp2 was)? Since all we can really do now is talk about what ifs, and I (and others, I think) always value your insight, it would be quite interesting/educational to read. Also, If you want to go into what your overall approach would be if you were engineering and/or game lead, too, please be my guest (it would be quite interesting, I imagine). I know, though, that you've given aspects of that already (though putting it all together would still be of value), and it would easily be mass wall of text that you may or may not feel like like writing, so do what you feel like. (for a given value of force). But, if you genuinely WANT to, please do.

I have seen Satire of this very situation on television. It is a trope I feel has been displayed enough to have been immortalized. Random individual conveys some sentiment with simple arithmetic to emphasize a general feeling of disappointment. Then a figure emerges from the back of the room. Crowd parts & a shadowy out of focus frame slowly center on the individual. Long well oiled mustaschio twirled idly between for finger and thumb... " weeeellll... seems we have a misunderstanding. Let me educate the poor farmers" proceede with circular talk to convince *farmers* some unrelated point in somehow relevant to their disappointment.