Search the Community

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.

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.

This is an entire speculative timeline of KSP2 development based on Investigative Journalism done by ShadowZone, extracted from this video. A thank you goes out to @ShadowZone for doing thorough research on KSP2’s development, while remaining neutral and preserving integrity in the reporting of his finding. Recurring names and important concepts or events are in bold. Abbreviations are noted between brackets in (cursive) next to full names. Problematic events are denoted with !. All markings are applied by me and represent my own personal opinion. A PDF version of this summary is available at the bottom of this page, for easier reading. Pre-production, 2017 – 2018 (Star Theory) Take Two (T2) chooses Uber Entertainment, Later renamed Star Theory (ST), to develop Kerbal Space Program 2 (KSP2) T2 allocates 2 years and 10 million $ to ST to develop KSP2 This was supposedly seen as doable by the Studio Manager Jeremy Able)and ST Owners Bob Berry & Jonathan Mavor (referred to as ‘ST Management’ from hereon) ST Management’s plan at this time was to do a Revision of KSP1, meaning; take the original code, polish it up to modern standards, add new graphics and content and sell it as new version The creative direction, Nate Simpson, has a broader vision: a Reimagining rather than the Revision planned by ST management This would have included Interstellar and Colonies. Nate was a long-standing fan of KSP at this point Nate Simpson is able to convince T2 to approve his Reimagining ! Despite this, the timeline and budget already allocated by T2 would not be sufficient for the studio to pull of this Reimagining This is regarded as the start of a cascade of problems for KSP2 development At this time, the only engineer on the project is Principal Engineer Chuck Noble, an experienced software engineer with a degree in aerospace, aeronautical and astronautical engineering ! T2 keeps development of KSP2 highly secretive This forces ST team members to do recruiting and hiring in addition to their normal duties, hindering development ST team members are not allowed to tell potential hires what game or even what type of game they will be working on ! Due to budgetary constraints, only a few junior engineers with little to no experience are hired (senior engineers are brought onboard eventually, but much later on) All but one of these engineers had never played KSP1 before ! The junior engineers were considering building KSP2 on Unreal Engine instead of Unity, but were ordered by ST management to stick to the original code and engine (Unity) used by KSP1 As a result of this, some early prototype builds of KSP2 were done on KSP1’s user interface and graphics Early Production, 2018-2019 (Star Theory) Scope Change: Colonies, Interstellar and Multiplayer now considered “must-deliver features” ! Spring 2020 release date is communicated to the development team, and is considered Non-Negotiable This causes stress within development team, which possibly contributed to some wrong and hastily made decisions ! The decision to cram all these features into KSP1’s code, as ordered by ST management, ends up costing the engineers a lot of time People working on the project during this time estimate this resulted in around one year of wasted development time, compared to if they had been allowed to rewrite the code Multiplayer especially turns out to be incompatible with this framework ! Contact with Squad, the developers of KSP1, is prohibited (possibly by Squad upper management) This leads to nobody being available to guide the KSP2 engineers through the KSP1 code they were ordered to work with, forcing them to work in the dark and figure it out themselves The KSP2 engineers at ST would have loved to talk with the engineers at Squad, but they fear for their jobs being terminated by T2 should they do so ! This fear turns out to be warranted: a developer from ST is let go after answering a community question AFTER the game was announced, with T2 claiming it was an “unlawful disclosure” and that “communication to the public was not star Theory's decision, but the Publishers” Ultimately, the two previous points prove insurmountable and the engineers realize a significant Refactor of the code is needed to support Nate’s Reimagining ! This decision does not go down well with ST management, who do not understand the reasons behind it From this point onward, it is assumed new code is being written from scratch T2 continues to give ST pass after pass in Milestone meetings, despite people familiar with these meetings believing they should not have passed ! The most likely reason for this is that ST management had convinced T2 that they were sitting on a potential goldmine, claiming they were working on a ‘cultural successor to Minecraft’ These claims drive T2 to see Kerbals as their version of ‘Minions’ (A.N. The yellow creatures from the ‘despicable me’ movies), even planning a collaboration with a toy manufacturer Nate Simpson tries to appease both T2 and the existing KSP community by aiming to have the game be more accessible to a new audience and expand its player base, while also sticking to the core mechanics of KSP1 ! ST Management meekly goes along with the secrecy ordered by T2; one of the reasons for this being the aim to keep people familiar with KSP1 away from ‘interfering’ in the sequel They explicitly did not want KSP1 Veteran and well-known Youtuber Scott Manley to have any input in development Another reason for staying silent was that Uber Entertainment (now ST) had a bad reputation for previous games ! T2’s reasoning for keeping the project silent so long was apparently driven by a desire to avoid conflict with the community until it was too late At this point, due to the complete lack of outsider input, Creative Director Nate Simpson is basically the only person making gameplay decisions espite developing his first game at the age of 13, Nate is not an engineer; he instead has a bachelors degree in Arts (people working on the game describe him as a ‘very visual person’) ! This in turn caused a lot of focus to be placed on the visuals of the game, sometimes resulting in fundamental design and gameplay decisions to take the back seat Nate sometimes had a tendency to micromanage (something he admitted to in an interview) single elements of the game; one of which was wobbly rockets. Even before the Refactoring of the code, it was discovered the original KSP1 code could support significantly reduced wobble while also maintaining the option for joints to break under high stress ! Nate however was convinced that the difficulty from wobble and breaking joints was necessary for a fun game and made executive decision to keep them in the game Despite these flaws, Nate is considered by everyone spoken to by ShadowZone (SZ), be it someone who worked on the project or other content creators who interacted with him, to be a KSP Superfan with nothing but the community’s best interests at heart in his decision-making. The occasional disagreements between him and the engineers are attributed by the latter to Nate’s inexperience with aerospace, not to any form of malice. ! This inexperience, combined with Nate’s desire to expand the audience of the game to new players, somewhat resulted in the opposite happening; it reduced the capability of the game to serve as a teaching tool for people going into aerospace engineering and spaceflight, and overall reduced the priority of realism during development KSP2 is officially announced to very warm reception, with a release date set for the next year (2020) Content creators like Scott Manley, Matt Lowne and SZ are also brought onboard for the first time Hostile Takeover, 2019-2020 ST finally bring some Senior Engineers onboard. The Refactoring of the code is still only halfway done at this point in time ! By this time is has become clear that the release date of Spring 2020 is not achievable; despite this, ST Management continues to communicate to the team that this deadline and key features like colonies, interstellar and multiplayer are non-negotiable Chuck Noble, the only senior engineer who had been with the project since the start, leaves the team ST Owners Bob Berry & Jonathan Mavor begin negotiations with T2 to sell the studio to them, which are well underway by late 2019 ! Late 2019: Negotiations with Take Two break down and Star Theory loses the project ! ST’s Owners, Bob Berry and Jonathan Mavor, raised their price last-minute betting on T2 being willing to cash them out before finding another studio to work on KSP2, making them multi-millionaires in the process In response, T2 pulled the intellectual property from Star Theory and started a poaching attempt, offering everyone on the team to transition over to continue working on the project ! Partially due to the complete lack of emotional attachment to the KSP franchise on the part of most engineers(they still had not played ksp1 at this point) and partially due to T2’s refusal to budge when senior engineers tried to get better deals and compensation, the poaching attempt mostly failed, with only 4 engineers initially making the transition to the new studio that would become Intercept Games(IG) ! A total of around 20 people ended up making the transition eventually, but most of these were either junior engineers, artists or production people, resulting in a small and inexperienced team once again Star Theory continued to survive for a few more months, but ultimately failed to pitch new projects ideas (supposedly due to Covid cancelling an expo they were planning to attend) to publishers, resulting in their closure not much after. Technical Director Paul Furio is brought aboard the newly created IG with the mission of rebuilding the development team and setting processes in place to allow KSP2 to succeed Bumpy Road To Early Access, 2020-2023 (Intercept Games) ! T2 gives IG the stipulation to keep the old, broken code from Star Theory and work with it instead of starting again from scratch Apparently this was done because T2 management felt uneasy about ‘Refactoring’ the code yet again, so the decision was made to keep the existing code There is some debate as to the ‘broken-ness’ of the Star Theory Code; A person working on the project under Intercept Games said “they had 0% chance of releasing anything with that" about Star Theory code. A person working on the project under Star Theory, on the other hand, said with a little more time it would have worked. This person does however agree that it would have been better for IG to start again from scratch, not because of code quality but because of fresh team and still no contact to KSP1 devs. In general, everyone SZ spoke to agrees that not starting from scratch was the wrong move Not starting from scratch also meant Multiplayer remained one the biggest challenges to making the game feature-complete In an interview with Nate Simpson, it appeared that KSP2 already had working multiplayer when he said “as we've been testing it internally, I have never heard people laugh so hard”. Apparently, this ‘testing’ was actually done using a multiplayer mod in KSP1. It is however worth pointing out that KSP2 did have some form of rudimentary multiplayer by this time, inherited from ST, but it was incredibly buggy, unstable and nowhere near shippable. ! At this point, multiplayer remained a secondary objective while the main focus was still very much on art and visuals. This lack of baking multiplayer into the design remained a problem throughout this stage of development. They did however make progress during this period; later builds allowed multiple players to inhabit the same world and launch rockets together A few months after the game released into early access, the entire multiplayer team was let go. The developers claimed they were still designing the game with the thought that multiplayer would one day be a big part of it in the back of their minds, but it essentially was put on the backburner entirely Despite the old code hindering development and Covid hitting the globe, progress was finally being made and experts like Dr. Michael Dodd, a physics engineer, and Chris Adderly (also known as Nertea), a prominent KSP1 modder were brought onboard the project. ! It would still be until mid 2021 before KSP1 developers could finally join the KSP2 team. The ban on contact remained in place until then. Upon joining the team, apparently their reaction was “you should have asked us a year ago!” (which the KSP2 devs wanted to, but still weren’t allowed to) This ban may be explained by Squad not wanting KSP1 developers to be distracted from the final KSP1 updates This does not however explain why ex-Squad employees who had left years prior, like KSP1’s original creator Felipe Falange (known as HarvesteR), were never contacted ! Problems continue to become apparent as development goes on. Some of these are exacerbated or even caused by producers changing priorities for developers, often forcing them to switch between very different features This was later addressed withing IG when the ‘feature team structure’ (detailed here) was introduced. This structure was something Paul Furio has tried to establish before Early Access, but it was only established after his departure Take Two forces a release deadline of February 2023 by this time, the project is already over its allocated budget It immediately becomes apparent that all key features would not be ready in time for this deadline. It is believed there was a chance Colonies could have made it, but this was foregone a few months later In September 2022 the decision is made to go to Early Access with a stripped down sandbox version of the game ! This causes a massive upheaval of development, as the project was never intended to be released in parts. Product managers started pulling developers from their tasks and assigning them new ones, causing even more problems An example of this is an engineer who was weeks away from finishing a colony builder tool being pulled from the task and assigned to another item that had to be ticked off a project list, as colonies were shelved ! Yet another problem presents itself; software engineers, in high demand at the time, could make $200 to $250K a year at large companies like Microsoft or Amazon, but at IG their maximum yearly pay was kept at $150K due to budgetary constraints. Not only does this result in difficulties with recruiting, it also drives several people, such as Dr. Micheal Dodd, to leave the project The biggest blow comes from the departure of Eric De Feliz, a Graphics Specialist working on shaders. Nobody was present to pick up where he left off, resulting in the game being shipped with seriously unoptimized shaders GPU engineers especially were in high demand around this time, resulting in even worse optimization ! Despite being requisitioned multiple times, the IT team is not able to provide the necessary tools to test performance in time, further contributing to poor optimization and a late release of minimum and recommended specifications to the public Early Access, 2023-2024 (Intercept Games) Take Two and Private Division put their marketing into full gear, encouraging the ‘hype train’ even more An event is held in the Netherlands where content creators get their first chance to play the game. The first problems start to become apparent to the public as the creators give mixed reviews. Meanwhile, tensions are high at IG and PD. Some people are not happy with some of the decisions made, and they are aware the game is not at the level they wanted to deliver. Anxiety about community reception is large. In spite of this, steam sale numbers are put on a big screen in the conference room as they hope to breach 100K sales on day one. KSP2 Officially releases into Early Access. The game receives mixed to negative reviews, and it becomes clear the secrecy pushed by T2 has hurt the relation between developer and community A person working on the project later admits not getting community feedback was one of the biggest mistakes. They go on record to say “We wound up shipping the wrong product and not focusing on the right features” T2’s marketing campaign backfires as people start to realize the flaws of the game they bought for (nearly) full price ($50) and negative reviews start pouring in from angry and disappointed customers Sale numbers fall short of the numbers hoped for, only reaching 80K. This number does not account for the many refunds that happened ! A few weeks after the early access release, Studio Head Jeremy Ables and Technical Director Paul Furio were let go by higher-up management, which deemed them as the most expensive people in the studio. Furio left immediately while Ables stayed on a few more weeks. Michael Cook, previously Brand Manager at PD, took over the job of Studio Manager. It is also around this time the multiplayer developers were let go. Multiplayer was still janky and buggy at this point, but it was functional in some capacity. Despite this, there was a silent understanding that the layoff of the multiplayer team might have meant the feature was now shelved indefinitely. Focus shifts to bug fixing and working towards the first milestone update, later dubbed ‘For Science!’ (FS!) FS! came out in December 2023 to generally positive reviews, 10 months after the game entered early access. This was a significant delay from the internal estimate of 3 months, brought on by the shift in focus after community backlash about the state of the game. It is during this period that Furio’s cross functional feature team structure is finally implemented Studio Closure, 2024 (Intercept Games) In late April 2024, a WARN notice appeared indicating T2’s Seattle office, where Intercept Games is located, is being closed with 70 people (about the size of KSP2’s full dev team) being laid off starting June 28th. The studio went into near-complete radio silence, with the only statement made on @KerbalSpaceP’s X account “We’re still hard at work on KSP2. We’ll talk more when we can.”. This is a developing situation, and the impact of this on the future of the game is still unknown at this time. Conclusion (ShadowZone’s Opinions) KSP2 development has been plagued by a multitude of issues from the very beginning, ranging from diverging vision to corporate takeovers to mundane issues like tools not being ready in time The project was based on the wrong parameters from the start Technical decisions were made by people that had no business making them The developers were not paid accordingly There were a lot of assumptions about gameplay and mechanics that the community might have wanted that were not verified until it was basically too late The lack of open communication and extreme secrecy did severely harm to the trust of the already existing fanbase, especially after the game went into early access Speculative: the total cost of the project so far is assumed to be around 40 to 60 million dollars so far, compared to an estimated revenue from Steam of Only 30 to 40 million Notes (from ShadowZone, LinuxGuruGamer, Matt Lowne and Scott Manley) Nate Simpson should not take the blame; this was a passion project from him, and he genuinely appeared to want to deliver a great fun game for the existing KSP community, but he might have bit off more then he could chew, and made mistakes such as wobble. A big part of why he might not always have been able to deliver what he promised (despite wanting to do so) are technical and business constraints (example: modding API) Opinion from LinuxGuruGamer, Matt Lowne and Scott Manley: KSP2 can not reach completion under Take Two. The best way forward might be to focus on the modding API in the remaining time, but; mods have their limitations and they will not suffice to ‘save the game’ **PDF VERSION** KSP2 Development Timeline.pdf

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?

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.

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.

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.

