Skorj

Kids these days. Video games "came out from a page" long before CDs were invented. You typed the source code in line-by-line from pages of the gaming or coding magazine you bought. Now you kids get off my lawn, I have clouds to yell at.

If you've ever noticed the "ease in physics" setting in KSP1, this is why it's needed. It's not just on load, I think, but any time you switch to a new craft, it risks kraken attack due to only partial state being cached. Squad solved this rather elegantly IMO by simply ignoring some physics effects until the physics model has time to settle down. Now that I understand K^2's explanation, I have to admire this approach.

Yeah, C# has had a lot of improvement in the past few years, which is surprising for such a mature language. It's baffling why Unity is stuck with such an old version of C#, perhaps they see Android as their primary platform now, but it's been clear for a while that they've lost their way. But of of course that wasn't obvious in 2017.

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.

For clarity: Private Division works with both independent studios in a pure publisher-studio relationship, and the T2-owned studios Roll7 and IG. The April action by T2 seems to have been to close the in-house studios. Fans of Roll7 are facing the same mystery, lack of communication, and corpo-speak. I believe that what's going on was largely unrelated to the struggles of KSP2. T2 just decided to simplify their corporate structure to make life easier for executives, as corporations do from time to time, and so just closed all the small shops they had. However, for legal reasons, those studios can't be officially closed, so they'll forever remain "open" in name only, with any remaining work done by a support team at PD to make sure any minimum legal requirements are met. It's not just common but the norm for AAA publishers to buy small studios with passionate fanbases, ignore the games that made those studios successful, then close them a few years later. It's baffling to me why this is normal, but it's not just in gaming that it happens.

For the game we have now: you can usually plan missions such that you have plenty of time at 1x speed to mess with maneuver nodes as you approach them. The key exception being circularization after launch, depending on what your launch looked like. For launches from Kerbin, I always went for 100 km orbits, just to give myself plenty of time between leaving atmosphere and reaching Ap, as I had problems with that in 80km orbits. Hope that helps,as the game is unlikely to change.

Yeah, it does make sense that the AAA studios would have that as an advantage of their custom engines. Surprised it has taken this long to trickle down, but it's cool that Unreal is on it. (Totally agree on the threading approach.) I don't know, you can get some good performance out of C# these days if you know what you're doing, but I suppose it's a case of "do the hard stuff in the language you know best". Thanks for inspiring me to read up on std:atomic, since that was added about the time I switched to distributed systems (which ironically don't usually use clever multi-thread optimizations). Interesting choice by the committee to only offer the slow-but-consistent fetch-and-add based increment, and avoid the fast-but-inconsistent atomic increment. The latter was always a footgun, of course. I'd certainly do orbital colonies as rigid, unless everything was working great and the team had time left over. The whole "do the minimum viable product first" approach. IMO this was the big leadership failure in the KSP2 dev process, they aimed too high without a fallback that was still a good game. I don't understand why they didn't start with "just KSP1 without the crashes", then incrementally add cool new ideas until the funding ran out. That's such a basic best-practice for running a project. For surface colonies, is there canned solution yet for "I want a large static map, except for some small cutouts here and there where terrain is replacable/deformable as a rare exception"? KSP2 rolled their own ambitious solution, and small indie teams just seem to live with the restriction of trying to do base-building on non-deformable terrain. Seems like the kind of common problem a game engine should solve, but maybe they're working on "just make maps of all deformable terrain fast" instead? Thanks for your insights on engines! Unreal certainly turned some corner in the past few years, as all the "small indie team sim games" I follow switched to Unreal as easier in their current work. But for KSP2 I'd do all the orbital physics as custom anyway, leveraging real-world solutions, so it would probably come down to what the art side liked better.

When talking about a KSP2, he suggests doing the colonies part working first, not doing it to exclusion of the physics. What we got is a buggy mess with physics problems and nothing new added to the genre. With Felipe's plan we would likely have gotten a buggy mess with physics problems and a working colony system, and so we'd have a reason to play the game instead of KSP1 or Juno. Lots of people enjoy KSP1 for the planes. It's a big chunk of the game's appeal. Maybe you only enjoy it for the rockets, and that's fine, but the game has a broader audience than just the rocket sim fans. It's a very accessible "design and fly your own plane" sim. With the planes as a stand-alone game, more effort could be given to tutorializing that aspect, so that Ferram Aerospace could be integrated and players could work up to the added complexity. I think it would be fun.

Are you being pedantic about "laid everyone off" and "laid almost everyone off"? Because we know they are laying off a number of people in Seattle about equal to the whole Seattle team. Sure, there may be a few survivors who find work elsewhere in T2, but the IG office is gone and 70 people are laid off, per the WARN notice.

