Kerbal Space Program 2 Release into Early Access Feb 24th

[The Aziz]

And all that is partially why we're getting KSP2 built from the ground up.

[Nazalassa]

On 11/4/2022 at 10:31 AM, The Aziz said:

If the community finally attempts to do a properly working wiki, there will be a list of parts soon after feb 24.

I'll try to do something

Spoiler

if I get the game :)

Spoiler

I will

[AMA PR0]

I have one question, I searched the forum and never found and answer but was wondering. With Early Access releasing in just a few short months will there be any information on system requirements to run it? I am really excited  to get my hands on the game and want to make sure my PC can run it before release. Just a though keep up the great work Intercept team! 

[t_v]

31 minutes ago, AMA PR0 said:

I have one question, I searched the forum and never found and answer but was wondering. With Early Access releasing in just a few short months will there be any information on system requirements to run it? I am really excited  to get my hands on the game and want to make sure my PC can run it before release. Just a though keep up the great work Intercept team! 

System requirements will probably be posted much closer to the Early Access launch from what I can guess. The main focus seems to be getting good performance and stable code for a portion of the game, so requirements will rapidly change until shortly before launch. 

[Anth]

4 hours ago, Lisias said:

7 hours ago, Anth12 said:

Other than the phase angle bug above and possibly the ejection angle, how hard would these bugs be to fix in the maneuver mode?

These are somewhat complex calculations, and the one that will be on charge on fixing them would need to understand what the code should do, and then check what the code is doing instead. The code part is, indeed, not that hard - the worst part is to find where the problem is, and to do that, the dude would need to know the math needed and also the code.

If this feature was working fine before, and suddenly stopped working, then one way out of the mess is to determine exactly the commit that got it screwed - access to the full history for the source code is, so, mandatory. A first step is to determine the very last public release with the feature working, and then walking up the commits from that point until it get screwed. Then a diff between the screwing commit and the previous one will fatally pinpoint the problem.

Level of difficulty on the first method: hard . But it will probably be the faster one if you get capable workforce. Disclaimer: I'm not, I don't know all the math it's needed.

Level of difficulty on the second, brute force method: trivial. But it will take a lot of man-hours - it's essentially a binary tree search where a node visit is a full compiling and then running the thing and look for the problem. This is what I would do, probably...

Brute Force? The maneuver mode code is already connected to the already existing UI wouldn't take a lot of man hours to find. We aren't rebuilding the entire maneuver mode code to fix a tooltip issue or to change the first year and day from 0 to 1.

4 hours ago, Lisias said:

7 hours ago, Anth12 said:

And how hard would they have been to get right in their initial development stage?

It depends of how many people were working on the project at that time. Do you know the saying "9 pregnant women won't give you a baby a month for 9 months"?

If you had a very few experts on the field, then they will probably get things right (or almost) at first time. The hard time is finding these huge experts on the field, then manage to lure them into working on a small software shop - no to mention having the money to pay the dudes.

There's a reason you don't find NASA engineers working on small Marketing shops, right?  

But let's pretend for a moment that a NASA engineer decided to code KSP in 2012, instead of a crazy Brazilian dude that decided to go the masochist way : as soon as the game starts to get traction and the work starts to pile up beyound the capacity of the initial workforce, fatally new people will get hired to help them. And these people will not be NASA engineers, as these dudes are not easily available on the market. Now things start to get hairy, because the initial dude is not working on the code anymore, he's trying to teach the newcomers about how he had done things. Development slows for some time - what's rarely well received by whom is paying the extra money on the new hirings, they wants results faster.

Probably some of the newcomers would be more experienced coders, but almost surely less experienced Space Engineers - and so, knowing most programmers of nowadays as I do, I'm pretty sure that old crappy code that was working fine were replaced by new, very well written code - but done by a dude that didn't know how to solve the problem himself and, so, will not realise when he/she does a mistake on the algorithm.

(on a side note: I prefer to emphasise solid interfaces than solid code - give me solid interfaces, and the code crappyness is not a problem anymore, it can be replaced anytime without screwing up dependencies!)

