Nate Simpson at Space Creator Day talks about KSP 2.

[Kerbart]

4 hours ago, Scarecrow71 said:

I just watched ShadowZone's interview with Nate, and I've got some comments on a few specific things Nate said and/or talked about.  Feel free to not read this if you are tired of hot takes!

I thought the interview went very well. Tough questions were asked, and what seemed like honest answers were given. I've become pretty cynical about what we heard and this interview was by far the best thing, as Nate did a good job in trying to manage expectations. I got a better feeling from the interview than from the SpaceCreator presentation itself, TBH

Quote

The Work Takes The Amount Of Time It Takes (3:45)
[...] I'm not arguing here that the work took time.  I - all of us, really - want this to be done right.  But the question as to why it took so long remains.  That is an answer we would all really love to get.  Why on Kerbin did it take 4 years to release this as EA?

Will the answer change anything to the current state? Maybe saying that's all water under the bridge is a bit too easy, but right now, in regards to KSP2, my biggest concern is if For Science will live up to the hype (and I truly hope it does). Maybe one day we'll find out. It's probably an exploding dev team, politics, and a project restart due to resetting the goal posts. Likely a mix. No evil conspiracy or lizard lord influence, but perhaps the Spanish Inquisition showed up unexpectedly.

Quote

Code Replication From KSP1 to KSP2 (12:00)
[...] We have been told this entire time that no systems or code have been re-used from KSP1 to KSP2.  But Nate's statements about copy/paste and doing it if the cost was low enough are cause for concern.  Couple this with the fact that we are seeing some bugs in KSP2 that were around in KSP1, and, well, I cannot believe that no systems were copied.  Although possible, it is highly improbable to actually code the same bugs in 2 different pieces of software that are not copied from one another.  Again, possible, but not probable.

Funnily enough, for me it's the area of least concern. You can start a project like this with working of the existing code base and refactor the sweet mangojuice out of it, or you can start from scratch and it appears to me that restarted from scratch. There's a reason so many things don't work.

The claim if no systems were cloned is one for semantics, I guess. I have little doubt that a "simulation clock cycle" was indeed  written from the ground up (updating fuel status, forces, velocity, etc). That, in my mind, is a "system" and to facilitate the desired features into the game, I think it's safe to assume that it would actually be easier to start from scratch then to shoehorn it into existing KSP1 code with all the new functionality and data structures bolted on.

But "determine the normal vector based on current orbital parameters" is a well defined problem for which existing code exists, likely with some non-trivial exception handling that you wouldn't think of the first time you wrote that from scratch. Of course you can expect that kind of code to be copy & pasted. Why wouldn't they? Also, I doubt the bugs do come from those instances as it's generally code that has been refined and tested over the course of years (which is why you'd use such a code block in the first place).

And as @ShadowZonepointed out, there's also middleware that is used in both products that might do things in a certain way, perceived as a bug (whether it's a feature or not). Yes, the bug gets reproduced, but that doesn't mean it's because Intercept copied code.

Finally in a system with similar input and similar desired output, code might be similar and coders might walk into similar pitfalls

Quote

Number of Engineers (18:00)
[...] This question goes along with his statement of "The work takes the amount of time it takes".  No, you aren't an engineer.  No, you probably aren't in charge of them.  But how can you be the Creative Director, and have worked on this game for multiple years, and simply not know how many engineers are coding this thing?  I may not know of everyone in the company I work for, but I can tell you exactly how many people are on the teams I directly work with on a daily basis.

I actually likes this part for two reasons:

• Shadowzone kept at the topic (I think Matt was easier guided away from his "hard topics")
• Nate clearly didn't want to get caught in  a lie (a good step forward in regaining community trust)

There's likely two parts to as why he doesn't want to give the answer. First of all there are likely part-timers and/or independent contractors. Maybe there's this really expensive unity expert on phong shading that you only hire a few hours per week to work on things no one else can do, as needed. That makes it hard to give an exact answer, especially if you've hired those coders for extended amounts of time for the sprint, but now you're putting that on hold when the work is delivered. I think he really doesn't know what the exact FTE count is as it's a number that changes week-to-week.

The second part is embarrassment; it becomes very clear that the answer is "closer to 20 than to 50" as well as that it's not in between the two. With all the critique on work progressing slowly I'd be reluctant to admit he only has a dozen engineers at his disposal as well (total staff is likely more - artists, game desing, management, quality assurance, etc). Likely outside his control, and it is what it is, but not a number you want to send into the world when everyone is questioning (based on past experiences) the ability to deliver on time.

