gluckez

ksp2 does have a broader scope than ksp1 did, so it's absolutely valid to get informed about how it works. and the best people to learn that from are experts in the field. If you want a game with the same scope as ksp1, why not just play the original? well, it is... at least in every team I've worked in in the past 6 years.

Maybe it's worth mentioning then that I am also a professional software developer with extensive knowledge on Unity development. I don't need an official source to be able to tell you what is optimistic in terms of developing software. We also know that ksp1's first prototype came without a sun, without a rotating kerbin, without any other celestial bodies, without SAS, without control surfaces, etc... I also took 3 years before it reached early access, and by then it did have other planets. and even then, that does not invalidate any of my points that I made about effort that goes into development. that was my entire argument. My argument was not about "how long" it takes to develop something, it's about the fact that software and game developers estimate this in terms of effort, not time. only management deals in terms of "time". How much "time" does it take to get a firm grasp of orbital mechanics? did the original devs of ksp1 already have that knowledge? how long did the original devs of ksp1 work with a panel of scientists to understand the domain? is this also calculated into the "time spent on development"? can you teach yourself advanced physics and engineering in a week before you start development? so my entire point is that it's basically pointless to look at it from a time perspective, because that's not how development works. The only thing I can't argue on here is what's being told is done or not, if they said it was finished 3 years ago, then they were clearly lying, unless by that time they hired a new architect who found it necessary to rebuild everything.

lets go by a measure then that's actually used by developers themselves: effort. Developers do not estimate in terms of time, but rather effort. Then on top of that, let's consider the idea that "development" is more than "writing lines of code". When ksp2 was originally announced in 2019, the original release date was set in 2020. that in itself is already hugely optimistic/not viable. This release date was not set by developers, I can guarantee you that. After that initial announcement, the game was being developed by Star Theory Games, who worked together with a panel of scientists. This is where it becomes interesting as a developer, because here "development time" should be seen as "analysis effort". you spend months/years working with experts in the domain trying to get a good grasp of everything ranging from engineering to orbital mechanics. as a software/game developer, that isn't an easy thing to do. So the first part of the "development time" was spent on analyzing the domain so they knew what they were building. After that, the release date was pushed back to 2021, because now management sort of maybe understood that developing things takes time and you first need to understand what you're building exactly. now management decides that take two will establish a new studio under private division, with a few of the older employees. This is a major problem, because all of the knowledge of those older employees that left needs to be transferred to the new ones. again, months of effort needed for domain analysis. meanwhile, there's an architect working on designing the skeleton of the game, that needs to be future proof, and support all the features promised, be scaleable and withstand the quirks of junior developers constantly breaking stuff. while this is being done, 3D and 2D artists work on in game assets, and UX/UI designers work on laying out gameplay mechanics... You see where I'm going with this? I could literally write a book just about how this entire process goes. my point is, even though you have a "big" team (<25 employees) there's still a lot of work that goes into building a video game. and more often than not, restructuring by management, and refactoring and analysis efforts, are unforeseen events that will delay everything. This is why I choose the measure of "development stage", because you can't really know how much effort is being put in the actual building of the game vs everything else that happens in a company. sometimes a feature gets delayed because management decided it was a good idea to fire half the development team and hire a bunch of cheap juniors that don't understand the code base, and you cannot possibly estimate how long it will take for these new employees to understand the code base, and that's just one example of what can delay everything, that has nothing to do with the existing code base itself.

what do you mean "less features"? you quote me to answer this, but literally in the next sentence after what you quoted I explained how at that stage, ksp1 actually had less features. as in: no actual sun, kerbin didn't rotate, no other celestial bodies, etc... ksp2 already has more features than ksp1 did in this stage of development. It has a full solar system, kerbin actually rotates, you have procedural wings (which were never even in ksp1 so that's already new), you have SAS, etc... And before you go: oh it's a sequel so it must already have all the same features as the previous version, my answer to that is: it was built from the ground up, by a different team, so it makes sense that it didn't just copy paste the original code base.

we can be patient. When the ksp1 alpha came out, the sun was simply a directional light. kerbin didn't rotate, there was no SAS, there wasn't even a mun, or any other celestial body. People have just become really impatient and entitled, sure, you paid full price for an early access, but you knew while you were paying for it that it wasn't gonna be done in 3 weeks. ksp1 took years to go from alpha to fully built out, and even then it couldn't slay the kraken. it seems that a really toxic part of the community is behaving like management, and just demanding things that aren't built or tested properly be pushed to production. Sure, go ahead, make the game yourself. and then when you ultimately do run into the issue that there's no one left to continue development and the codebase is riddled with junior level mistakes, then point the finger back to the original creators I guess. Either way, you let them do it properly, or you take over and do the same thing terribly, it'll take a time and money.

what exactly do you mean with "systems that need it"? A lot of unity components don't require asynchronous behaviour. for example mesh renderers and colliders, input, etc. when it comes to physics behaviour between parts, multithreading doesn't benefit much, because each part needs to wait on the other parts physics update to complete anyway, otherwise you'll experience clipping and even worse cases of kraken attacks. There are also other ways of leveraging multiple threads in Unity that doesn't involve DOTS, jobs or the burst compiler, but it needs to be useful and not work against you while you're still building the base of the game. bugs can be easily hidden in other threads, so even if something performs well, that doesn't necessarily make it better.

ah, thank you. I stand corrected. I didn't see that one.

They tweeted that there would be a delay on the 19th. unfortunately, they didn't mention how long the delay would be

I'm pretty sure pretty much any development team knows what concurrency is. Applying asynchronous programming can be very beneficial in most cases, but does not come without it's caveats. When applied to something like a ship, and all its parts, there's a lot you need to account for that could end up costing you more resources. One of the issues is that parts of a ship also react to other parts of the ship, not just it's environment. So even though each part can concurrently interact with the environment, any update on a part will need to impact connected parts as well, which is something that, when done concurrently, would need to be simulated in memory and may actually cost you more computing power than if you would just do it synchronously. I do agree that DOTS is a super powerful solution, but it might be more interesting for loose parts and procedures, especially if you can properly leverage it's data oriented aspect and the burst compiler. in the long run, this is definitely something that they should aim for though, so it's a discussing that they should really have internally.

I like both the idea of a grid function, and pre-made square wings. maybe better to implement a grid function, and to be able to save the configuration for a part for later use?

nice ideas. I also have one, but way way way down in the future when everything is released: functional dyson spheres. And about the robotics, I think that should be in the base game though, it would be super useful for building colonies and space stations, but also to fit larger rovers in a fairing if you can fold in the wheels.

I'm glad I found this somewhere in another thread. I had no idea what the current status was, or when an update would be available. I'm a software dev myself, so I understand that these things take time, but is it possible to make these bug status reports more visible? keep up the great work!

Same here, I stopped doing any sort of missions since I couldn't get it to work properly. After landing on Duna I figured Laythe was the next stop, but my spaceplane wouldn't get off the ground due to a bug where the control surfaces were reversed. And even if I could get it to laythe, I wouldn't count the mission since there's not even any re-entry heating. I'll start playing again if there's something to be done other than visiting the planets and looking for easter eggs, I hope science comes back soon.

yes, I'm stuck on Duna

yeah, I got the same bug but on Duna xD guess my lander is a colony now and Seedred will have to wait. don't think I had enough deltaV to return anyway