This discussion reminds me too much on my time in World of Warcraft. I spent almost all my teens on that game. Was it part of my life? Clearly. Did it teach me something? Certainly something about progress, motivation and goals. But is something lost because I don't play the most recent patches since many years now? I didn't play as much KSP as some of you guys - shameful 2~ years to be accurate - but a big take away from my gaming experience is that the biggest slice of any game teaching or telling you something is always achieved in the first steps. Most things happening afterwards are reiterated over and over again until the player is mastering his skills to meet some kind of end goal proofing you're a specialist. There is only one problem: Some games have no end goal. KSP is just such a game. The deepening of some skills might be fun and such but there is nothing obvious you lose. If you can talk about life altering things you probably have learned it already. You have taken it and nobody can steal it from you anymore because it's in your mind now. The only thing you really lose - and that's very precious for many people - is your passion. I understand that. Passion never really falls from the sky at any time. It's like a rare moment in life where you make the right decision and hit the point and now you ride a wave for a longer period of time. But at the point where you only feel pain or think your life depends onto it you should try to rethink whether you still ride this wave or not. Maybe you're on the surfboard, thinking you have a safe stand these days but in fact the sea is just dry and your board standing still on the sand. Maybe -and I certainly don't want to judge - you just don't want to see it like it is. If you play this game for so long it makes sense to me. Nothing holds up to eternity. It didn't do it for me at least. I see it like this: If I hadn't stopped WoW, I would never have played KSP. Maybe there is the next best thing around the corner waiting to be found. You just don't know it yet. Endless missed opportunities because you play KSP for so long. Oddly, no one is talking about that.