[PDCWolf]

1 hour ago, Vl3d said:

I'll just leave this here from 4 years ago. You can watch both interviews and compare the subject matter talked about.

 

"it is my understanding there's no holdover code on that [fuel flow] system at all, that we're organically encountering the same challenges that KSP1 is facing, because we're attempting to simulate fuel flow across in some cases some very complicated trees."

How is a listener supposed to take this? You have the first game, you can look at the code of the first game, yet you develop an allegedly new solution that has the same problem, even though you know that barrier is still there? There's no good way to take this. 

"I can not make a categorical statement that nobody has copypasted any code between KSP1 and KSP2. My understanding not being a person who can look at code myself is that there's little to no reuse. Perhaps if other people are performing a forensic examination of the codebase and determine there's significant code reuse I'd be very curious to hear about that".

Nate, you know it breaches EULA to look at the code, and it's even illegal in some countries...

"If a feature could be replicated at relatively low cost by duplicating it from KSP1, I'd be eager to do that. That's one of the things that's made KSP2 complicated is that this is very rarely possible to even theoretically do that, because the underlying systems are so different".

And then ShadowZone reveals they're using the same middleware as in KSP1. Lmao. That's probably another reason they decided to stick with unity, having to depend on third parties' software that might not be available anywhere else, much less if they went custom.

 

[Lisias]

3 hours ago, Vl3d said:

Regarding the ShadowZone interview, I very much appreciate it, but we keep focusing on the same problems with the internals of the technical development and ignoring the very important aspects of gameplay decisions and mechanics. We know very little about how this game is improving on KSP 1 gameplay and how the new features work in detail.

Yep. But as a matter of fact, only now with 0.1.5.0 we (apparently) have a game that is really playable, essentially we have now what should had been delivered in January. Until now, the technical development were in focus because this is what was preventing the rest of the game to be evaluated (if not plain being loaded).

NOW we are in a position to start evaluating the gameplay (before, something usually crashed way before).

But, given the information I'm getting in other threads, I need to warn you: some aspects of KSP2 are way different from KSP¹ except on the most basic use cases. Casual players will probably not notice any difference, but seasoned users surely will - and this may not be exactly a positive outcome (IMHO, it's not).

[Pthigrivi]

I mean I think the answer to this: 

51 minutes ago, PDCWolf said:

How is a listener supposed to take this? You have the first game, you can look at the code of the first game, yet you develop an allegedly new solution that has the same problem, even though you know that barrier is still there? There's no good way to take this. 

is this...

52 minutes ago, PDCWolf said:

"If a feature could be replicated at relatively low cost by duplicating it from KSP1, I'd be eager to do that. That's one of the things that's made KSP2 complicated is that this is very rarely possible to even theoretically do that, because the underlying systems are so different".

Because the underlying structure needs to be much different in order to accommodate things like acceleration under timewarp, interstellar scales, and future multiplayer implementation they can't just copy paste solutions from one game to the other. They do still have to solve all the problems KSP1 encountered but in a different way. As a far as I understand it even something like axial tilt would have been very difficult to implement in KSP1 because its fundamental code was structured the way it was. 

[PDCWolf]

2 minutes ago, Pthigrivi said:

I mean I think the answer to this: 

is this...

Because the underlying structure needs to be much different in order to accommodate things like acceleration under timewarp, interstellar scales, and future multiplayer implementation they can't just copy paste solutions from one game to the other. They do still have to solve all the problems KSP1 encountered but in a different way. As a far as I understand it even something like axial tilt would have been very difficult to implement in KSP1 because its fundamental code was structured the way it was. 

But you know the problems KSP1 had, why program them in again?

[Pthigrivi]

3 minutes ago, PDCWolf said:

But you know the problems KSP1 had, why program them in again?

Maybe this is just a word interpretation issue. By problems I mean challenges--fundamental physical and programming solutions that need to be found one way or another. They're running into many of the same issues because they're trying to solve many of the same challenges, but now with added constraints imposed by new features and systems. 

Edited November 3, 2023 by Pthigrivi

[Lisias]

3 minutes ago, PDCWolf said:

But you know the problems KSP1 had, why program them in again?

Well, I'm a software developer myself and I can say that, sometimes, a fix to the problem causes more damages than the problem itself and so we code the problem back.  

It happens way more than we would like.

[cocoscacao]

1 minute ago, Lisias said:

happens way more than we would like.

