K^2

Honestly, both. As in, both of these kinds of coders.

That often applies, but KSP does require more technical knowledge than most games. And even HarvesteR has a degree. So while, perhaps, it's not strictly necessary, it sure helps a lot, and someone entirely self-taught will have an incredible amount of catching up to do.

To me, as someone who has been in a position of managing (and growing) engineering teams across multiple projects at companies both smaller and much larger than Intercept, as well as someone with a background in physics (including patents from work in games), this unfortunately raises more questions. I want to avoid jumping to any conclusions, but the fog of war on hiring did seem like a reasonable explanation for why the team did not know how to make a KSP game. If you are saying otherwise, I do not understand the objectively bad decisions that have been made from the technical perspective.

Again, have you watched the video? ST was given $10M and 2 years. Nate said, "Can we have more, here's a pitch," and T2 said, "Yeah, we like that. Lets do that." This is when ST started trying to hire more people, and where they ran into the first troubles with how T2 wanted to do this. It was entirely on T2 to say, "No, you do this with your current resources," and then you could hold Nate responsible if he didn't go with, "Well, here's a $10M pitch." But Take Two didn't, so Nate pushed on the larger scope game, which, as I'm getting tired of repeating, is all his job requires him to do. And that was the original pitch. But the increased scope should have immediately required a change in structure. I would argue T2 should have brought in their own specialist since ST didn't have one to do due diligence on the project. They either haven't, or brought in somebody who doesn't understand KSP at all.

The whole thing is implausible. I would tell you that it's implausible that the game had no technical director for 4 out of 7 years. And yet, here we flippin' are. Take Two has bent it out of shape so bad, that to go with your knee jerk reaction of, "There's a person nominally in charge, therefore, it's their fault," is the unreasonable response here. You'd be correct 95% of the time, but we're in these other 5% with KSP2.

Again, much overstated. Would you be happy with rockets having zero flex at all? Because that's really what Nate was fighting against with nobody on the team being able to provide technical clarification. Of course decisions were made by Nate. There was nobody else in charge for more than half of the project. Intercept started with 4 junior engineers. Who do you imagine making decisions in that case? Well, if you want to get all legal about it, Nate's covered by the mens rhea principle. He had no intention of making a bad game and was given zero resources to make it better. Under the circumstances, he has done as much as any competent art director could do for the project and more. You're holding Nate responsible for jobs of what should have been five people. And you're saying he's guilty for not being five people with the relevant experience? Is that the standard by which you want to measure contribution? If so, you're not looking for the guilty party. You're looking for a scapegoat, and I find that disgusting.

You push back by asking T2 to hire somebody. T2 hired Paul, who by all accounts also didn't understand the game they're making, because T2 didn't even allow the job postings to mention that this is for KSP-related game. Now picture it, you're an artist. You're asking to hire somebody who knows what they're doing. Eventually, you get an engineering director who says, "Yeah, we'll figure this out." Do you go, "I doubt your credentials, good sir, I don't believe we'll figure it out," or do you go, "Oh, great. Lets gooooo!" Because I imagine it was the latter, and I have no idea how anybody could blame Nate for that. Again, the problem might not even been with Paul as an engineer, but with Paul being the wrong kind of an engineer who join the project late to boot, and that's still very much on T2.

T2 did marketing for KSP2 EA. If you watched the video, it's clear that communication about KSP2 progress was filtered through T2 and significantly throttled. Nate was allowed to share his vision and enthusiasm with us. I don't know if he'd be able to share the hurdles of the project even if he were fully aware and able to communicate them. Which, again, should have been up to production and technical leadership. So please, go through and point at where Nate has been lying.

