RocketRockington

I really wish KSP2 had tried to do something else with the part physics. It's not just that noodle rocket suck. Though they do and even with PhysX there were other options - for instance having all parts rigidly attached and computing stress tensors for breakage bespoke. But it's also the PhysX is too much of a general purpose physics engine oriented toward a wide variety of standard game uses, rather than one what's specialized for what KSP really needs. KSP needs a physics system that is optimized for mechanical linkages. And one that tries to be more accurate/realistic about how forces worked rather than just the verisimilitude that PhysX offers. Conservation of energy/momentum is just not a thing PhysX really cares about, other than making it look right, for instance. KSP2 could have done this in a couple of ways. Unity allows you to change out the physics engine, though it is a bit more work to swap it out, a game that is so physics dependent should have at least investigated doing this. They could have used a more open-source engine that allowed them to tinker under the hood. Bullet for example. Stormworks: Build and rescue uses Bullet and has thousand-part ships that are rigidly bound together, and physically simulated, very similar to what you'd what in Kerbal They could also have licenses an engine that is more optimized for mechanical simulation, like MuJoCo or BeamNG Unfortunately, I don't think this is a decision that will ever make the dollars and cents logic at this point for them to retract and redo - I feel bad that when their version of breaking ground robotics comes about, it's going to be just as floppy as KSP1's - maybe more so since the KSP2 team seems to currently want the floppiness.

I think it's just the style of humor they're going for. I find even just the descriptions offputting. But Minions is a hot brand, and I'm sure that also influenced the thinking. Between the tutorials, PAIGE, and the Kerbals, though, it's clearly trying to pivot toward a younger audience.

If they didn't do engineering prototypes to identify key issues - like 'oh hey our planet rendered can only run smoothly on a 4090' (a card that didn't exist 3 years ago) then again, that's a failing their project management. Prototyping isn't JUST gameplay prototyping, especially when you have a systems driven game. They *claimed* to have a working build, with at least Kerbin in the promotional footage for 2019. It should have been much more than prototypes, since they *claimed* they'd ship in 2020. And they carried their project management over to Intercept. [snip] Because, first of all, they 'got to alpha' when they were supposed to get to beta. Failing that is bad management. Second - their 'alpha' isn't even a feature complete alpha. Alpha typically means 'game is fully testable, although all content is not in'. That means all systems are in. They've only gotten to an alpha of part of their game systems - and not even the most difficult one, multiplayer. Finally - it's the same project management. Same Creative Director. Same executive producer until Nate Robison left. Same Studio Manager. Same Art Director. The same ones who screwed up things at star theory. You're the one who's giving them a total pass for entirely messaging up their whole project once. I'm not. Games typically don't get a 'do over'. And the fact that they messed up their do-over this badly? Sorry man, but this is the height of bad management. It's beyond bad management tbh. Stats on this? PD is a small division of Take2 and they seem to have lost several staff. Unless most of Take2 lost >10% of their staff, I'm not buying this. I never said it was a re-skin of KSP1. You said that Star Theoy's KSP2 was a reskin of KSP1. And I don't see how that at all relates to whether they're badly managed or not. Companies can make a mobile game in 6 months if they wanted to. There absolutely is no 'getting to alpha should always take 5 years, anyone who does it faster is a genius' which is what you seem to be implying. When I'm working on a project, I look at the resources at hand, the core goals of the project (gameplay pillars, quality bar, target audience, etc), and plan out the best way to reach that goal with the resources at hand, or tell the people setting those goals that they're unrealistic. When someone FAILS to do that - that's bad management. EIther failing to get where you're meant to in the allotted time - even if you have to reduce your target - or making it super clear to upper management that its impossible to do what they're asking. What clearly happened in Intercept's case is neither of those things - these people, who ALREADY had a chance to try to build this exact game, somehow told management they would be able to do it by end of 2021, KNOWING all the challenges they'd face - again, most games don't get the 'do over' and the fact that they did and flubbed it is a massive point against them. Then, given a massive extension, despite all that - they failed again. Then, given another massive extension - they failed again and released this garbage which, as I'll remind you, is a barely-alpha version of a cut-down feature set of their target game. A game they CLAIMED to be able to release by 2021. [snip] If you work at a company, and you say 'I'll be done by next week', and people count on you to get it done by next week - even if that 'next week' goal is very ambitious - and you screw it up, over and over - well, it's terrible time management. And if what you end up delivering after multiple flubs is a big fail - even if the time frame was STILL ambitious - it's a big failure of time management, especially since you had the chance to figure out what you'd been doing wrong all the other times.