Now we have pressure to make things faster, as now the stakeholders are spending more money and they want the investment back as soon as possible (the dreadful "Time to Market" race). You have newcomers with more experience on coding replacing the "crappy code" but without enough knowledge about the problem being solved, and so without being aware of eventual mistakes being done. And new features being shoved on the backlog while the clock ticks.

Do you get the picture? Having something done quickly and right is almost impossible unless you have top notch professionals all the way down. Given how KSP was incepted and how it was developed over time, I think it would be pretty hard to have things right at first. But once the team gets cohesion and motivation, they are able to rework the problems pretty fast after some time - as long they don't get burn on the process.

"Cheap. Fast. Good. Pick two."

Ok thats definitely more complicated than I expected. If it was me personally I would code/run/test, then see the result and then code/run/test again and again until its right. How can someone write some code and just expect it to work without testing it thoroughly? And we aren't talking about something complicated like robotics here. Its just a UI interface.

 

4 hours ago, Lisias said:

7 hours ago, Anth12 said:

And could the spaghetti code of KSP1 be a hindrance?

Yes, but not a fatal one. Usually is easier to isolate bad code under a solid interface, and then develop the new features around the interface. Good Software is pretty much alike good hardware: you don't need to replace your car's transmission if you need to replace the car's brakes, do you?

Spaghetti code becomes a serious problem when people adds new features over it, instead of adding new features around it.

Easier saying than doing, no doubt: but there's a reason good developers are highly paid, right?

Let me tell you a history that I had lived on the days I was working on embedded systems: we were working on a considerably complex product, we were a team of 5 and we have a lot of code from different vendors to stitch together. There were good code but written for a different system, there were absolutely terrible code written for the same system, and there wasn't enough of us to rewrite everything.

Sounds familiar?  

How we managed to survive the mess? By writting wrappers. We defined a framework in which we would develop our product - and this framework, indeed, took a lot of work from all the team to get done right. We took months on it, and we only managed to accomplish that because the Manager had a solid background on development himself and agreed that the solution was solid - but hell, we took a lot of heat due the lack of "results" for a lot of time.

Once the framework got ready, we wrote a Facade around every 3rd party code - essentially shelling code around our interfaces, writing code to convert things when needed. Some CPU were wasted on these conversions, and again some heat because CPU resources are usually limited on embedded systems - but, again, we got lucky because the hardware were over dimensioned for the task and we have some fat to burn.

The only time we got screwed was when the Top Brass, worried about how slow were were developing the thing, decided to "help" by hiring contractors to accelerate the deliveries. It was not totally bad, the knowledge of the contractor effectively helped on some issues - but the dude was being paid by task, not time spent, and so he did things the faster he could - taking shortcuts over our framework and doing direct calls inside the components instead of using our public interfaces.

Guess what? We lost months of development rewriting a good part of the code he wrote, not because the code was bad (some of it was, but if the thing works, then it works!), but because he didn't follow up our interfaces and made calls to things that wasn't meant to be called outside their contexts, completely screwing up the stacks of the threads and halting the whole system.

At the same time, one of my colleagues, besides being a very good electrical engineer, was (frankly) a bad coder. But he did everything by the book, and almost none of his code was flagged with bugs. Hell, I was a way better coder than him, he reached me for help on the programming language now and then - and yet my bugtrack's size was twice of him's.   (he had a better understanding of the hardware than me!!!)

Well, after this wall of text, I think you must get caught the picture: Spaghetti code can be a hindrance or a problem - it's how the team copes with the code that decides which one.

I am talking about a hindrance to fixing the bugs. Not a hindrance to the entire development of the maneuver mode.

 

4 hours ago, Lisias said:

7 hours ago, Anth12 said:

Was this above the skill of the Squad developers?

Well… Let's be careful on this one.

There were capable professionals on the team, no doubt. Some more experienced, some rookies, some nice guys, some sas-moholes, the usual stuff as always. In a way or another there were good things being implemented, we can't say that the all the features were crap - not at all.

IMHO what we had was some critical bugs pilling up without being fixed, to a point in which all the very good stuff being added could not be appreciated by the users. Why these bugs pilled up must be the key to answer your question.