For most of KSP2's development, the game did not have engineering leadership. That sounds absurd, but that's the timeline that ShadoZone presented, and I find it believable. So the empty space that should have been doing technical leadership was incompetent, yes. That's hardly a statement I can contest. I would also argue that the technical leadership the game has had has been inadequate. I don't think Paul Furio did what was necessary for KSP2 to work, and while I still don't think it's worth calling him names over it, or even to be certain that he's bad at his job in general, this is one example where a fraction of blame can probably be placed fairly. Again, with caveat that KSP2 was a special project that needed special technical leadership, and Paul Furio was not it. The bulk of the blame is still on T2 for refusing to hire people with proper announcement in the req of what they're trying to hire for, or ensuring the pay range is adequate to meet these requirements. Neither of these things happened. I know I wouldn't work on KSP2 for $150k/yr even back when I was a Senior Engineer. You can't hire competent tech people with that cap. It's impossible. They only hired juniors because that was the salary cap. Even people who were hired later into higher level roles clearly lacked the experience, because nobody with experience would work for that salary.

Take Two. And I'm sure there are specific people within that org that we could put a blame on, but I don't know who they are, nor do I particularly care. A publisher ensures that a) the project has resources to meet the scope and b) the people involved in development have competence to keep the project within the scope. It was clear that one of these things did not happen, we just didn't know which. Now we have learned that the correct answer was both. This is 100% on T2.

I'm not sure where you're getting that from. In order to have a compromise, you have to have somebody offering an alternative. I don't see T2 pushing to reduce the scope or a competent technical director telling Nate that what he wants to do is not feasible. All of the people who have to work with the creative director to reach that compromise position were missing. I am amazed that KSP2 got as far as it did in these conditions, and I can't imagine anyone doing a better job in Nate's shoes. I've worked with a bunch of creative directors on a bunch of projects, and all of them want to build a bigger shinier thing. And I had to tell them, "No, we can't do this," or "No, it will be too expensive," or "No, but here's how we can do it differently," many, many times. I had to do that because I was the tech person on the project. And that led to discussions and either a scope reduction, approval of more resources, or some other adjustments. It's the creative's job to want more. It's the technical, PM's, and production company's job to say, "we can't have that." So unless a clear evidence is presented that Nate has been overruling good technical advice, or lying to Take Two, or in some other way doing something other than his job title required him, I see absolutely no reason to hold Nate accountable for things that weren't his bleeping job to do. Since you tagged me in, take note. Well, I don't know, maybe when you see someone with experience making a thing defend someone else's attempt at making a thing, instead of being "sick" of it, try to understand why? Maybe, just maybe, a person who knows how games are made has a better idea of whose fault it is that something didn't get made right? Just a possibility, maybe?

As someone who can do better on the technical front, HarvesteR isn't the right person for the job. KSP2 needs somebody who understand how to make a game with a wider appeal, which is not HarvesteR's strong suit, and somebody who has deep understanding of game tech and physics to handle the technical aspects, which isn't HarvesteR's strong suit. HarvesteR is very good at finding new concepts and proving them out (or not). That could be fantastic for a particular aspect of a game like KSP2, but not the game overall. And I think HarvesteR himself would be happier making a new game, not just expanding something that already exists. That is where his strengths lie.

Yes, and even @linuxgurugamer specifies that some flex is necessary. The discussion was always about how much wobble, and what are the technical limitations. Nate did not understand technical distinction. It was not Nate's job to understand the technical distinction. It was the engineering director's job to explain the specifics, likely relying on whoever is in charge of physics for input. The problem is that a lot of that discussion happened at ST/Intercept before they even hired their physics expert, who wasn't an expert on game physics. So if that's all you've got, I find your competence lacking in making the call, and it is my professional opinion, both as a physicist and a game developer, as well as someone who's been playing KSP since before it rolled out on Steam, that you owe Nate an apology.

Please, watch the video again, and tell me what Nate should have been doing differently. Keep in mind, that the job of saying, "No, that's not how things work," falls on the technical director, not on Nate.