Well... I just learned something about medieval history. Probably can't teach it at my school, even though I do talk about some of the crazy shtuff the Normans got up to back then.

Yes. Big part of that is the handling of non-owned vessels in multiplayer, to make the physics of N-parts aircraft manageable in a game that allows you to shoot off every single part individually. The solution they found "sacrifices" wobble (lol) amongst other stuff, to make offloaded vessels a single integrated part, but keeps the capacity to calculate hits and damage to individual parts. It's very probably an iteration of the KSP1 proto-vessel method. Mind you all vessels are still able to grab fuel/battery from their containers correctly. Like really, at this point you're just throwing vitriol around with zero knowledge of what you talk about. You hate HarvesteR and KSP1? fine. But don't try to pass your hate as anything more but your personal views.

Im pretty convinced at this point they'll leave that roadmap on the steam page after firing everyone until there's a lawsuit more threatening than the sucker-sales of people who don't know its abandonware--which is never. I will never buy a product from PD or T2 ever again and I'll warn off everyone I talk to about games. These are trash people.

I think there's more than one thing that's going on. Modern approach is to use velocity constraints with Baumgarte stabilization for drifts. Baumgarte does work a bit like a spring coefficient, but the velocity constraint already has damping built in. So with a sensible choice of coefficients, any perturbations should naturally decay, rather than lead to more oscillation for any single joint. Unfortunately, systems of joints can still misbehave. The worst case is usually a light object sandwiched between two heavy objects. Unfortunately, I just described every single stage separator and decoupler, which immediately becomes a problem in KSP if you don't add additional joints to stabilize it (such as multi-joint connectors, autostruts, etc.) A very good read on the topic is Erin Catto's GDC presentation from 2009, Modeling and Solving Constraints. Every modern physics engine I've seen goes back to this talk. At a minimum, Havok and Chaos do, as well as Crystal's and Blizzard's internal engine implementations because Erin Catto worked there and was instrumental in making sure these engines worked. Now, not every engine uses impulse exchange as their iteration method, but all iterative solvers are going to behave similarly. I think Erin really likes impulse exchange mostly due to its logical simplicity compared to pure linear algebra methods. Crucially, the PhysX version that ships with Unity predates the industry's switch to this as the main method. So their constraints handling might be a little different, and I haven't looked at the code for that specifically. Though, it might be interesting to try and dig up the source for a relevant PhysX engine and to make sure. In general, even the older physics engines had to solve the same fundamental problem of enforcing constraints. And even if you start with position constraint (rather than velocity constraint) and work your way from there, you are still building a damped harmonic oscillator, but your coefficients might be less "magical" and require more careful tuning. So we're still dealing with what's ultimately a damped harmonic oscillator for each individual joint, but what can still fall into some sort of a bad feedback loop between multiple joints. And we know that mass ratios are a problem for the PhysX joints as well, so whatever the solver is iterating over, it's not that far different. So that's one part of it. Even with a good solver, there are bad configurations that you need to learn to avoid, and for something like KSP that means either merging some rigid bodies together (e.g., if you made decoupler and whatever it's permanently attached to into a single rigid body) or doing what KSP1 does and adding additional joints in a way that avoids the unstable configurations. The second part is, I think, what muddled the situation for KSP2. And here we're back to logical connection vs actual joints. I have seen a number of times when a ship spawns in (either at the launch site or from a save) with some parts detached. And it's one thing to just watch some part of your ship drift away, and another is if it's some internal part with collisions that ends up doing a ragdoll-spaz inside the ship. I don't know how many of the KSP2 physics explosions are due to bad joint configurations and how many are due to a part getting loose and spazzing out. I've definitely seen both, but I wouldn't be able to identify each particular case. And I think that might have been why Intercept kept having these issues creep back up, because there are several different bugs they're trying to fix that can be reported as one bug: rapid disassembly without any obvious cause. All of this is kind of self-inflicted, but I do sympathize. Again, it's a hard problem, and unless you happened to have worked on these exact problems before, it takes time to catch up on all the terminology and required reading.