However, I don't know the facts I need to know to give you a answer for it. What I know is that it's possible to have a terribly incompetent team formed by very competent individuals - as well to have an incredibly productive team formed by rookies. You can save or doom a team by adding or removing a single dude...

Most of the time, management is the key for the success of a Team, but it's premature (and probably unfair) to just blame management for all the problems - at least, without more information. And I, definitively, don't have much...

The KSP2 early access video appears to have most of the original developers and ones I didn't even know of until I looked at the KSP1 credits. If their skill wasn't at an acceptable level then Intercept Games wouldn't have taken them all on. That's why it felt more like a management issue.

 

4 hours ago, Lisias said:

7 hours ago, Anth12 said:

To clarify. The answer to the skill level question is NO. Most likely what happened is that they were working on Breaking Ground at the same time and they somehow forgot to thoroughly test the maneuver mode in amongst the mess of developing and testing the robotic parts.

Given the results we have nowadays, it's clear that the Team had failed on delivering the results expected from them. Lack of skill can be one reason for that, but my guess is that it was not the only one - perhaps not even the main reason.

If I would make a bet, I would bet that over-confidence played a bigger role than the lack of skills. Some features should not had been allowed to be published at the state they were. Hell, some KSP releases had config files with merging problems (to the point I had written a lint tool for the config files) - at least this one is not about skills, I can tell you.

Over confidence? That cant exist. If I was working on KSP1 and the free updates. I would be cringing on every update. My self confidence would be plummeting on every stupid bug that popped up when it shouldn't have been there at all. Something else is going on here.

How do I force the quotes to collapse when viewed by others?

My response is taking up too much room.

Edited November 9, 2022 by Anth12

[Lisias]

4 hours ago, Anth12 said:

Brute Force? The maneuver mode code is already connected to the already existing UI wouldn't take a lot of man hours to find. We aren't rebuilding the entire maneuver mode code to fix a tooltip issue or to change the first year and day from 0 to 1.

But it would be the approach I would do, because I don't know all the math I need to know to identify the problem by eye-balling, neither know the code enough to know where to eye-ball the damned thing!

You see, the point is that you don't need highly skilled professionals to detect (and sometimes fix) some bugs (even on complex systems). You can replace skills with raw power (and some extra time).

A highly skilled professional will always be more efficient, no doubt. But not necessarily the cheaper choice.

 

4 hours ago, Anth12 said:

Ok thats definitely more complicated than I expected. If it was me personally I would code/run/test, then see the result and then code/run/test again and again until its right. How can someone write some code and just expect it to work without testing it thoroughly? And we aren't talking about something complicated like robotics here. Its just a UI interface

Working with people is complicated. Working alone is, almost always, way "easier" - but most of the tasks of nowadays development are too big to be handled by a single dude, and so we end up working on teams, where everything is more complicated.

One of the worst problems on working on teams bigger than 3 or 4 dudes is the Chain of Responsibility. When the team became bigger enough to prevent that every dude is able to know and understand what the others are doing, you have an opportunity to hide problems or let others to be blamed for problems you had caused.

This leads to a growing bugtrack that ends up eating all the time available, stealing man-hours from the new features - and the money are on the new-features. Buggy code was already sold (it was the bugs were discovered at first place), so management rarely see them as a way to expand the incoming. New features, on the other hand, is how management is able to sell more copies of the product.

And I hate to tell you: they are not exactly wrong. Check the Steam Charts for the peaks of users online, and you will find that most of the time, there was a new KSP release at that week. We don't have access to the sells chart (obviously), but it's reasonable to assume that these peaks on users online has a relation to more KSP copies being sold.

And so we reach the dreadful Bug Priorization: since there's no time to fix the bugs and also deliver the new release, someone gives a priority on each bug, and so the team scrambles to fix the bugs ordered by priority. If someone gives a really annoying bug a low priority, it will be essentially not fixed until the end of the project when no new features are left to be added. But since at this point the sellings are usually stalling, there will be no money left for developers, and so we have a bug that will never be fixed.