@linuxgurugamer has it right. It needs new code. There is a world where KSP2 is handed to a new team and they spend time fixing it and cleaning it up and turning KSP2 EA into some form of a finished product. That will still cost tens of millions of dollars and the result will be hardly worth it. I don't think anyone who can make KSP2 better will take the contract for the budget T2 is likely to offer. The other possibility is you start from scratch. I would argue at this point, not switching to Unreal would be criminal. You can make the game work with Unity, but it will actually be a lot less effort, and therefore both cleaner and cheaper, to make it in Unreal. This game needs a clean break at this point. Take Two very clearly doesn't want to do either of these things. I'm not going to say as strictly, "Not with Take Two," but definitely not with Take Two under current management. Either the IP gets sold, or we will be waiting a very long time before a proper attempt at the KSP2 can be made. Unfortunately, I don't think T2 will sell the rights. Kerbals are too merchandisable. The business savvy move is probably to make non-KSP games based on the characters, and maybe some are already under development, just with the same degree of secrecy. Intercept was hiring for a game project that we've never heard anything about. It's not impossible that that project was transferred to another studio a while back and is still ongoing. Either way, that's likely what's next for Kerbins. The only way I can see a KSP-style game made with KSP IP in the near future is if a third party licenses the rights. T2 might be willing to license rather than sell. But that can lead to some unfortunate questions about KSP2 that could take a legal undertone, unless converting all of the KSP2 purchases into keys for the new game is part of the deal? I just don't know how has both the resources and the desire to take on the risk. I know RocketWerkz has been talking big about a KSP-successor, but I don't think they have the know-how or the resources either. They're in the same situation as the original Star Theory was at best. Very enthusiastic, with vision, and with no resources to drive that vision to completion. This is pretty grim. I was trying to look for silver linings over the past few weeks, but I don't think there are any left. Other than being vindicated in saying that Intercept didn't just fail - they weren't given resources to have a chance at a success, the few things I was hoping for as a way to rectify the problem no longer appear to be in play. Also, thanks @ShadowZone for an in-depth dive. A lot of this was clear to people familiar with the industry, but you filled in a lot of the pieces that make the overall picture look so much worse. Edit: I'm not sure you watched the video. Everything that prevented Nate from making the game he was talking about has come from above. And while clearly, Nate was making decisions based on look and feel rather than technical realities, that is the job of the game's creative director. The game's technical director is supposed to be pumping the brakes and making corrections. That did not happen. All of you taking it out on Nate is bad tone on top of being just coming across as someone being ignorant and incapable of comprehending information presented even if it's broken down to you in a video.

Yeah, $10M and 2y sounds very close to what I expected the original ST project to fall under. I hope that this at least makes it clear that Intercept was making a very different game than what Star Theory was originally contracted to do. Edit: It was clear to me that development started on a much smaller budget and suffered a disruption that effectively reset the process. But this is so much worse... Watching Shadowzone's investigation, I'm impressed we got Early Access that kind of works sometimes at all.

Well, the question is, do we want flex at all? I'm not sure the community overall would have been happy with rockets that are perfectly rigid in any configuration. No matter how absurdly long and thin you make the beams? It would also be way harder to tell what's failing. When properly configured, flex sort of tells you where you don't have enough structural support. So if your rocket snaps, you usually know what happened. With rigid rockets, you can still compute the stress on all the joints, and it can be done very efficiently. But then the player would have no indication that something's close to breaking. The first indicator you'd get is the parts failing and your rocket falling apart. And the moment you have flex, you're going to have wobble in some configurations. Your options are absolute rigidity or a sometimes wobble. I'm not convinced that it was a conceptual mistake to go for the latter. It might have been wrong for the team's capabilities, which is also an argument to be made, but I don't think we could have known that back in 2020.

