Skorj

The smart corporate move at this point is to quietly remove the roadmap section from the Steam page. I suspect Vlonald is right in that they're currently busy seeing what they have, but my guess is best case we get colonies finished up. With Colonies KSP2 has new content that KSP1 doesn't, and I could see htem thinking that justifies the current price. Perhaps they're waiting on that assessment to figure out where to cut off the roadmap.

Back at ya. I thought Kerbin looked better, and Duna looked OK, but most of the rest of the planets and moons just seemed off to me. The Mun as I said looked like a 1960s live TV broadcast, way overlit (like the lack of dynamic range in those TV cameras), and awkwardly photorealistic in a game where that wasn't the usual art choice. It was like in South Park where the pictures on the walls were actual photographs looking very odd in a cartoon. The rest seems to diverge from the "slightly cartoony" look KSP2 seemed to be going for in either direction -- either again going for photorealistic, or the other way into oversaturated colors -- with too much detail at 30+ km. While the landscapes in KSP1 were overly bland and low-detail up close (to the point of being the game's main visual weakness IMO), I love it's "slightly realistic" art style from orbit. Eh, it's all subjective though. (Other then the stock KSP1 landscapes up close, which are objectively low-detail.)

I'm making a note here: huge success. I suppose it's hard to overstate your satisfaction. Other than Kerbin, I thought the terrain just looked bad compared to KSP1. Take e.g the Mun: in KSP1 it looked like a 3D body I was orbiting, or approaching for landing. From the ground it was obviously an older game, but I love older games so, yeah. In KSP2 the Mun looked like an over-saturated photo of the moon pasted awkwardly into the display. It's like they were trying to re-create watching the moon live on the broadcast feed on a 1960s TV. I found it immersion-breaking. I found the UI cluttered and just bad, The font was unreadable. In KSP1 I also had all the information I needed clustered together where I could see it at a glance. Sure, that was due to KER (configured how I liked it), but it was much better than stock KSP2. And everything was in large, easily readable fonts. As far as life support - there was simply no way that was ever going to be stock, and I'm baffled why people thought it might be. Nate made it clear from the start that KSP2 would be more accessible to the average gamer than KSP1. He emphasized that from his very first video talking about KSP2 onwards. KSP1 was already too hard for most people, they weren't going to add features that made it harder. After all, KSP2 was never going to be made to provide additional hardcore content for we turbo-nerds with thousands of hours in the game. You don't make a game for an audience of dozens of people.

Ah, I had wondered how anyone could like the new UI. That actually makes sense. Are you talking planes or rockets? I so rarely look at the navball when landing a rocket, and have all my KER displays at the top of the screen around the altitude.

I don't think they can. The problem is, both the Steam store page and Nate's marketing communication treated the roadmap as a promise of future content. For example: This is presented as the description of the game, not some aside about "things we'd like to have one day, if it works out" on a dev blog post. So if they announce that feature development has stopped, they could be at risk in countries with strong consumer protection laws. If they announce any specifics about future feature work, they just make the problem worse. If they just say nothing concrete (just some occasional ambiguous corpo-speak) and wait long enough, then no one will care any more and the game can "softly and suddenly vanish away".

In terms of "EA accountability", there is a player-initiated review process already for games that are broken, malware, or a legal liability for Steam, but the items you can flag a game for aren't the sort of problems we're talking about here, I think, although I did flag KSP2 for its registry spam. There are probably 1000 EA games released each day on Steam now, given it was over 100 when EA was new. Human EA oversight would be a bit challenging. For sure I prefer a store with minimal oversight to one policed by insane AI bots the way Google does their stuff. Any system that could possibly result in a game being removed without a clear statement of the reason, what rule was violated, how it was violated, and an appeals process involving actual humans who actually respond (unlike, say, the VAC ban process) would be worse than what we have now. Player-complaint based review leads to a dark place, as we should all know by now. But perhaps Steam could review the store page for EA games above a certain revenue threshold, and at least ensure the text of the page was rules-compliant. That at least could be done fairly with no involvement in gamer drama.

I'm far more cynical about corporate decision making, and don't believe such an individual exists. I believe the entire corporate decision making process for recent past, present, and future was: "Bring up the spreadsheet for the PD games. OK, lets cut those 3, close them out. What's next on the agenda?"

You skipped over the actual rules. In particular: 2. Do not make specific promises about future events. For example, there is no way you can know exactly when the game will be finished, that the game will be finished, or that planned future additions will definitely happen. Do not ask your customers to bet on the future of your game. Customers should be buying your game based on its current state, not on promises of a future that may or may not be realized. Almost no EA games have their roadmap on the Steam platform. You don't want it as part of your sales materials, because in some countries it can be considered a promise when it's part of the description of the product.