This. The code would be dead simple (relative to "rocket sim"). Further, if you remove game physics for anything not in the physics bubble and, keep track of orbital parameters and not coordinates, then you don't even need to know where anything is until it needs to be displayed. You could have any number of bodies in elliptical orbits and give them 0 computational effort until you needed to display them. Perfect for high timewarp, and orbits cannot decay, or for that matter wander due to cumulative FP rounding error. As you say, SOI-crossing orbits are a matter of setting a timer (which they should be getting right anyway to support Alarm Clock in the base game.). For high timewarp, I'd certainly start development with treating the boosting ship as a rigid body. Modeling joints under boost at high timewarp seems like a "nice to have" at best. Until you mentioned the Risk twins, it didn't occur to me why you were discussing 3-body sim. Wow, talk about starting with an overly ambitious dream. Man, talk about stuff to defer until after everything else is working! That was the tail end of the roadmap, and it seems like they started with it. Upthread you mentioned the problems in KSP2 with save data and live data diverging. Is there some common problem with saving/restoring full physics data for the public engines? I've seen small indie teams using both Unity and Unreal just treat that as an unsolvable problem and just not save physics state despite being physics-heavy sims. I'm curious whether that's actually difficult with stock physics engines, or it's a case of buying some game save tool off the store without understanding it, so they're stuck with the positional-only information it came with.

