Kerbal Space Program 2 Release into Early Access Feb 24th

[thejoker1432]

After reading a couple of comments here, I am very surprised at how surprised people are about the price and confused about what an EA is

I dont know if many here just only play KSP and thats it but 60€/$ is the standard price for a non-indie game since I guess 8 years or so? And 50€ for the EA seems reasonable as you get the features step by step AND they cant just make a 25€ EA since everyone would buy that and noone would pay the later 1.0 full price tag of 60€

 

Secondly: EA is not a separate game or program. Its an early version of the game that gets updated over time until it is finished or released (and post release support still happens). Therefore you are not really paying to playtest. You are paying for the game but its not done yet. You can pay and not play or pay and play but not give any feedback. Noone cares

 

Lastly my main thoughts are that I hope the KSP2 foundation is performance wise solid to support larger vehicles, less physica clipping like EVA wheels on rover construction and overall a less janky experience. All the other features are great but performance and polish to me is the most importan. In the end its not fund to build colonies or travel between stars runnings at 5fps and blowing up every 3 minutes

I really hope time between updates wont be too long. I guess it might be 6 months for each but who knows

[fragtzack]

On 10/21/2022 at 7:03 AM, Intercept Games said:

Most importantly, we want players to play for thousands of hours

Yeah, throw away our real life and dedicate life to Kerbol. 3000+ hours in KSP1 and you want more from me?   <cry>

[Jacob Kerman]

On 11/4/2022 at 1:30 PM, t_v said:

If you want to look at the suggestions, the sub-forum is accessible from the main page under the KSP 2 section. I’ll link it here too:

https://forum.kerbalspaceprogram.com/index.php?/forum/112-ksp-2-suggestions-development-discussion/
 

If you want to suggest some things, you can start your own thread in that sub-forum. Alternatively, there are a few threads for small suggestions that don’t merit full threads. I’ll link one here:

I hope this helps, and welcome to the forums!

Thank you the help and good wishes! Have a wonderful day!

[The Aziz]

13 hours ago, thejoker1432 said:

they cant just make a 25€ EA since everyone would buy that and noone would pay the later 1.0 full price tag of 60€