Very cool link, thanks! Perhaps we have a different baseline for "hard", when it comes to software. For sure, I've done more with less, but that's professional software guys and not game devs, so maybe you've the better baseline.

You just need to add your own game-appropriate physics engine to Unreal (or whatever) for orbits. Doing that entirely from scratch would indeed be hard. Fortunately, real people have solved those problems for real spaceflight, and much of the work is published and easily available, Want to simulate orbits in a way that is accurate to double-precision floating point, and takes only a few nanoseconds to compute? Not only is there a paper telling you how, there are multiple competing papers trying to one-up each other and optimize even further. It's not easy in the sens of "I could do it in a week", but it's easy in the sense of "a small team could do it in 6 months". So, too big for Felipe working by himself evenings and weekends while working full time for a marketing company called Squad, but it shouldn't have been an obstacle for a well-funded team.

The biggest problem IMO was that they put their roadmap on the store page. The promises for what would come in 1.0 were "on the box", so to speak. That's against the EA rules, and for good reason. Had the release just been KSP1 without the bugs, I would have paid $50 for it despite all the new content being a future promise. But it wasn't, and I think a lot of people justified the price tag because of the promises on the store page. If the game is officially put into "support mode", there could be legal trouble in the EU because of this, which may be the reason we're not getting an official announcement. There's a reason most EA games have the sense to leave their roadmap off the Steam platform. It shouldn't be part of the sales material for the game. The game needs to stand on what it has today for today's price.

I believe the whole roadmap was supposed to be done in 3 years of dev time - plenty of time for a team this big. After 6 years they had not even step 1. The problem wasn't doing the foundation first, it was moving at 1/10th speed. It's not like they planned to ship with no new content, they didn't even plan of an EA release, it's just that's all they had when Take2 ran out of patience. Heck, I think the game could have been successful without anything new on EA release. Had it been a perfectly bug-free KSP1 with modern graphics and mod support, modders would have been all over it with tons of content, and new content from the dev team would have been gravy. But yeah, the fact they apparently had to re-do anything to add the planned roadmap features is just a terrible sign. Bugs and performance issue aside, what on earth were they doing all those years?

WARN notices are not ambiguous (which is the point of the law). The WARN notice is for an office closure and the layoff of 70 people, which is about the size of the IG team. So, some specific individuals at IG might be given relocation offers or some other way to move within PD, but almost everyone is gone. Mass layoffs are almost never done across multiple days. Everyone knows on the same day. However, sometimes a company doesn't have their act together, and that day lags a bit from the public discovering the layoff (or has a panic layoff, then another round a few weeks later, but that's not this case) . Since a few ex-employees have made their layoff public, we know it's done. Lack of a public announcement to clarify the situation to the customers is a baffling absence. If there was a future for the game, we likely would have heard by now. I'd assume that we'll get the minimum of support work (bugfixes) needed for EU legal compliance and that's it. If they really do have a plan for future feature work, the lack of communication has already doomed that plan, as the recent Steam reviews are now Overwhelmingly Negative.

Sorry, that announcement was from the week before the studio closure. I expect the support team at PD will push those changes out eventually, since they seemed almost ready, but that may be the last we get.

The logical first step for KSP2 development was to re-write the core of KSP1, replacing the fundamental design mistakes in the physics engine with something that would be robust and scale to large craft. Nate even said they had done that as the starting point, back in 2019 or so. Once that is solid you start adding new content. It's clear now they didn't even finish the first step. My personal theory is that Nate was telling the truth at the time: ST built a solid foundation for KSP2, that IP was lost with the shuffle to IG, and the talent was no longer there to re-create it. But maybe that's overly optimistic of me and they simply never finished the first small project in 7 years of work.

The WARN Act notification went up at the beginning of the business week. The end of that week has come and gone with no real communication from the publisher, beyond a content-free "still supporting it" tweet. Nothing acknowledging the closure of IG and clarifying the future of the game. A week is far beyond the usual corporate caution in carefully wording an announcement and running it by legal; we're now in the realm of just being rude to the fans. What on Earth is going on over there? Heck, no one has even removed the future promises from the Steam store page, which is just asking for legal trouble in the EU. Steam recent reviews are now "Overwhelmingly Negative" due to fans assuming the worst, so a press release about the situation could only have made things better. Sad times when the corporate overlord can't even pretend to care.

I don't think I've liked a single game he's made, but I'd still likely give a proper space sim a try. If they're really constructing a full engine from scratch, the project has already failed (I think in the past 20 years only Factorio has managed both an engine and a good game).. But more likely they're building a physics engine for orbits on top of an existing game engine, which is the obvious way to go.