Bug Priorization is a Lost Art, I can tell you. On complex systems it's usual que a very underestimated bug ends up being the root cause of a lot of higher profile ones - to the point that fixing that Kraken damned small bug would fix by side effect a lot of nasty, user's SAS bitting ones. However, it's pretty rare to have people skilled and experienced enough available to do such priorization (not to mention that the dude must have a good knowledge about the whole code to identify such relationships).

 

4 hours ago, Anth12 said:

I am talking about a hindrance to fixing the bugs. Not a hindrance to the entire development of the maneuver mode.

They are essentially the same thing, see my previous paragraph. Companies don't write code to brag about their coding skills, they write code to earn money.

If they find that they can earn money writing bad code and walk, then bad code is what they will write.

 

4 hours ago, Anth12 said:

The KSP2 early access video appears to have most of the original developers and ones I didn't even know of until I looked at the KSP1 credits. If their skill wasn't at an acceptable level then Intercept Games wouldn't have taken them all on. That's why it felt more like a management issue.

I'm prone to agree with you on a higher level that you think. BUT… "management" is a too broad concept, we have low, middle and high management, and the problem can be happening on any of these levels. It's the reason I'm cautious on talking about.

However… I had learnt something on my PMI times (yeah, I had tried my way on the Dark Side of the Force - got burnt, by the way, Darth Vader level of burnt): "Good Managers don't work for Bad Managers, but Bad Managers can end up working for Good Managers - for some time".

What's probably the explanation for the other saying I learnt: "A players hire A players; B players hire C players". What's also explains why you rarely find A players on big corporations - people on big corps don't hire people that can overshadow them, it's not on their best interest.

 

4 hours ago, Anth12 said:

Over confidence? That cant exist. If I was working on KSP1 and the free updates. I would be cringing on every update. My self confidence would be plummeting on every stupid bug that popped up when it shouldn't have been there at all. Something else is going on here.

You care about the product. Most people only care about getting paid. With as little effort as possible, by the way.

Spoiler

I remember being chewed up by my direct (soon to be ex) manager (yeah, he was replaced) once due my aggressive posture on defending the best way to develop the product (that were causing some management problems and increasing his workload).

He said "It's not your product, you don't own it."

I replied "But the product has my name on it, and I own my name." — what was a less-than-confortable way to apply what I had learnt on that PMI lessons, believe me…

 

4 hours ago, Anth12 said:

How do I force the quotes to collapse when viewed by others?

My response is taking up too much room.

Use a Spoiler (the Eye icon on the toolbar, below the "Font"). It's what I did on my previous paragraph!

On mobiles, this button is usually hidden. Switch the phone into landscape position (wider than taller), and the extra space will allow it to be shown.

Edited November 10, 2022 by Lisias
tyops, tyops, tyops everywehre!!!

[Anth]

@Lisias So looking at everything you have said basically Take Two had no choice but to do a complete reset giving KSP2 to another company.

Then they possibly looked at Squad's way of doing things to see if their employees would be capable under new management. Which they are or they never would have ended up working on KSP2.

Its good that they are working on KSP2 so they can give feedback to keep KSP2 feeling KSP like. Also they might know issues we have no idea about with KSP1 so as to counter the same happening in KSP2.

1 hour ago, Lisias said:

I remember being chewed up by my direct (soon to be ex) manager (yeah, he was replaced) once due my aggressive posture on defending the best way to develop the product (that were causing some management problems and increasing his workload).

Well it was lucky you kept your job. I have seen people fired for doing what you did even if the proposal of changes would have increased production.

 

 

[playedspaceinvadersdayone]

Take my money already!

[panarchist]

On 10/28/2022 at 3:41 PM, Fullmetal Analyst said:

maybe we expected more than a paid alpha test after 6 years of dev time...

i mean if they valued the communities input on their development they wouldnt have been so secretive about it the whole time, they obviously just want money, else they would let us play the game for free until its finished, usually you pay people for doing QA for you, not the other way around...