IGN's take. "Take-Two CEO on Intercept, Roll7: 'We Didn't Shutter Those Studios'" https://www.ign.com/articles/take-two-ceo-on-intercept-roll7-we-didnt-shutter-those-studios But it's all corporate bafflegab; meaningless. So you closed the office, laid everyone off, but "didn't shutter the studio"? That's pretty much what we heard before: no one is working on it, but he's heads down working hard. I'm assuming the studio lives on in name only, the work has moved to a legacy code support team, and we'll get whatever work was in motion on 4/29 in the next few months. Then critical bugfixes only. I'm starting to get rather upset that the roadmap is still on the Steam store page, unless there some secret plan to replace everyone and start over (which seems ridiculous at this point).

@K^2 Thanks, I appreciate the detailed reply. I'm really surprised rollbacks aren't a standard part of physics engines these days. (It occurs to me that if you have enough to do rollbacks, you're most of the way towards being able to snapshot and then save in a different thread, which is something else I'm surprised isn't common.) If you're doing custom work anyway, is Godot a better starting point than Unity? At least then it's not a black box. I think I shouted "next BATCH of items to grab" out loud. Old habits die hard, I guess. I really need to deep dive what the fast way is in C# to do this correctly (this is much easier in Java, because the answer is "everything sucks, shoulda used a different language if you cared"). I'm used to thinking of any cache-piercing actions as being really slow, but I guess you can safely assume a single-socket system for gaming and my intuitions are probably all wrong. I like your "islands" approach a lot - if there were KSP1-style physics bubbles around what each player was controlling, you could get good results without so much work whenever they didn't overlap. Of course, maybe docking is where you have the least tolerance for rubberbanding, so hmmm. I think if I were attempting it on a small budget I'd just add a docking computer component to the game as a work around. OTOH, perhaps with smart use of part welding, so that as you mention a simple rocket was just a single rigid body, you could probably get away with a lot of not-very-performant stuff. Especially the case where it's just two Kerbals running across the surface next to each other (or both interacting with static controls at e.g. some colony), which might be a lot of the gameplay.

I doubt KSP will even come up in the earnings call, though maybe in the Q&A if there's analyst who's a fan. The big news will be any details on when GTA6 will release, as that's the money printer for T2.

That sounds entirely believable. Damn shame too, as a cleaned-up KSP1 codebase with some core fixes to let the physics scale better, and graphics the equivalent of the better mods would have won my heart. Other than multiplayer, adding the rest as effectively big mods seems the safe way to go. I'd think multiplayer would have to be plumbed in to the base game early. Unless the team had some hands-on experience with multiplayer development, I don't think that would have been practical, I think a lot of us would have loved an EA release that was KSP1 with fewer bugs and updated graphics, with new features coming over time. Even if multiplayer was off the table, I certainly would have been happy with colonies / logistics / interstellar coming in every quarter or two if it started with a better KSP1. K^2, slightly off-topic, but how hard is combining multi-threading physics and multi-player these days? I've done a ton of distributed systems dev, but the big performance gains required accepting that the system was not quite deterministic. As I understand it, that's unworkable for multi-player, unless someone's gotten clever in the past few years.

You're talking about existing players. I'm talking about potential new buyers of the game, whose purchase could fund future development work. Recent reviews showing as "overwhelmingly negative" would be very off-putting to potential new buyers, so it's very hard to get a wave of new buyers giving positive reviews. While it's theoretically possible to climb up out of that hole, e.g. people could change their existing reviews, that's quite a rare event.

I don't have kraken-style bugs in KSP1 any more (I do try to avoid any part overlap to keep the kraken at bay). The worst I worry about is wonky landing gear physics, which frustratingly Juno has too. But I do save in case the game crashes due to memory leaks, which happens every so often. While I'm not pushing the bounds of KSP1 ship size, I haven't really seen the old style of bugs past 1.7 or so. Maybe I'm just lucky, but for the past few years the only bug I've seen other than kraken attack with overlapped parts is the game crashing. I haven't seen that except for bad interaction between vanilla and the Alarm Clock mod when I set an alarm very close to the burn. KSP1 will blow past where you want it to if you manually set very high timewarp and then try to stop on a dime, but I don't think that's what you're talking about. Couldn't agree more though about the game industry not valuing players' time. It's why the good indie games shine.

Yeah, with no official communication there's no way anyone is going to be allowed to say something on their own. If they are going to continue development past bugfixes, this silence may have doomed the game anyway, due to the Steam review score. Still, I would love to see colonies finished.

Tried and hated Helldivers 2, can't understand the hype, but then discovered Abiotic Factor. Wow, I think it's the first crafting survival games with enemies I've ever really liked. Possibly because it starts in a Half-Life 1 Clone world. Also revisiting Planet Crafter for its 1.0 release, as that may be my favorite crafting survival with no enemies game. Basically killing time until Factorio 2.0 comes out. I sure hope that whoever's working on the next rocket sim game will include some expressive quirky characters and not just empty spacesuits. It should be obvious by now how important the Kerbals are to the experience.

Well, it's certainly easier to understand how we got what we got if the team were much smaller (or had a lot of do-nothing overhead jobs)! I don't see why there would have been a re-start, though, unless work product was lost, or the reason ST ended was that T2 really didn't like what they made. Imagine me ranting for an hour here about ancient dev practices like waiting until all pre-prod work is done before starting any prod work (benefit of being retired is no longer having to care). But for KSP2 in particular there's a lot the team could start on right away: you don't need rounds of concept art to know what a Kerbal looks like, you know the first coding task is to fix the physics, and so on. Come to think of it, didn't Nate did say early on that they started with fixing the "big problem" of KSP1 physics, and completed that to prove the idea viable? One reason I suspect code was lost with the studio switch is, well, it sure doesn't look like we got a fixed core physics sim.

IG had continuity in people from ST. I doubt it was 70 right away, but they started with a sizable team. We don't know if any of the code from ST was available IG. But for sure a large team was working on KSP2 from 2017 on. The fact that half the team and perhaps all the code was lost in 2019 is just one more screw-up on the pile. One month of lost work due to Covid is totally reasonable. 6 months is either some serious slacking, or the kind of screw-up that it takes multiple MBAs to arrange. I've seen people claim they weren't able to work for 18 months, which is going too far to make excuses. So we don't know all the details, but it seems reasonable to assume they had at least half that 70 on average working for 7 years. That's 200-250 dev-years. Far, far beyond what KSP2 EA should have taken. You make a good point about the procedural graphical work being substantial, but IMO that's "a handful of dev-years" substantial. Plus the overly-clever stuff they tried to replace sections of terrain to insert anomalies (and presumably colonies), which was a cool idea but presumably is the root of the "fall through the world" bugs. As you point out, there's a lot to a game like this beyond what the player controls in-game. But it's off by an order of magnitude IMO. Of course, if their code base is as bad as the bugs suggest, that would seriously slow development time, but still. Either there were some serious shenanigans as ST/IG, or the rumors are true that before EA they did a lot of work on colonies, and a lot of work on interstellar support, and a lot of work on multiplayer support, and who knows what throw-away work. I figure it's a little of both: something wacky had to have happened with ST, something out of line with the usual publisher / late studio relations. I can't see that amount of dev work for what we got without bad dev practices and trying to do everything at once and ST management shenanigans and Covid and T2 being unable to hire replacements for senior roles all taking a chunk out of productivity.

With this much silence, it's reasonable to conclude that the game has been carried to Mount Doom by a couple of Hobbits and chucked into the volcano. It has shuffled off this mortal coil and joined the bleedin' Choir Invisible.

The secret to beating the biters is Hopefully your factory is growing well. I'm just wrapping up my latest megabase run, which I'm rather happy with, before setting the game aside again until the expansion.

Well, I'll summarize by saying that given a "patched conics" universe and stable orbits (not under boost, not crossing SOIs), you don't need to track the location of an orbiting object frame-by-frame to know where it will be at any given time in the future. This is a "well-solved problem" in physics. Sure, you have to approximate using numerical methods, since the equation for the objects position as a function of time has no closed form solution, but you can approximate to the accuracy of a double-precision float very quickly, and FP rounding errors won't accumulate. Stable orbits is what we'll care most about, since that's every commsat, scansat, orbital colony, and so on. So from the start you want a solution that scales to many thousands (or millions) of them, so that it's a non-concern performance-wise in normal gameplay. And of course part-welding is a huge performance win for rockets under boost/atmosphere. Kithack nailed that IMO: model joint stress, but as far as game engine physics goes a rocket is 1 big part. A lesson that HarvesteR would surely have shared, had he been asked.

Game engines aren't my area of expertise, but from what I've heard, Godot wouldn't not have helped the game's rendering performance problems. Unity just has a lot more effort put into core optimization (and Unreal even more so). I haven't heard anyone describe Godot's 3D performance as anything better than "it's acceptable now". And of course the huge downside of Unreal is C++. I used C++ professionally for a dozen or so years, and I'd never go back. Not to revisit the usual language holy wars, so let's just say the cognitive load for writing/reviewing C++ code is just a lot higher than C# for most tasks, because of all the landmines and historical baggage of the former. When trying to find a complex and subtle bug, the fewer things to consider that might be wrong, the quicker the process. I'd just take a very different approach to this kind of game. For a game with colonies, I'd want to effortlessly support thousands of objects in stable orbits. There's a way to do that with fairly simple and straightforward code, by using a solid understanding of real physics rather than doing the work with game engine physics. But this forum is probably not the right place to discuss that.

In Felipe's interview today we heard that all the OG KSP1 devs left before the sale to Take2, so Squad wouldn't help much.

Really cool to hear he backstory on the team and the Kerbals.