Well, because I don't think they started from scratch, thats your theory. I think they at the very least must have had prototypes and design docs. In a 5 year project, that's typically the first two years. And regardless of 'getting to alpha' - their target was to get to (at the very least) a playable beta by now. They launched a game that's at 51% negative reviews - and if it hadn't had 'Kerbal' in the title it'd probably be 90% negative. Also in games, often what seems like the last 10% of the work actually takes another 90% of the time. A game that is mismanaged doesn't manage its scope or time well, and that's clearly happened here. In short, yes. For multiple reasons. 1. As stated - doesn't matter what they do in a year if they get cancelled in the meanwhile. 2. An engineer who can work on gameplay features (eg supplies) can work on other gameplay features (eg: fuel flow). Engineers are not so specialized that they work on one system only, ever. That'd be dumb. Similarly, if an engineer works on multiplayer, then they should have been working on the core foundation of the game, and should be able to handle many bugs. If multiplayer isn't ALREADY integrated into the game. Well, they're up feces creek, and the paddle was RUD'd. There's no way they're getting it into the game in any reasonable time frame and without going dark for a long time, like NMS. You don't code a real time physics sim that's meant to work across the network without building it for multiplayer at the start - those two systems HAVE to function together. If you don't believe me, ask a current programmer - I'm not anymore but that doesn't mean I've forgotten everything I knew. 3. Its likely those engineers dropped what they were doing on future features to work on bugs for the last couple of months at least. They won't be 'switched'. They've already been switched. They must have known what a dumpster fire they were launching, and had all hands on deck improving the release. If not - their management is even more clueless than my low estimation of them. Yes - so we agree they should be doing everything possible to improve the stability of the build right now. And I disagree with you on that last one. KSP2 is PD's biggest project - both in terms of dollar cost, with the massive overrun and the need to pay for/start a new studio, and the cost of buying the IP and with the future plans they must have for the IP. They had more than just a sequel in mind. Outer Worlds was a similar scope project, but Obsidian already had it well underway before they brought it to PD - hence why Obsidian kept the IP, which is now Microsofts, Outer Worlds 2 won't be published by PD. Also because of that, the royalties go much more in favor of Obsidian. Moon Studios thing is also similar in scope - but again, Moon Studio has much more of the pie in that case I believe, and also I don't know that one will ever see the light of day. Everything else PD has done is comparatively small potatoes, and they've had no real successes of any scale besides Outer Worlds, which again, is now lost to them and they didn't get that big a piece of the pie anyway - and they've screwed up the DLC for it too. Why do you think the layoffs were focused on Private Division, and not more evenly spread out across Take2? It's because PD has been a money loser for them, and they're trying to tighten the belt.

I'm sorry, you seem like a nice and bright person, less argumentative than most, but in my view anyone who thinks there's a chance that they're not very badly managed is very naive, in my opinion. Even if there are artists or what not that aren't working on bugs - they're not on the critical path. We've been shown assets for ages for the colony game, for instance. I wouldn't doubt that - if it was just a matter of the art being done - the colony game would be playable already. The game's primary problem is with engineering and systems work, and I doubt a single engineer is working on anything except bugs and performance right now. Their sales and reviews are terrible, it's clearly a situation where they're going to be trying to fix that issue before worrying about what's 6 months or a year down the road. I've been on and around projects that were flaming wrecks and there's no long term thinking happening now - especially given that they're trying to hire 6 more engineers. Note that if you see those hires get pulled down without new staff actually showing up, that means the project is 100% kaput. They might not even be wrong - do you think if they don't improve the state of the game in the short term, there even will be a 6 more months for them? I kind of doubt it. Tbh from what I hear through the grapevine, I think all of Private division might be on a knife edge.

That's why I mentioned 'virtually every system and feature in the game has bugs'. You don't have to switch people's specialities in that case - everyone has plenty of work to do in their own features. And there are also almost always low-complexity code bugs that most engineers can track down and handle, or low-complexity asset most artists can - of course you don't have an artist fix code or vice versa, I'm not saying that. That's one reason Nate's list of fixes mostly was not showstoppers though, and had a lot of not-very-important issues - likely the few developers who could untangle the really messy issues are swamped, so the other devs are fixing less key issues No, that part is all KSP2, who knows what else they thought was a good idea, maybe the colonies will be made of jello. But doing parallel bug fixing on one branch while QA tests a different one is standard practice - something even Intercept knows how to do. Probably