Late to the party here, but - they're not asking the community to do QA - QA is what you do prior to the release when the feature set is established and the coding and internal smoke testing is done. What they're asking for is assisting in requirements gathering and User Acceptance Testing. The feature set isn't settled, the scope is defined, but that's about it. You don't pay people for doing UAT - the customer does UAT for free to ensure that the software does what they want it to do, i.e. meets the requirements. What Intercept/Private Division is offering/asking for is for the community to define the requirements (within limits) and tell them if what they've coded implements those features the way we want them to work.

Also, how do you figure 6 years? KSP2 wasn't announced until August 2019 - that's 3 years ago. 

[PDCWolf]

On 11/9/2022 at 2:26 AM, Meecrob said:

I get what you are saying. What I am saying is that Take Two is asking for ROI before making sure the product is good...evidenced by the launcher and no bugfixes other than tutorials. Tutorials are to onboard new players..who haven't encountered the bugs yet. It seems to me that if you force something, it does not come out the best.

Edit: as I said before, it sounds like deadline pressure to me...and the deadline is up to take two...who just had a loss this quarter...

The product's been 3 years in the oven longer than originally planned, and it's coming out with half the features missing, into the only market that allows messy launches and lackluster products. Early Access at this point is just a hidden fourth delay, with the politeness of at least letting the customers spend some money on a promise of a game before we all age and forget about it. It is definitely ROI related pressure.

On 11/9/2022 at 2:16 PM, The Aziz said:

And all that is partially why we're getting KSP2 built from the ground up.

I thought that was because T2 bought the rights to a franchise with intent of exploiting them, not out of the goodness of their hearts to create an allegedly bugless, well built platform.