KSP1 ships go on rails if you're warping even if you focus on them. That's why people use warp to freeze physics, rotation, and fix other problems. It's equivalent to switching to KSC and warping from there. If you do stay focused on a ship on 1x time, you do still get drift. You just have to have a lot of patience to notice anything significant, since you are in local coordinates and the time step is a fraction of a second. Whether that's a net decay or net boost, I never had the patience to find out. Yeah, I think they ran with what's possible, and not with their team specifically can do. But the game director is almost always a creative, and they always push for more. That's normal and what every game development process will go through. It's the game's engineering director's job to say no, and then you start having discussions about what the limitations are, whether they can be exceeded by hiring more people or circumvented with a different design, and you arrive at something functional. That didn't happen for KSP2, and it sounds like the problem was on the engineering leadership side, unfortunately. So game led by artists wasn't the problem. All indication is that the engineering didn't apply the brakes where needed or supply a solution. And while orbit decay specifically is a deceptive sort of problem, where I can see someone underestimating it initially, there were way too many examples that land the same way for me to excuse it. Technical leadership dropped the ball, and maybe Nate et al. should have recognized that sooner. Engineering director was eventually replaced, but I have no idea what sort of impact that had. The replacement would have been stuck with an absolute mess to untangle, and that obviously would take time.

It's a standard solution. When you're doing floating point math, your sensible options are single precision (32 bit) or double precision (64 bit). And while most modern CPUs do basic operations with double precision floats at an ok speed, a lot of the vector operations aren't built for it, and consumer GPUs are absolutely horrible with it. Your realistic performance penalty from going from 32 bit to 64 bit floats could easily be in 5x-10x range. As a consequence, none of the tools are even built for it as an option, so you'd be stuck with dirty workarounds to have an awful performance in the end anyways. And 32 bit floats are precise to roughly one part in 10 million relative to their magnitude. So if you're dealing in distances of a few km, your precision is sub-mm, and that's fine. Once your distance scale is more like an astronomic unit, the smallest increment you can do in your position is in tens of km, so all your craft parts and geometry are at the same exact coordinate to that floating point precision. Realistically, though, your ship will get krakened to bits long before you make it that far. So instead, you do all your physics and rendering in some sort of a local coordinate system, relative to an origin that you relocate as needed. There is a little bit of a leeway in how you store that origin's position, and I haven't looked at how KSP2 handled it. A lot of open world games that start running up against this simply store origin as a float as well, and eat the complexities of dealing with the fact that the location isn't perfectly fixed, but even that starts getting wonky at interstellar distances. Using a double precision float is a lot more viable for the origin position, since you don't use it in simulation - it's just an offset. So that's pretty common. I would make a case for using a 64 bit integer, though. You could then place an origin anywhere within 1km of where you want to do the simulation, which is close enough, and that'd still let you place objects nearly a million real world light years away from Kerbin without loss of precision. The way Intercept talked about it makes it sound like they were having more trouble with it than I'd expect, which might be just the devs never having to have had to deal with this before, but otherwise the approach is fine. It does look like they had some bugs in the relocation code, and I don't know if they were all fixed, but that in itself isn't really uncommon either. This is just part of a development experience for a game where distances are that huge.

The question comes down to how you update the orbit. KSP1 ran this for ships under player control in Cartesian coordinates. Fast and dirty, and also results in an absurd amount of error. It looks like KSP2 team was doing something very similar. And in Cartesian, just integrating the main body's gravity goes awful immediately. If you are integrating forces in orbital elements coordinates, you're back to doing very heavy math for changes in argument of periapsis and anomaly at epoch. Fortunately, KSP simulation doesn't need to be predicting with high degree of accuracy if a given real world asteroid is a danger to Earth 30 years from now. So a mixed coordinate system can be used as I've mentioned earlier in the thread. So long as you integrate energy and angular momentum change directly, your orbital shape will be correct, and then you can use the Cartesian update to figure out periapsis precession and the true anomaly update. And if these latter two end up a little off, nobody playing the game will notice. That part there are at least standard methods for. You basically have to run a variable time step, with different step sizes for every craft, depending on their local gravity strength and the engine thrust. In most of these cases, the craft is either engines-off and on rails, or it won't be in high curvature area for long, so it's ok to spend more computation there. At worst, you'll have very occasional slowdowns in your simulation. The only special case is low orbit, low thrust. Here you'll have to pull out some formulae from dusty books on satellites orbiting the Earth to see some approximate analytical solutions which will let you apply coarser steps to such craft.