To me, the failure is even more fundamental. Since about 20 years ago, the firm cultural expectation was "you don't check in/merge to find out if it works, you check in/merge because you know (within reason) it works". If you merged in a change with an easy-to-find bug, your change would get reverted and you'd have an unhappy conversation with your manager. Test automation was a means to that end, but the burden was on you regardless. QA (if it existed) only happened after that, to find subtle hard-to-find bugs. I almost have to go back to the previous century to remember a time when it was OK to check in code that broke anything that affected other people, and even that was only early in a release cycle.

Bit of advice to anyone in the software industry from an old head: it's on you to be financially responsible with the sure and certain knowledge that you will be laid off multiple times in your career. No, I didn't do that before I was 30 either, but a wise man learns from the mistakes of others. Yes, it sucks, but it's a well-paying job you get to do indoors with no heavy lifting, and I have no regrets about my career choice. More advice to anyone who will listen: you generally benefit greatly from being willing to relocate to follow the hot hiring locations for good dev jobs, as that changes once or twice a decade. If you're in some place that "used to be" good for dev jobs, there's a real chance it's not coming back. Devs in one city might all be complaining about how hard it is to find any job at all, while teams in another city are desperate to hire anyone. There are good reasons why someone can't move (kids in school, spouse with a better job, etc), but don't let simple fear of change hold you back. I saw several office closures over my career, Only in one case were the junior devs not doing a good job. All the rest were either "turns out the product didn't sell well, end of company" or "senior management at a remote office got too arrogant with their demands, and corporate decided it was easier to close the office than put up with them". In every case senior leadership had make critical mistakes that doomed everyone, but it was rarely an indication of the skill of the junior devs. On the flipside, we always looked at hiring junior devs who were affected by such closures as a great opportunity to find talent, not a black mark against the devs.

I don't imagine there was any sort of competition. Rather, I'd say the art people delivered on their end, while the code people ... didn't.

I don't think they'd need to finish the game for a console release, just colonies would be enough as that's something KSP1 doesn't have. IMO the blocker is crash bugs, as consoles have actual standards when it comes to crash bugs (if little else), and it's not like the Sonic3D secret level select trick is going to work for them. I have a suspicion the long-standing major bugs in KSP2 aren't actually all that difficult to fix, just needs a different team to fix them, but obviously I'm just guessing.

No, no. In the VAB you set the docking port as "this specific part is the part that any other ship will use as the target when selecting this ship as the target". Unlike today where from ship A you select a part on ship B, instead the "target part" becomes just a property of a ship, like the root part or control-from-here part. You'd only need an action of any kind if you wanted to keep changing it around between ports. Given the bug patch release cycle, it looks like they probably did have one ready to go, with the fixes Nate noted in his last post. Color me skeptical that those fixes actually work, but I wouldn't be surprised if someone at PD pushed them out soon. After that, though. yeah. I don't think there will ever be any more feature work, just bugfixes, unless (A) colonies are much closer to done than I imagine, and (B) T2 thinks a console release will make a lot of money.

Yeah, it was clear to me from my 90 minutes before refunding that the team didn't know any sort of modern best practices. With UI examples, you can at least make a slight excuse that UI test automation is hard (especially early on when the UI is constantly being changed). But the bugs in the maneuver node? The simple fact that maneuver node bugs made it into the internal daily build, let alone any sort of release candidate, said it all. That's where you start, before you even have a second planet or a VAB or anything. You get fuel burn and maneuver planning working, and you write very robust test automation around it so it can never regress. Both because it's the core mechanic of the whole game, and because it's so easy to write tests for. The fact that there were any easily-found game breaking bugs, and the team just lived with them? I can't even. I can't even begin to even.

I never felt the need to build Star Destroyers or other 1000-part ships. I really like KSP1 as a mission-based rocket sim. I spent endless hours making reusable boosters with which I could do a re-entry burn from orbit and land hands-off at the KSC. Buggy and crashy as it is, I still find it fun. I think most people who post on this forum would have loved a "KSP1 without the bugs" before any of the new stuff in KSP2, but we're a pretty small niche. Still, does anyone think that "KSP1 without the bugs" would have gone worse than what we actually got?

That's the software development industry, though. I understand it coming as a shock the first time someone gets ambushed by a layoff. In part, that's on us senior people for not communicating it well to the junior people on the team, as part of mentoring about the industry as a whole. I think I failed in that way. But software development is simply not an industry in which you can expect continuous employment. We have it better than actors or construction workers for sure, jobs can last years at a time. While I believe anyone in any job should try to have 6 months living expenses saved up for when things go bad, that's doubly true for dev work. You will spend months unemployed, so be ready either with savings or another job to fall back on. I used to work with a guy would work the office job during the day and bartend at night. I though that was silly at the time. How wrong I was; he had it figured out.