That doesn't mean anything of the sort. Nor does it mean what @Peripleis implying either. What this means is that there is a development pipeline. QA is testing things for the release candidate that the developers worked on the previous week or week before that. Developers move on to fixing new bugs that will be part of the next patch. Otherwise you'd have development stalls where the developers can't work while QA tests, and QA can't test while the developers work. This is completely standard software development practice. What it doesn't mean though is that the devs have moved on to work on finishing new features - this would be the case if only a few developers were needed to fix bugs - because of limited bug count or because only certain devs knew how to do the work. In this case, KSP2 being the buggy mess that it is, with issues in virtually every feature and system in the game, its unlikely that anything but a few artists or maybe a designer or two are working on anything but fixing the game.

Hope and hype are powerful drugs I told my boss it was unshippable. My boss told my boss's boss it was in really bad shape. My boss's boss told my boss's boss's boss it needs work. Eventually my boss's^5 boss heard it was awesome, and green lit the ship. That, or they listened to Nate Simpson...

I don't get why they did proc wings but not proc tanks. Seems... schizophrenic. Especially with this game having more fuel types.

Part manager is ok...if it was in addition to part action windows. By itself, it's awful. Part action windows should come back.

Yeah, in the context of HDRP, the things you want it for are kind of orthogonal to the things you care about when render big environments, other than ray tracing. Ray tracing could be fantastic for many things in KSP, but tbh if they hadn't already built clouds, penumbras and shadows with ray tracing, I don't see them doing it now. And it certainly wouldn't improve the key performance problems they're having. Thr more I dig into it, the more HDRP seems like a boondoggle to me. But they may want just one specific feature out of the pipeline. *Shrug*.

It would occur to them, but engineering turnover on that project has been pretty extreme, even if you don't count the star theory mess. The fact they didn't manage to keep their physics programmer or hire a new one - when this is the sort of project physics programmers typically would be extremely excited to work on - seems like a bad litmus test all by itself. It's not uncommon for games to have turnover, but so many senior/lead/tech director programmers coming during just the 2.5 intercept years is pretty telling - on linkedIn 8 out of the 16 people that worked there but stopped are engineering staff, and I know there are a couple of others not listed on linkedIn.

But in this case they kind of have to. Those perf numbers Mortoc posted were abysmal and all related to one area of the code. And he says it can't be optimized further. It's a little shameful that they claim to have pushed PQS to it's limits...but sat around using it with those awful perf numbers Mortoc posted till this late in the day. What else did they spend time on figuring out the rendering for, if not the planets? There's very little other geometry KSP has to care about or optimize around. But at least he's saying it's not that much code .. that's a good thing for the hopefuls - it means it's also not necessarily as big of a rewrite. Nebulous: Fleet Command and Hardspace: Shipbreaker both use it and are space games - but neither are expansive or graphics tour-de-force titles. You can see a full list of steam games using it here: https://steamdb.info/tech/SDK/UnityHDRP/ Whats most concerning to me here is that it seems like a decision you would have wanted to make right at the start. Assets do not have compatible settings. They'll have to go back and touch every asset they've built to look at it with new shaders. https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal@7.3/manual/universalrp-asset.html#:~:text=You cannot%2C however%2C switch between,the render pipelines are incompatible. Overall...it is a weird change to consider when you're having performance issues as it is. Especially when presumably things like atmospheric scattering and cloud tech was written without hdrp in mind and now you have a new lighting model to deal with. Oh well. I doubt we'll see any results from this for months and maybe they'll change their minds in the meanwhile. At the moment though it's giving me star citizen object container streaming vibes though.

Reddit Thread between Mortoc and one of the originators of the CBT algorithm. As with most things, it sounds more complicated than a silver bullet solution to KSP2s perf issues. Will be interesting to see how/when any of this comes about.

I just expected better from the UI. When you have a game go from the absolute first version of a genre, and then move to much bigger budget ver2, that also has examples from a couple other indie games doing similar things to learn from - you expect blanket improvement rather than 2 steps forward one step back. Also a lot of the menu UIs look unfinished and like big wastes of space, as @Moonssays. Hopefully they are unfinished rather than intended. VAB UI is the pretty good to me - as expected since star theory apparently worked on that first. Flight UI is a mess. Nav Ball cluster is ok but way too cluttered. The orientation ball is unnecessary usually and would have been better as an in-scene UI that can be toggled on as needed. Other parts not so good, and I generally echo moons on this. What would have been better - and they had the budget to do this - is to modularize the UI so there was a good UI for key types of flight. Eg: an ascent/desecnt UI. A plane flight UI. An orbital maneuver UI. A docking UI, with key info available. KSP2s UI is missing any way to see most orbital elements, at least KSP1 got that eventually. Hopefully they've made the UI more moddable than KSP1 - but the fact that app bar is the way it is in KSP2 gives me little hope of that.