How many times I thought that something is stupid and I can do better. It's rather obvious solution really. Then edge cases bring cake to my doorstep...

[PDCWolf]

31 minutes ago, Pthigrivi said:

Maybe this is just a word interpretation issue. By problems I mean challenges--fundamental physical and programming solutions that need to be found one way or another. They're running into many of the same issues because they're trying to solve many of the same challenges, but now with added constraints imposed by new features and systems. 

Okay let me rephrase. First off, I don't think they coded in such a problem willfully, wanted to clear that up. 

My point is: You have the system already coded (fuel logic from KSP1), and you have unfettered access to the bugtracker both public and private to see which problems it ran into. So you know making the fuel logic behave a certain way is gonna make the game chug when you spam engines.

It's no longer crashing against a new issue, it's repeating a well known and probably even well documented one in a system that's supposed to not be the same as the last.

I don't believe in "we're organically finding the same issues" without also having to take into account that they are either ignoring that the issues were there, or worse.  

[cocoscacao]

10 minutes ago, PDCWolf said:

First off, I don't think they coded in such a problem willfully

Reading (understanding) the code of others isn't easy. Some problems are very specific and there aren't that many ways on how to solve them. Trying things out and even repeating mistakes is a way to learn and gain deeper understanding, so you can refine the solution. This is exactly what I usually do with juniors assigned to me. Give them a task where they're gonna hit every possible roadblock that I know of.

[Lisias]

7 hours ago, PDCWolf said:

It's no longer crashing against a new issue, it's repeating a well known and probably even well documented one in a system that's supposed to not be the same as the last.

Because the problem isn't always on the code, sometimes it's on the requirements. 

For example, the crafts in KSP¹ are internally Trees. Make it simple to code and previsible to determine how many iterations you will need to run over it to do something, but it has a serious drawback: it limits horribly how to design a craft.

Graphs are perfectly for the job, we could design our crafts around spars and spines using Graphs, it's a way more flexible data structure! 

So we rewrite the thing to use Graphs, and now we can't keep stable FPS no matter what. Problem: Graphs are way less previsible than Trees, we need to keep track of the nodes we had ready visited because we can get there again multiple times by multiple routes. Not being bad enough, this also hinders paralelism because all workers need to share the list of visited nodes and so this list must be synchronized. 

And then we go back to Trees because you can open a thread to each branch, knowing in advance how many work each thread will handle and there's no need to share runtime data between the threads.

Our crafts are crappy again, but at least we can fly them.

Edited November 4, 2023 by Lisias
Tyops!

[Kerbart]

18 minutes ago, cocoscacao said:

Reading (understanding) the code of others isn't easy.

And your own code, of course, looks like it was written by someone else after three months...

[moeggz]

On the subject of Shadow Zone’s interview I do think both Shadow Zone and Nate gave a good interview. I think it was professional from both sides.

Like others, some of the explanations of what happened in the past leaves me a little confused.

For instance running into unexpected problems that take longer than you think to solve is a totally understandable problem. However there’s no need to say the game is nearly finished and so fun it’s a production issue if it’s not nearly finished. Even if it’s hard to predict how much longer it will take to be feature complete, knowing how playable the game is at a given time seems easy, and there was no need to oversell that. 

All that said, I appreciated how in this interview the communication about the future of the game was different to how that has been done in the past. I personally vastly prefer this I undersell style, and if the game talks for them with For Science! I think they can still regain community trust.

Even with the gaps in the explanation, this was Nate clearly understanding how he (unintentionally) contributed to the erosion of trust, said that it was reasonable to be frustrated, impatient, and to have low trust in the devs, and then said this coming update will speak for what has happened over the past 10 months. That’s a major step forward in being transparent.

If the update doesn’t live up to the expectations, well they know and we know that KSP2’s image and potential sales will probably not be recoverable.

If it does, I for one will wear my dunce hat for being overly pessimistic, admit where I was wrong, and enjoy the update and get hyped for colonies. 

I want a performant, bug free, and expanded Kerbal game way more than I want to win an argument or to know the exact causes of the slow start to development. I’m pessimistic on some things because being pleasantly surprised things went better than I expected is a lot easier for me to process than the reverse.

I appreciate and agree with the view that the vocal frustrations come from a place of passion. I really hope For Science! makes me have more passion for playing the game than for talking about it.

[Vl3d]

10 hours ago, Lisias said:

Our crafts are crappy again, but at least we can fly them.

Why can't I connect two subassemblies using just struts, without other tricks / decouplers / docking ports?

4 hours ago, moeggz said:

If the update doesn’t live up to the expectations, well they know and we know that KSP2’s image and potential sales will probably not be recoverable.

But what exactly are the expectations?

4 hours ago, moeggz said:

I want a performant, bug free, and expanded Kerbal game

If these are your expectations, I've got bad news.

https://forum.kerbalspaceprogram.com/forum/120-ksp2-suggestions-and-development-discussion/

Edited November 4, 2023 by Vl3d

[Lisias]

8 hours ago, Vl3d said:

Why can't I connect two subassemblies using just struts, without other tricks / decouplers / docking p

Because a single craft need to be a tree, so if you are going to merge two crafts, one of them need to be rerooted in order to keep the final result still a tree, otherwise your data structure will degenerate to a graph, and then you are screwed.

Struts are a hack to allow multiple nodes on the same tree but in different branches to "connect" - but these parts still need to be on a tree, otherwise they wouldn't be reachable by the traversing algorithm.

On a pretty abuse of language, you can think on Struts are being "GOTO's" used on a structured program: you still need to follow the code's flow until you reach the GOTO.

 

12 hours ago, moeggz said:

If the update doesn’t live up to the expectations, well they know and we know that KSP2’s image and potential sales will probably not be recoverable.

If it does, I for one will wear my dunce hat for being overly pessimistic, admit where I was wrong, and enjoy the update and get hyped for colonies. 

There's a line in need to be draw about expectations:

1. There're the KSP¹enthusiasts that want a better, enhanced and more polished KSP to play with.
2. There're the gamers in general, willing to try something new and easily reproduce some of the stunts they see on KSP¹ videos on youtube but on a less demanding framework.

The first group IMHO will be pretty disappointed with KSP2 and I'm betting they are the reason the reviews on Steam didn't reverted the trend of bad reviews (besides 0.1.5.0 being a pretty solid update on the technical point of view).

The second group will probably enjoy KSP2 very much, as soon as they are able to play the damned thing.

Knowing in advance what you expect from KSP2 will surely help on foreseeing what you will think of it once it is, finally, feature complete.

Edited November 4, 2023 by Lisias
Tyops

[cocoscacao]

3 hours ago, Lisias said:

besides 0.1.5.0 being a pretty solid update on the technical point of view

I hope they do an update with wobble patch before 0.2.0, to ease up the waiting time

[MechBFP]

12 minutes ago, cocoscacao said:

I hope they do an update with wobble patch before 0.2.0, to ease up the waiting time

Given that 0.2 is only about a month away, there is a 0% chance of that. 

[cocoscacao]

8 minutes ago, MechBFP said:

Given that 0.2 is only about a month away, there is a 0% chance of that. 

Eh... I don't remember if 1.5.0 addressed a few parts, but at least, my payloads no longer wobble outside of fairings. 

[Lisias]

On 11/2/2023 at 5:31 PM, Lisias said:

Not enough people are getting fun from the game!

<…>

The bugs are annoying, but as they are being solved, people are still having a hard time to keep motivated on playing it.

We have an improvement on the positive reviews, but the negative didn't budged at all since last time I check it.

Apparently @PDCWolf had some solid points on this:

On 11/2/2023 at 2:42 PM, PDCWolf said:

It does so long as it doesn't get better. People won't magically forget when release arrives, they have to rebuild that during however long they plan to take. It's incredible how decontextualized people have become in regards to the game's situation:

• The people that want the game no matter what already have it. They won't "come back" because they're already there.
• The people who felt hugely betrayed or disappointed are gone, they won't come back. Welcome to the 75% activity decrease slump.
• The people who don't trust the devs might still stick around to see where they end up. There's probably a chance to convince them if FS! and following headliners are actually worth it.
• That KSP2 will have the same engine, spaghetti codebase, unoptimized physics and comical joints is already set in stone, and so the people who wanted the foundational pieces changed are gone, and won't come back.
• The people that don't mind the point above but wanted more will only come back on further headliners, provided those are good, or even in post 1.0 DLCs (remember how KSP2 will not have robotics or life support?)

So far 0.1.5 and FS! announcement haven't done anything for the reviews or the playerbase being back again on a negative trend after the small patch spike.

On the other hand, the player count appears to hold (the numbers from yesterday are similar to the numbers from last week's Tuesday), so we have an improvement for sure - more older players are being "converted" back and sticking around:

This may suggest a problem on converting new players (the ones more prone to write new reviews). More people entered the game, but half of them are still getting liquided on it. Still the Bill Bernbach effect?