Problem is, now they're facing a lot of people who won't buy an unfinished game for $50, because very often, early access is offered at higher % off, not just $10 (or more, because the full price isn't known yet). And then there are people who are afraid the the game won't be finished, or have an expected level of polish, which would mean they wasted that $50.

[fragtzack]

KSP1 was basically in early access until about 1 year ago,  KSP2 is just being honest and upfront about the situation.

[Superfluous J]

22 hours ago, fragtzack said:

Yeah, throw away our real life and dedicate life to Kerbol. 3000+ hours in KSP1 and you want more from me?   <cry>

I'm pretty sure they mean they want you to WANT to play for 1000s of hours.

[kerbiloid]

1 hour ago, Superfluous J said:

I'm pretty sure they mean they want you to WANT to play for 1000s of hours.

Only what the publisher wants plays a role.

Publisher wants money. Money is not per hour, they are in total.

[Anth]

9 hours ago, Superfluous J said:

I'm pretty sure they mean they want you to WANT to play for 1000s of hours.

 

7 hours ago, kerbiloid said:

Publisher wants money. Money is not per hour, they are in total.

 

What do players that play a game for 1000s of hours mean? That DLC's will make lots of money after the main release of the game because of people continuing to play KSP2 for longer than a normal game where people play for a while and then stop, like my playthroughs of the Mass Effect games.

Lets consider the following:

• Do we want KSP2?
• Who got it for us?
• Take2 got it for us.
• Who did they pick?
• Star Theory/Intercept Games with a person whose a KSP nutcase who is Nate Simpson.

Star Theory (who some went to Intercept Games) flew in well known KSP1 players (at least one from Europe) to their HQ in Seattle to ask them what they wanted for KSP2. Any other games that this is happened?

Do we want KSP2 or not? So far everything took a while sure. But other than the Launcher I am fine with everything that has occurred so far.

Take Two want their money. We want KSP2. I am good with that. What was the alternative? No KSP2.

 

 

Edited November 8, 2022 by Anth12

[kerbiloid]

3 minutes ago, Anth12 said:

That DLC's will make lots of money after the main release of the game. 

KSP1 has 2 DLC.

How much % of the KSP-1 players have bought them?

[Anth]

1 hour ago, kerbiloid said:

How much % of the KSP-1 players have bought them?

 

No idea but I seriously doubt that the DLCs were really made for the money making aspect. Their overall goal was to figure out how many people would buy them, then use that for KSP2.

Then on top of that they would have added the fact a certain percentage of people liked KSP but hated the bugs and quit playing.

I believe that Take Two are expecting to make a lot of money. Way more than The Outer Worlds that was also published under Private Division which did really good in the sales department.

[Kubaszzz]

I am very curious abot the 2 ediotion of KSP. I have an idea: What if there could be some planing space on online version. What I mean by that is space where 2-3 friends could build space station and have all parts noteded to take to the space in order to build it there?  I dont know if there is already that idea included so dont blame me 

[Anth]

3 hours ago, Kubaszzz said:

I am very curious abot the 2 ediotion of KSP. I have an idea: What if there could be some planing space on online version. What I mean by that is space where 2-3 friends could build space station and have all parts noteded to take to the space in order to build it there?  I dont know if there is already that idea included so dont blame me 

KSP2 has multiplayer as part of the roadmap. KSP2's foundation is built with multiplayer being a part of it (it was stated from the beginning). Not sure how it will be implemented though.

[kerbiloid]

6 hours ago, Anth12 said:

No idea but I seriously doubt that the DLCs were really made for the money making aspect.

Any commercial project is made for money making aspect, because salary needs money.

[Meecrob]

24 minutes ago, kerbiloid said:

Any commercial project is made for money making aspect, because salary needs money.

I finally agree with you! They didn't make the DLC's for fun...evidence is the bugs in them...sounds like deadline pressure to me.

 

 

"Give us some ROI, or we will reduce budget."

Signed,

-totally not Take Two

Edited November 9, 2022 by Meecrob

[Anth]

3 minutes ago, kerbiloid said:

Any commercial project is made for money making aspect, because salary needs money.

Take Two left Squad (management) to its devices for the DLCs and all the free updates.

The DLCs were buggy, and 1.4 (after Take Two took over) to 1.12 were all overly buggy as well. KSP1 Management seems to just quit when development gets to 80% and doesn't go all the way.

The KSP updates after Take Two acquired the IP could have made 1.4 - 1.12 way more robust by supervising the development more closely but didn't do anything obvious.

What is KSP's biggest flaw? Its buggy and badly optimized. But we love it so much and work around the bugs because there's no alternatives.

Take Two wanted KSP2. That was their main focus. Not KSP1. Not at all or KSP 1.4+ would have been vastly improved.

[Anth]

2 minutes ago, Meecrob said:

I finally agree with you! They didn't make the DLC's for fun...evidence is the bugs in them...sounds like deadline pressure to me.

 

 

"Give us some ROI, or we will reduce budget."

KSP bugs were consistent through out the development of KSP after 1.05 - 1.12.4 with bugs etc when Take Two didn't have the IP until 1.3.1 or 1.4.

The bugs aren't on Take Two.

[Meecrob]

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...

Edited November 9, 2022 by Meecrob

[Anth]

37 minutes ago, Meecrob said:

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...

Yeah I can agree with that. The price of US$50 instead of US$60 that was the original price tag is kind of proof of that.

However Early Access for KSP2 is an excellent idea. I think without it KSP2 would have been less than optimal on release.

Plus we get to see how well Intercept Games interacts with the community with an Early Access instead of a 1.0 release.

[kerbiloid]

1 hour ago, Anth12 said:

What is KSP's biggest flaw? Its buggy and badly optimized.

Noone expected that a one man's pet project would grow into what the KSP is.

It's a cargo scooter tuned into a monster truck.

[Anth]

6 minutes ago, kerbiloid said:

Noone expected that a one man's pet project would grow into what the KSP is.

It's a cargo scooter tuned into a monster truck.

 

Six 1.7 Bugs I reported in relation to the maneuver mode:

• The Maneuver Mode starts from Year 0 Day 0. This causes issues because the Universe started from Year 1 Day 1.
• Ejection Angle changing constantly when its part of a maneuver node. It should be stuck in the exact time the maneuver is supposed to be happening (in the future)
• Somehow Phase Angle was locked on Kerbin as the center of all phase angles, when the sun is the center for a phase angle between Kerbin and Eve, Kerbin is the center for a phase angle between Mun and Minmus, Jool is the center for a phase angle between its moons. That never got fixed.
• UT time in the maneuver node tab doesn't work correctly under the Year:Day:Hour:Minutes:Second entry option (clock icon)
• Entering the exact time of a maneuver node in the UT text box moves the node around the proposed maneuver instead around the current orbit.
• The mouse over text doesn't change if the target is changed from Planet to Planet or Craft to Craft BUT does change if target is changed from Planet to Craft or Craft to Planet.

This isn't hard programming. And the spaghetti code of KSP1 wasn't an excuse for these bugs. It just needed to be tested and fixed before the 1.7 release.

 

With all the bug reports I have done for KSP1 and the secrets they showed me:

KSP2...I am COMING FOR YOUUUUU!!! Be ready to RUMBLE!

 

[kerbiloid]

9 minutes ago, Anth12 said:

With all the bug reports I have done for KSP1 and the secrets they showed me:

KSP2...I am COMING FOR YOUUUUU!!! Be ready to RUMBLE!

A game put into early access four years later after the pre-declared release date is just doomed to be bugless.

Edited November 9, 2022 by kerbiloid

[Anth]

Just now, kerbiloid said:

A game put into early access four years later after the pre-declared release date is just doomed to be bugless.

You take that back! (I secretly hope you are right)

[Deddly]

4 hours ago, Anth12 said:

This isn't hard programming

How would you fix them? As someone who has dabbled only in a little TCL for the IRC bot, this kind of thing is beyond me but still fascinating. 

[Anth]

2 hours ago, Deddly said:

How would you fix them? As someone who has dabbled only in a little TCL for the IRC bot, this kind of thing is beyond me but still fascinating. 

 

My main experience was with a small amount of Visual Basic years ago where there is a graphical window where a dialog box etc can be created and text boxes and labels and other things can be attached. Then there is code and attributes that is connected to the textboxes or whatever that is able to be interacted with on the window when tested.

With Unity I have only made one mod for KSP that showed coordinates of individual parts of a craft using the action menu for a bug report relating to the robotic drift. That mod ended up helping with what eventually became 1.12.3

So to be honest my experience is kind of limited. But based on Visual Basic and the small tiny amount of experience with Unity I would have to see how the code links to the UI elements and see how it works before changing it.

7 hours ago, Anth12 said:

Six 1.7 Bugs I reported in relation to the maneuver mode:

• The Maneuver Mode starts from Year 0 Day 0. This causes issues because the Universe started from Year 1 Day 1.
• Ejection Angle changing constantly when its part of a maneuver node. It should be stuck in the exact time the maneuver is supposed to be happening (in the future)
• Somehow Phase Angle was locked on Kerbin as the center of all phase angles, when the sun is the center for a phase angle between Kerbin and Eve, Kerbin is the center for a phase angle between Mun and Minmus, Jool is the center for a phase angle between its moons. That never got fixed.
• UT time in the maneuver node tab doesn't work correctly under the Year:Day:Hour:Minutes:Second entry option (clock icon)
• Entering the exact time of a maneuver node in the UT text box moves the node around the proposed maneuver instead around the current orbit.
• The mouse over text doesn't change if the target is changed from Planet to Planet or Craft to Craft BUT does change if target is changed from Planet to Craft or Craft to Planet.

This isn't hard programming. And the spaghetti code of KSP1 wasn't an excuse for these bugs. It just needed to be tested and fixed before the 1.7 release.

Note the following bug was fixed: Entering the exact time of a maneuver node in the UT text box moves the node around the proposed maneuver instead around the current orbit.

The others weren't

@Lisias (getting an expert) Can you please give me a hand for a second after my grandiose claims.

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

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

And could the spaghetti code of KSP1 be a hindrance?

Was this above the skill of the Squad developers?

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.

Edited November 9, 2022 by Anth12

[Lisias]

11 hours ago, Anth12 said:

@Lisias (getting an expert) Can you please give me a hand for a second after my grandiose claims.

Me and my big mouth.   Let me check the previous posts, so I can estimate how badly I will shoot our collective feet...

 

11 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...

 

11 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 burnt on the process.

"Cheap. Fast. Good. Pick two."

 

11 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.

 

11 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...

 

11 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 skills 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.

Edited November 10, 2022 by Lisias
Grammars. Don't you hate this thing?