It's really easy to fall into the hole of, "Orbits will be fine, so long as the integrator is good," because gravity just doesn't like that happening. If you are coming into it from perspective of a game developer, velocity Verlet solves basically all your problems, and RK4 is there for the few cases it doesn't. Gravity is a rare exception to that. Likewise, if you're coming in from physics, the understanding of the physics can actually be a little disarming. All of the actual physics that's relevant to a game like KSP I have learned in undergraduate courses, mostly in Classical Mechanics. I've picked up more context, some methods, and just experience using this in the later years studying physics, but if anything, it made me feel like gravity is a simple problem compared to other things I knew. And that can do more harm than good when you start trying to solve a practical problem. The only reason I really know better is because I have tried to write simulations, realized I'm crap at it, and started looking at other ways to do this. And I've done so incrementally over the years, often prompted by something that came up in KSP or on this forum. This is an atypical experience for any given team you'll put together to make a game. I can only guess at the logic that went into the KSP2 sim, but the requirement to warp under thrust was probably what kicked off the chain of bad decisions there. KSP1 didn't need to do simulation. The moment you go into warp, simulation's frozen and everything's on rail. The only part of it that's sim-like is SoI boundary crossings, and as far as I can tell, it would just check if you are in a different SoI after doing a time step. So there was some randomness based on where the true SoI crossing is compared to the step size, but it's nothing that's going to impact the gameplay. I'm sure that even with the on-rails update there were places where drifts could occur, but it's nothing like KSP2's. In KSP2, you had to be able to leave the engine running and go to max warp, because you're not crossing an interstellar void otherwise. So you have to simulate physics somehow. And it turns out, applying a simulated force to an object in orbit is actually really, really hard. We're talking old books, from the pre-computer era hard, because while there are numerical methods for dealing with this, they're absurdly expensive computationally. If you want a good simulation that gives you stable orbits, is fast to compute, and can work across time warp ranges, you have to work with orbital elements, and not simply use them as a convenient geometrical representation, but understanding how they arise from the constants of motion, understand Hamilton-Jacobi equations, have a strong sense for a classical perturbation theory... This used to be fairly common part of physics curriculum in, like, 70s and 80s, back when things like orbit precession had to be computed by hand, but basically as soon as that was replaced by computers, it started becoming a lost art. And it's not that it's so hard to learn for anyone who has been doing other areas of physics. It's just knowing that you need to learn it so that you can do the numerical simulation that KSP2 requires is a very non-trivial bit of domain knowledge. And yeah, it's not like it hasn't come up before. There have been numerous discussions on physics under warp and n-body gravity on this very Forum, plus a number of members of KSP1 modding community have become acutely aware of the problem trying to implement these features as mods. So it's not like KSP2 team wasn't able to discover both the problem and some potential paths of solving it in advance. But they evidently didn't, so that was another rake in the tall grass.

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.

Or at least, it will! You just need to put a little bit more into it, and then it'll definitely pay out! But seriously, it's a complex topic. Someone's always getting the blame for the losses at a corp, so while the company overall is going to steer clear of doubling down on losses, whoever thinks they'll get the blame might very much be willing to bet everything on it working out eventually. That can lead to some bad cycles. I don't think any of that applies to KSP2, though. T2 is both happy to cut any losses there, because it's a fairly small percentage of total operating expenses and the leadership will look on the net performance of the game as something to adjust for, and to re-invest into restarting the project later, because it's still an untapped revenue source.

Formula that is too advanced for a particle physicist, but NH4Cl managed to unlock its secrets after thinking about it for a while. Not at first glance, of course, it's way too advanced for that, but on the second try. Forget integrals of motion. Comparing too ratios, that's the advanced mathematics that needs more than one look at it to wrap your head around it. They'll crack quantum gravity any day now. I honestly expected nothing else. Thanks for making my point. I've nothing further to add.

I'm pretty sure I aged from reading this,.