If anything, the still broken DLC and the launcher surprise is proof of T2 more than likely wanting another live-service or DLC/microtransaction-able cash cow. I'm not against a company wanting to make money, but if you think T2 is gonna do a better job at bugfixing than SQUAD... yeah no, we have proof that this is definitely not the case. This is not me defending SQUAD either, KSP1 still has bugs carried from very old versions, due to their spaghetti code and complete disregard for anything but rushing a release, BUT, they had some internal passion that PD just can't, on account of being a hired studio and having to do what T2 tells them (like releasing a long overdue product that's still barely half done into EA just to get some quick cash)

 

[Ashandalar]

18 hours ago, PDCWolf said:

if you think T2 is gonna do a better job at bugfixing than SQUAD... yeah no, we have proof that this is definitely not the case

Reminder that the game is being developed by Intercept Games, who have many (former?) SQUAD members on staff, not by some other beleaguered T2 studio you might point to as an example. Different studios, even if they ultimately have the same owner, are not interchangeable. I make no claims about how buggy or bug-free KSP2 will be, because I have no idea, but neither do you.

[PDCWolf]

11 minutes ago, Ashandalar said:

Reminder that the game is being developed by Intercept Games, who have many (former?) SQUAD members on staff, not by some other beleaguered T2 studio you might point to as an example. Different studios, even if they ultimately have the same owner, are not interchangeable. I make no claims about how buggy or bug-free KSP2 will be, because I have no idea, but neither do you.

My point came from the idea that SQUAD guys had a passion project, and as much passion as PD might have, T2 has the reins, which is the most probable reason we're seeing another stealth delay with EA after 3 delays already. T2 needs money, needs it now, and it doesn't matter how many super passionate people including squad employees are in PD, they're releasing now. And when the time comes, that they have to choose between fixing bugs and developing some new feature to attract sales again, they will follow what T2 tells them, which is probably the later.

[pandaman]

On 10/30/2022 at 2:47 PM, Lisias said:

 

"Hey, buy an unfinished product, help us to debug and polish it with your scarce free time and save 10 bucks after a year of work"...

Nobody is insisting that you report bugs.  If you just want to play it then do so.

You could even just buy it in early access, not look at it until full release,  then download v1.0 and you cunningly saved yourself $10.

 

[Kerbart]

On 11/9/2022 at 4:34 PM, Anth12 said:

Brute Force? The maneuver mode code is already connected to the already existing UI wouldn't take a lot of man hours to find. We aren't rebuilding the entire maneuver mode code to fix a tooltip issue or to change the first year and day from 0 to 1.stupid bug that popped up when it shouldn't have been there at all. Something else is going on here.

The maneuver node works in two directions; it’s used to show the values as well as update those values. So the conversion needs to work in both directions. And is it really as simple as adding +1? Is the problem the same for the 24h clock as for the Kerbin 6h clock?

What seems like a simple problem will likely need thorough review and testing; somebody merely jumping in and adding “+1” to the code is likely going to result in just more bugs.

Not intended to burn you down, but simply to mention that what seems simple from the outside is not always that simple to fix.

[Anth]

2 hours ago, Kerbart said:

The maneuver node works in two directions; it’s used to show the values as well as update those values. So the conversion needs to work in both directions. And is it really as simple as adding +1? Is the problem the same for the 24h clock as for the Kerbin 6h clock?

What seems like a simple problem will likely need thorough review and testing; somebody merely jumping in and adding “+1” to the code is likely going to result in just more bugs.

Thorough testing is what should have happened for the maneuver mode in the first place. For them to get the phase angle blatantly wrong means they didn't test it at all. I tested it with Kerbal Engineer. But perhaps you are right. Its a little worrying that code would not be able to be fixed with a +1 though.

2 hours ago, Kerbart said:

Not intended to burn you down, but simply to mention that what seems simple from the outside is not always that simple to fix.

Maybe.

[Majorjim!]

I don’t know how to feel about this.. I’m happy to see the game getting a release soon but I am not over mun about the method of release.. the main thing that stopped my playing KSP was the updates that break craft files and it seems this will be the KSP2 experience too.. I think I will have to adjust my play style and just enjoy exploring rather than putting months into complex craft. Actually that sounds super fun! 
Good luck with the release and here’s to KSP2 and the promise it holds! 

[Astroneer08]

Yay! So exited!

[Anth]

7 hours ago, Majorjim! said:

I don’t know how to feel about this.. I’m happy to see the game getting a release soon but I am not over mun about the method of release.. the main thing that stopped my playing KSP was the updates that break craft files and it seems this will be the KSP2 experience too.. I think I will have to adjust my play style and just enjoy exploring rather than putting months into complex craft. Actually that sounds super fun! 
Good luck with the release and here’s to KSP2 and the promise it holds! 

Yeah that would a concern. What I would really like to do is progress far enough in my KSP2 save that its ready for the next steps in the roadmap rather than have to start from scratch in my save.

It isn't like everything after early access are going to be built from the ground up though. They appear to have been working on all features quite a bit. So we might be lucky that crafts will stay compatible with all updates.

[Gurkonier]

One of the many reason i continued playing KSP was the constant stream of new updates.

It was exciting to test new features and i think i will enjoy playing along the development process and seeing, how KSP 2 evolves and becomes more complete.
But i can also see, why other people see it differently. For example mod development will be as hard, as it was before KSP had it's final (major) release.

[sweatbox]

A part of me is slightly concerned that this game is in development hell. I've been very optimistic and eager to explore the new game, however considering the game was originally supposed to "release" 3 years ago, and only now are they confident enough to release what essentially will be the same game as KSP 1 with the updated engine and tools, I can't help but feel wary of the progress the development team is making.

Of course I understand the difficulties that come with developing games, but to have only the default system and none of the landmark features that this game is supposed to have after what will end up being around 4 years of development is worrying. 

I'm sure the team is giving it their all but can't shake the feeling that we might be in for a long wait for the new features. 

[darthgently]

<face palm>

[Wyzard]

21 hours ago, sweatbox said:

Of course I understand the difficulties that come with developing games, but to have only the default system and none of the landmark features that this game is supposed to have after what will end up being around 4 years of development is worrying. 

I'm sure the team is giving it their all but can't shake the feeling that we might be in for a long wait for the new features. 

Well, all of the features are in progress already.  Multiplayer, for example, is the last item in the "roadmap", but IIRC they've talked about how they're already testing with it internally.  I expect that the foundations for all this stuff is already in place, and the steps in the roadmap are just getting each feature finished and "polished" enough to enable for users — not starting on each feature from the beginning.

Also, remember that KSP1 was in Steam early access for about two years, and early versions could be bought directly from Squad for nearly two years before it even became available (as EA) on Steam.  This doesn't seem drastically different.

[PopinFRESH]

On 11/17/2022 at 10:10 AM, Wyzard said:

On 11/16/2022 at 12:15 PM, sweatbox said:

A part of me is slightly concerned that this game is in development hell. I've been very optimistic and eager to explore the new game, however considering the game was originally supposed to "release" 3 years ago, and only now are they confident enough to release what essentially will be the same game as KSP 1 with the updated engine and tools, I can't help but feel wary of the progress the development team is making.

Of course I understand the difficulties that come with developing games, but to have only the default system and none of the landmark features that this game is supposed to have after what will end up being around 4 years of development is worrying. 

I'm sure the team is giving it their all but can't shake the feeling that we might be in for a long wait for the new features. 

Well, all of the features are in progress already.  Multiplayer, for example, is the last item in the "roadmap", but IIRC they've talked about how they're already testing with it internally.  I expect that the foundations for all this stuff is already in place, and the steps in the roadmap are just getting each feature finished and "polished" enough to enable for users — not starting on each feature from the beginning.

Also, remember that KSP1 was in Steam early access for about two years, and early versions could be bought directly from Squad for nearly two years before it even became available (as EA) on Steam.  This doesn't seem drastically different.

Given the context of the story Nate tells about the KSP2 contract, when T2 acquired the KSP IP, and when Nate became creative director at Uber Entertainment; the development of KSP2 likely started pre-production in late 2017. When it launches in EA next year it will be about 5 years of development, and like sweatbox this announcement gives me substantial pause in regards to the state of the game. What happened with KSP1 is irrelevant in this discussion in my opinion. The context of the previous communications over the past 3 years including the last delay announcement's phrasing appeared to set an expectation of delivering a feature complete game at launch. This announcement not only is a radical departure from that tone, it also lacks any indication as to the state of the roadmap features or any target/expectation of cadence for when they will be added.

Also the "just getting each feature finished and "polished" enough to enable for users — not starting on each feature from the beginning." when in context to the stated rational for early access just doesn't pass the sniff test. If you're at the point of "polishing" those features then the "getting users feedback on the core experience" is meaningless because it is not going to substantially change a nearly complete feature that is "just getting each feature finished and "polished" enough to enable for users".

I've also been very optimistic and looked forward to when KSP2 would launch. This announcement however seems like it came from a completely different direction when compared to the last 3 years of communications, and as such it gives me the feeling that Private Division had kicked the can as far down the road as they could and Take Two ran thin on patience and gave Private Division an ultimatum to either start generating revenue or cancel the project. I will check it out when it hits early access launch like I've said before, however, given the context of things I will very likely refund it and wait until there is at least most of the expected features and an established cadence of how quickly they are delivering the features on the roadmap.

Edited November 21, 2022 by PopinFRESH

[Vl3d]

You see the mess created in people's minds by the lack of communication?

Just repeating the same old information from 2019-2020 over and over again and just presenting the KSP1 + Interstellar mods feature set without coming through with the real answers and solutions. It just created a tense environment on the forums where every argument is dismissed as speculation, where there are no promises made because of fear of not delivering. Not to mention the "may or may not exist" aspect of the internal betting board in the Intercept offices.

What's the actual point of Early Access if everything is already decided upon or implemented? Bugfixing. So then if we strongly disagree with a way a feature is implemented, when can we give our feedback? Only during EA? Because I feel there's been a lot of interesting conversations and I don't see how they have informed the decision making process of the dev team.

How can the game ask for community feedback only during Early Access if in reality the feedback had been continuous for years without anyone at Intercept talking about the actual implementation of the systems? Example: how will the delivery routes system be implemented? Will we see automated flights and driving or will it be just a resource bump from time to time? Such a fundamental unanswered question.

[Anth]

9 minutes ago, Vl3d said:

What's the actual point of Early Access if everything is already decided upon or implemented?

We will find out soon enough if what we are saying has any major affect on features that seem to be completely fleshed out.

I hope it ends up feeling a bit like  a community effort than just giving blind feedback to Intercept Games.