Sounds like management wants to keep the product page up and just not have to talk about it again. It got full funding for as long as it was going to. It just isn't worth it anymore compared to other places to put money. So unless the cost of carrying financing drops to nearly zero again, I'd say they've put their money where their mouth is by firing the developers. They just want it to stay on the books to pad the portfolio for investors.

THE SECRET SPACE PROGRAM - YEAR 4, DAY !̶̨̛̤̰͈̥̫̯͎̻̘͕̭͎̣̠̠̯̩̦̫̣̦̤̼̯̿̏̈͛̐̉̈́̀̈̾̓̈́̊̃̈́̒̚̚̕͠*̶̬̺̜͎̳̠̦̗͕̝̠̖̭̝̟̝̠̻̭͉͛̂̈́́͒̽́̀̈́͌̑̂͝ͅ@̸̢̧̢̨̻̟̱̖̤̠͉̠̪̮̭̝̯͚̝̠̺̗̤̪̠̔͋͐́̔̈̒͋͂̾̍͂̋̔̎͒̎͘ͅ^̴̨̧̧̛͕̦̱̜̩̗͎̲̰͔̤͎̪͔̪̭̬̤̈́̾͆̾̑̃̔͠$̶̢̛̭͉̳̭̤̹͔̝͔͌͐͗̿̈́̽́̔͐̑̿͊́̓̍͆̈́͗́̐̄͜͝͠͠͠͝͝͝@̶̦͇̮̠͍̬͙̻͕̞̭̠̅̾̀̍͜ MISSION OBJECTIVE: Send crew to the Secret Space Station CREW: [NO DATA AVAILABLE] It's ya boy [REDACTED] back with another update at Kerbin's most secret of space programs. The Dessert Launch Center (DLC) has had some extreme overhauls recently, including the construction of a much more streamlined VAB. Instead of rocket parts being built is separate buildings and then assembled on the launchpad, it can all be built and assembled right there, and then rolled out. Also, the launch control center is no longer a small tower, but now a full fledged center for launch control. And new barracks have been constructed, which I must say are pretty snazzy, especially for a crumby government facility. Now, onto the important part. This mission will be sending a new crew to Triple-S (as most of us on base call the space station), where they will continue to monitor the Mun and signals coming from it. A recent burst of energy has been detected from the surface, higher than anything we've seen. Almost like something has just come through the portal. Rumors have also spread that they'll be working on an unmanned lander mission that will investigate the structure further, but truthfully we have no idea. Sure, shipments have arrived at base, but these could just be for any old satellite launch too. I don't have clearance to enter the VAB, and those who do are ordered not to talk about what's happening inside. Hmm... The new crew who I still don't know the names of make their way to orbit. "Proceeding with orbital insertion burn." - Unknown Commander "Burning for Triple-S." - Unknown Pilot Now we sit and listen. For any little sound movement or smell coming from the Mun. We finally have eyes up there again, and I will do as much as I can to tel you what those eyes see. What secrets do you continue to hide?

It was said that they will talk as soon as they can, but bureaucracy can be quite a torture at times. If they don't talk within 48 hours I begin to believe we will hear something end of June at best. The team has a heart. I believe in them. Something will be said. They just can't talk now and they feel the pain too.

Not at all; and I highly doubt they mention anything in regards to plans for KSP2 specifically on the earnings call; other than the potential for more clarity on the closures and the reduction in costs related to it. KSP2 was already dropped from their quarterly reports last year where it was previously still noted as having an expected console launch... checks date... Oh, it was already supposed to have launched on console. In this call, they talk numbers not specific details of future plans; and any forward looking statements they do make are going to be focused on positive outlooks, such as expected revenues from GTA6.