Hand on heart - obviously, no I think KSP2's are better. Hand on heart to you - is it better enough to be worth running many times slower on a beefy rig though? Its not to me. And mountains from LEO are just one aspect of planetary graphics - the Mun looks a little better in KSP2 at a distance - but way better close up in KSP1 mods. Most planets do. Landed Kerbin looks better in KSP1 mods. All of those perform much better than KSP2 does. I was hoping we'd see something closer to universe sandbox graphics and performance, myself - that doesn't seem like asking for too much since Giant Army (the development studio for US) is 10 people. And they simulated a whole universe with proc planets and all kinds of additional celestial bodies - not a fixed solar system.

Sure. There's some stuff I like. Procedural wings are good. Part recoloring. The sound is miles away better (KSP1 never had a sound guy and used freeware music lol). The VFX is way better than KSP1 (which didn't have a VFX artist) Orthographic view in the VAB. None of those speak to the foundation of the game - they speak to having lots of developers and development time and budget and getting a few new ideas in. And making a really good hire w/Howard Mostrom. And there are lots of things KSP1 did right that they went backward on. If they'd come out with a game that had a solid engine - reasonably performant, physics way better than KSP1 (no noodle rockets for instance) mod ready out of the gate and reasonably bug free, I wouldn't be trashing them even if they dropped the ball on getting any other features done - or even less features, though hard to imagine what even less might be - back to a single planet? But they've done so badly in so many areas given so much time and money - my problem is what this does the the Kerbal franchise. T2 is unlikely to ever do a KSP3 if this thing isn't profitable. This is not a more solid foundation to build mods and other stuff on. Could they fix it? Sure. Maybe. Eventually. But KSP1 never yoinked its physics engine or did a major refactor of that nature- games RARELY do that because you have to go dark for a long time and then rebuild/retune a lot of stuff that was built on top of it. So yeah - I'm critical because I think the wrong publisher and developer took my favorite franchise and mangled it. Sorry if that offends you.

So your theory is now - they failed to do the job building off the codebase of KSP for 3 years. They then lose all their engineers, and their codebase, and with the experience of failing to get the job done in 3 years, a bunch of non-coders with no engineering team decide that 'oh, obviously we'll be able to finish this by 2021'. I realize Hanlon's razor is a thing, but at some point that level of rank 'optimism' by people who are paid, theoretically experienced developers slips into malice just through that much incompetence.

@Periple So there's no geometry on stock KSP1 Kerbin that looks like the nice water-sculpted mountain valleys of KSP2 and I'll grant the artists on KSP2 did a much better job generating realistic terrain. But of course - I only have to show what KSP's engine can do, not the one artist that KSP1 had do Kerbin and which couldn't be changed after without borking everyone's landed craft. So here's RSS's mountains. The lighting feels a little overexposed, I do think KSP2's deferred renderer can do a better job with lighting (at the cost of nuking the framerate), but you can easily get the atmospheric fuzziness down with a quick change to scatterer's settings. Oh, and also? That little133 from the show FPS mod up in the corner? That's my frame rate on my i7 12700H / 3070m laptop.

Gotcha ok. Sorry I get a little confused debating between you and K^2 who seems to believe everything went fine with Stary Theory's engineering. This makes more sense. My apologies. So yes, the one counter-arguement there is then why announce a ship date in 2021. Your counter-arguements to that have seemingly been 'they knew it was a fake date, it was just because (business reasons) that they announced a public fake date so they could string along both investors and the fans. (Please correct me if I'm wrong here about your position) My response to that is 'why wouldn't they just have said 'we have to take longer, we just restarted the game' and then we're at an impasse, because I don't see a good reason for them to do that, and a lot of my distrust of KSP2 stems from their routine willingness to fabricate lies to their audience to make themselves look good in the moment. Once you can believe that Nate et. Co are willing to just outright lie about the development of the game just to look good in the moment - even if its gonna bite them in the butt down the road - you can throw out a lot of what you guys seem to be hopeful about - for instance, that the devs actually were playing a fun game internally, that they were playing a version of multiplayer internally, etc. And very little of the dataminining has shown any working code, afaict. Bits and pieces of tuning files and namespaces, sure, but no swaths of seemingly functional code that just needs to be switched on.

So your theory is that Star Theory managed to build on top of KSP1's code base - without having a single engineer from the Squad team working for them at the time. But that Intercept couldn't work off of Star Theory's code base - because of...? What? You've trapped yourself in a huge logical inconsistency here already with your oft-repeated, never-improved arguements. Even if I granted you that KSP2's production code base was started over - which tbh, doesn't seem to be the case given that visible parts of what was working in their 2019 trailer - particularly the VAB - seem nearly identical to what's in KSP2 right. So I'm granting you a MASSIVE benefit of the doubt here, one that isn't likely the case. But even if that's the case - typically the first 1/3rd to 1/2 of a project is concept and preproduction. Writing design documents, Doing prototypes. Testing what will and won't work. So basically, R&D for what you're going to build. For instance, this is the period of time when Star Theory SHOULD have figured out PQS was insufficient for them - which they didn't do, given today's devblog, or that they even bother to try to figure out. So essentially even if they started coding again in 2020 - they should have had a lot of knowledge on best practices, design work, and assets carried forward from Star Theory to use. Knowledge they either didn't transfer (because the leadership team that came over were bozos who didn't even learn a little about what the Star Theory engineers had figured out) or that they ignored (ditto on being bozos) or that Star Theory's engineers weren't even asked to test (ditto2). All this still points to a bunch of bad project leadership that wasted a lot of time for not very much benefit - and clearly failed to make up for that time with the 'only 3 years' of development that they did.

Then put up some screenshots of KSP2. And I'll see if I can match them with modded KSP1 screenshots that show that KSP1's engine could do just as well, no need to use this magic PQS+ system that does things that were 'impossoble' before. Screenshots of Earth aren't meaningful in this discussion.

Fuzzy blobs are actually more realistically planet-like, when you're looking at one from space. Stock KSP's render is way too clean. So I dunno what you're talking about here. This is stock Kerbin. How is that a 'fuzzy blob'? And what does that have to do with the mountains?

So he's saying we shouldn't take Mortoc statements out of context that PQS + is just a copy of PQS. And then he's supporting his arguments by listing this that have nothing to do with PQS? So... how does that make the situation better, in your mind? That he's not being disingenuous, he's just making a terrible argument. "I didn't copy my history homework from Alice. Look, my math homework is clearly not a copy, I got an answer right that Alice didn't" Ok, if that's what you think is happening, sure. Instead of misrepresentation, its just an attempt at confusion and misdirection. I could buy that. Still is deceitful though. And generally, he's listing things that he's CLAIMING that KSP's terrain system couldn't do then, and I'm saying "No, KSP could do that". So that's also, at the very least, wrong, if not deceitful. I'll go you a step further. I only picked the triplanar mapping because it was easy to show that that was false, just point to Parallax . But his other jargon is wrong too. "it needed to allow our terrain artists to intermix multiple distinct biomes in ways that looked good at all scales" KSP2's biome mixing doesn't do anything that KSP1's does, visually. Argueably its worse. " it needed to support many octaves of detail so that artificial-looking patterns did not emerge at either high or low altitudes" Depending on if he's talking about textures (which have nothing to do with PQS) - KSP can support 'octaves of detail' just fine. Mostly that comes down to the texture sampling techniques used, and mods can change the shaders and how textures are sampled. Literally nothing KSP2 does besides deferred rendering - which doesn't impact planet texture sampling - can't be done in KSP If he's speaking about geometry generation - which would make more sense since he's speaking about PQS+, then the general PQS algorithm lets you decide how much subdivision you want to do - at the cost of performance. And since clearly PQS+'s performance is not giving good results, there's not much arguement to say it outdoes PQS. "it needed to support the addition of topology-defining decals for areas of high detail" This is something the stock game already does. That's how KSP flattens the terrain for things like KSC. And Kerbal Konstructs extends it to do other things "and it required painstaking co-development with our environment artists to give them the tools to bring all of those things together in a way that looked natural and beautiful" This is one I can't say much about. Likely stock KSP and modder tools for KSP terrain painting are not as good as what KSP2 has. But it's unlikely those tools COULDN'T have been written - 'impossible' as he said - just that they weren't. Overall though - his claims that KSP2's PQS+ system does backflips that KSP1's PQS system could not - really fall flat to me. tbh I'm kinda mixed on that. I liked KSP1's mountain heights, as just a challenge and for gameplay variety, something to fly around.. But KSP2's are more realistic for Kerbin's size, and KSP1's sharp, tall mountains are one of the places it looks the worst visually, probably a reason they got flattened some. So visually I'll definitely give that to KSP2.

Happy to. But maybe you should pick a different KSP2 image than I got when I searched up KSP kerbin? Or you can keep the one I picked, your choice, it does show off a key KSP2 feature. Top one is KSP2 naturally for those that might not be able to guess.