Search the Community

But the planets just don't look good outside of the map view? Like what are you even talking about? I can look at Kerbin and see jagged square tiles of terrain where it intersects the ocean at basically any range, nearby hills appear as perfect triangles because the quality vs distance is worse than KSP. That's not an improvement. I don't care if it apparently never looks like it repeats when the ground looks magnitudes worse overall, the scatter assets seem to be UV unwrapped more incorrectly than not, the mountain ranges have shrunk ridiculously and are completely unimpressive and unexciting now? Like usual the game you talk about and the reality of the game in our hands are completely different things.

Indeed. As I view it, they've fixed nothing, and will, in my view, remain with having fixed nothing, until the content is out in the hands of the end-user. They can talk all they want about all they did, but not a single bit of what they claim to have done matters until and unless it is published and out there. So far all we have to show for what's happened, is 3 weeks of silence, vague promises, and a frustratingly amateurish/haphazard PR strategy that even still doesn't seem to meaningfully be addressing questions regarding content or timetables. And to that end, when I saw after Dev Diary 18 went up, a promise that there'd be "more coming today" in the announcement on Discord...I expected something much more informative than "look at the cool stuff people have made" about an hour and a half after that went up.

Good afternoon, fellow Kerbonauts! We continue to make good headway on performance improvements and bug squashing. In fact, we managed to sneak a few additional fixes into the first patch, including a fairly high-impact resource flow optimization. We also fixed the "Kraken drive" bug that created insane reverse thrust when an engine’s nozzle was obstructed - so if you’re working on a Kraken ship, the "unique" physics on which it depends are about to go away forever. We may not in fact have killed the Kraken yet, but we have definitely stubbed its tentacle. As to the timing of Patch One... QA is thoroughly testing the build right now, and as soon as they give us a thumbs-up, we’ll release it. Right now, our goal is to release that patch next Thursday (March 16th). Provided QA does not uncover any show-stopping bugs over the next few days, that date should hold. If they do run into something unexpected that needs to be fixed, that date will slip. We have done a fair amount of hand-wringing around whether we should announce the target date for this patch when there is a non-zero chance of a delay, but we know this topic is very important to you all, so we're doing our best to keep you all in the loop. We’ve also already completed a nice queue of fixes to go into the second patch, but we’ll talk more about that after we’ve got the first one out the door. To help tide you over until then, we’ve got a new performance-focused dev blog post from Mortoc, our senior graphics engineer. If you’ve been wondering how we test performance and what we’re doing to improve it, this one’s definitely worth a read. Finally, I just wanted to give a holler of support to the many people who have undertaken the weekly challenges - last week’s air-launched rocket challenge was a sight to behold, and we’re on the edges of our seats to see what mayhem will take place during this week’s Minmus challenge. If you want to take part (or just bask in the ingenuity and/or madness of our community), check out the Weekly Challenge Discord channel. Our Community Team has also picked out a few choice gems from the last week and added them to a Community Highlights post here. Yes, the shopping cart is in there. The shopping cart that flies. See you on Minmus!

There one on ckan side that runs on SpaceDock and notifies them. You want to talk to @HebaruSanabout how ckan works and integrates (it might even help you not to reinvent the wheel) The main point im trying to make is: Mod Authors have to approve of distribution channels.

Hi Y’all, I’m Mortoc, the new graphics programmer on the team. I wanted to take some time to chat about KSP2’s graphics and performance – where we are today and what our process is and what the team’s goals are. As many of you have noticed, KSP2’s performance isn’t amazing at the start of Early Access. In a game as complex as KSP2, there are a dizzying number of areas that we could spend our efforts on and the feedback we’re receiving is invaluable for us to focus our time on the issues that affect the players the most. There are different reasons that the framerate can suffer. If the CPU is asked to do too much during simulation or if the CPU is asked to send too much data to the GPU in an organized fashion, it can make the framerate drop without maxing out the GPU. In most cases the performance in KSP2 is bottlenecked by the GPU, and since I'm a graphics engineer, that's what we're going to investigate in this article. Other engineers are working hard on CPU-facing improvements that you'll see reflected in upcoming updates. Deep Dive Warning: Numbers Ahead Before we dig into the numbers, let’s start with a primer on what we’re looking for here. Game developers tend to think of framerate in terms of milliseconds rather than FPS because it’s easier to budget out your frame time that way. Converting from FPS to ms is simple, you just use the formula 1,000 / FPS = ms (for example: 100 FPS means it takes 10ms per frame, 1,000 / 100 = 10). This way we’re talking about how long a system takes to run directly. We want to measure how many milliseconds each system in the game takes in order to figure out which are taking too much time and dropping the framerate. We use a tool called RenderDoc for our automated performance testing (among other tools). RenderDoc allows us to get the ground-truth timings for every single command sent to the GPU. Our tooling can then pull out the slowest GPU events for us to investigate. The machine I’m using here for performance analysis is a laptop with i7-8650U CPU, Mobile Nvidia GTX 1060 6gb GPU and 16gb RAM. It has a slower GPU than our current min spec, so we’re not expecting it to make a playable framerate yet. KSC Landing Screen – 11 FPS 10 Slowest GPU Events Draw # Duration (ms) PQSRENDERTEMP\Draw(229248) 270 6.08 RenderDeferred.GBuffer\Draw(229248) 505 5.84 RenderDeferred.GBuffer\Draw(229248) 506 5.44 CloudCommandBuffer\DrawIndexed(6) 746 4.43 Shadows.RenderJob\Shadows.RenderJobDir\Draw(229248) 652 4.31 GenerateWaterDepthCommand\Draw(229248) 576 3.18 RenderDeferred.GBuffer\Draw(229248) 503 1.72 RenderDeferred.GBuffer\Draw(229248) 504 1.63 Draw(229248) 263 1.62 cloudsShadowCommandBuffer\DrawIndexed(6) 560 1.58 In this scene, eight of the top ten worst-offenders are related to PQS+. PQS stands for Procedural Quad System and it’s the algorithm used to generate planet terrains. KSP2 uses a modified version of PQS from KSP1, generally referred to as PQS+ after all the modifications made to it for KSP2. That table starts with a draw call to PQSRENDERTEMP, which emits 229,248 vertices. Each other draw call that uses that specific number is doing some work on the PQS mesh. The two draw calls not related to PQS in that table are the ones with a 6 in the name and are related to the cloud system. From this report we can see that the terrain clearly takes the most GPU time in this scene; 29.94ms in total. Let’s try another vantage point. LKO – Low Graphics – 8 FPS 10 Slowest GPU Events Draw # Duration (ms) PQSRENDERTEMP\Draw(92160) 237 10.44 RenderDeferred.GBuffer\Draw(92160) 301 4.06 RenderDeferred.GBuffer\Draw(92160) 302 3.14 RenderDeferred.GBuffer\Draw(92160) 304 2.34 Dispatch(12, 240, 1) 1 2.07 RenderDeferred.GBuffer\Draw(92160) 303 1.59 CopyResource(ObserverCubemapView_CubemapFinal, ObserverCubemapView_Temp) 92 0.60 CopyResource(CelestialBodyCubemapView_CubemapFinal, CelestialBodyCubemapView_Temp) 184 0.33 Camera.Render\PQSRENDER_DEFERRED_DECAL_MASK\Draw(92160) 230 0.24 Camera.Render\Draw(92160) 227 0.23 As you travel away from any Celestial Body, we swap out the complex Local shader with a Scaled version that’s much more efficient. This scene is from Low Kerbin Orbit, but still close enough to the planet to be using the Local version of the shader. PQS+ is again 8 out of the top 10 worst calls (the line Dispatch(12, 240, 1) which is Draw Call #1 is from at the start of the frame when we kick off a compute shader to generate the terrain mesh). That first PQS+ call that took over 10ms is especially dirty. Staying Grounded Clearly the PQS System and related shaders are a big performance problem. Let’s talk about that, but first dig into some background. A core philosophy for the early part of KSP2’s EA cycle is to make sure “it still feels like a KSP game”. This means that for each feature we build, we want to start with what KSP1 did and then build a similar system that improves on it. Following that goal, the team started with the PQS design from KSP1 and added modern graphics features for KSP2’s PQS+. As development progressed on KSP2, more and more features were added to PQS+ to keep pushing the artistic envelope. I might be biased, but from orbit, Kerbol’s planets look incredible. Our art team did a fantastic job. From the surface the game is still quite pretty, but the terrain itself just doesn’t have the consistent visual quality we want yet. While trying to build that ground up to our visual ambitions, we added more features than the previous PQS architecture can support. It wasn’t until the ramp up to EA that it became understood just how far past the limits of the tech we had reached. Future Trajectory OK, so, clearly there’s a problem, what are we going to do about it? A few things are being done simultaneously. First, we’re prioritizing performance optimizations for this system over the next couple of patches. Particularly for when graphics settings are “LOW”, we want this system to be eating far less GPU time. This takes two forms: one is pure engineering optimization that doesn’t affect final graphics, the other is to disable certain visual features when the graphics are set to “LOW” or “MEDIUM”. That first category, engineering-only fixes, was taken about as far as it could be with PQS+. Our short-term plans are currently focused on the 2nd category, turning off features that don’t provide enough bang for the buck. Here's an example of an optimization that affects the visuals. Coming soon in a patch, we will be able to turn off the Anti-Tile system in the terrain. In a bunch of places, the effect is negligible, but you can see the Eve surface has a repetitive texture artifact without it. This visual polish comes at the cost of accessing each texture a few more times, putting strain on the memory bandwidth of the GPU. Disabling this effect can have a small-to-medium sized effect on the framerate, depending on the GPU in question. Optimizations like that one are happening now and will arrive in the next few updates. The rest of this article deals with systems that are in progress, so we cannot make specific promises about timelines or features until further along in development. But here’s where we’re heading: In the medium term, my first major project on this team is to design and build a next-generation terrain system – what we’re calling the CBT system (it uses a Concurrent Binary Tree data structure, but it could also stand for Celestial Body Terrain). PQS+ has served us well, but nowadays video cards are much more flexible and there are more modern approaches that will give us better results in terms of performance and visual quality. Exciting new earth-shaking architectures are possible. The next-gen CBT system will be the topic of a future dev blog which will contain a much more detailed look at what we’re building. While it’s too early to share any details, I will say that I’m excited about the artistic expressiveness, potential terrain variety, and performance of the CBT system. Another area that will see a major shift in visual quality and performance is bringing the game up to Unity’s modern renderer, HDRP (read more about HDRP here if you’re curious, it rocks). The main benefits we get from HDRP are a more optimized render engine, which means faster framerates, and a more flexible shader model, which means more effective dev team efforts. It’ll also make it easier for visual mods to be built. As a sidenote, despite how much we love you modders, this change will definitely break most visual mods (sorry modders, sometimes we must hurt the ones we love). These in-progress changes will allow us to build more scientifically grounded yet fantastical worlds for the Kerbals to explore for years to come.

I love this part even more and think it's applicable in this situation... "6. Don't launch in Early Access without a playable game. If you have a tech demo, but not much gameplay yet, then it’s probably too early to launch in Early Access. If you are trying to test out a concept and haven't yet figured out what players are going to do in your game that makes it fun, then it's probably too early. You might want to start by giving out keys to select fans and getting input from a smaller and focused group before you release in Early Access. At a bare minimum, you will need a video trailer that shows gameplay. Even if you are asking for feedback that will impact gameplay, customers need something to start with in order to give informed feedback and suggestions." I had the hype for this game because of what we were told before release in interviews... It was big talk that was unnecessary seeing as they knew the state the game was going to be released in. I'm certainly in this for the long haul but it's valid that many are calling out a terrible release... It's barely playable at this stage.

i am glad there is some people left with some hope. i been fighting and backing them up in forums. never got a refund i pulled 89 hours in gameplay. and check and follow ksp2 channels every day most the day. hoping to read something that came from the devs. or see a update in my steam. but this last 2 days. i just falling down. and really just do not feel the ksp2 power. i feel like i am losing hope. what if they or leaving us. i never had a game that does not communicate with there buyers like this. don't say discord cause i am a discord user and i gone into there discord asking for help and no one would respond to me. but that is ok cause i asked for help all damn day in there and nothing. they talk but they don't care to answer simple questions. yea that made me so mad. i just kind of quit after that one. i love ksp i am a big fan of it. but i do not know. feels like meeting your fav sanger and they stick there nose up at you as they pass by. yea what ever. look i hope they do something but into i see some kind of action i guess i should just stand down drop my weapons' and pray this is not the end. i am not going to bash on ksp2.. i holding on to this last string but i just yea i don't know really what to say atm besides wish us all luck.

lol I should have known you'd have a director title. My latest gig I talk to the CEO and CTO of the studio every week or two to keep them updated, since I concepted the thing. Also an 8 figure project. But I'm a lead so I actually still do real work too, while the directors fluff about. Wouldn't have it any other way. Director might as well mean 'chief waste of other people's time' at most of the studios I've been at. Not all, there's an exception to every rule, but most. Did you know that Intercept has 6 Directors? (or had, Paul Furio got the ax) For a 50-ish person studio? Another reason they're so far behind. And I've worked for a couple of the big 1st party publisher/devs. Shipped on more than one 100+ person, billion dollar revenue product. It sucked but I'm glad I got the experience. And also shipped on a couple facebook games that were barely worth the few months it took to get them over the line, and I don't even put them as individual entities on my CV.. And titles all the way in between.

Probably a symptom of the whole project "We couldn't get enough done to be worth releasing it in 3 days... let's do a patch in one week." "We couldn't get enough done worth release in one week - let's push out a patch in two weeks". etc, etc. "We couldn't make a game worth releasing in 3 years - let's push it out another year!" Maybe Take2 management will have to step in to force them to release even a patch. Then the KSP2 hopefuls can talk about the patch being out too early when that patch adds new bugs. Somewhat kidding with the above, More seriously though - if their processes are not good enough to release a reasonable EA, there wasn't much hope they'd be releasing patches at a high cadence. I guess we'll see what it contains when it actually lands - who knows, maybe it will fix most of the significant issues.

I just watched @ShadowZone 's interview with Nate from just before release.* SZ's presumption is that the developers knew what condition the game was in - and that 'management' (my word) rushed / set an arbitrary date for them to release to EA. It had to go out on the date come hell or high water. And it did. Nate mentions the one thing that will likely be the biggest performance enhancement: refining the PQS System. (The Planet Making System) Given that that is likely a big overhaul, and my impression from the interview is that it was an ongoing project before the release... I don't expect it to be part of the first patch. It could be; I just don't expect it. He did talk about the process: Find the biggest resource hog, tame it; find the next biggest. Those actually sounded like two parallel processes - Taming PQS is a long term, not easily solved thing that is a work in progress - the other is regular refinement. So I would expect some performance enhancement with the patch... just not likely to be the one that causes FPS drops like those from looking at space as the background vs a planetary body as the background. Another thing from the video that comports with what I've seen over these last two weeks - there's a lot of stuff in this build that is wrong, that they could not have NOT known about. So the likelihood is that the patch work isn't just 'look what these intrepid players discovered' it's also fixing stuff they've known about for a while. Final note: while I've been doing my bug hunting and reporting stuff on the forums - I keep running into this line of thought where people are liquided that they haven't patched it yet. I think that wishing for a rushed patch is counter productive. My biggest gripe is how poorly the community interaction and contact has been. I get that a project this big has a lot of moving parts and there is greater risk from rushing a bad update out too soon than there is from taking their time and putting out a well thought, well coded patch later. I'm fine with that. But they should be talking to us. I've tried to explain this elsewhere - but let me try again. The Communications Strategy seems to be PrivateDivision driven - by an expectation that they were releasing a fun-to-play and largely functional game that was awaiting some key elements of 1.0 to be polished, and those big content releases would be fed to players in the order outlined in the roadmap. In other words, a functioning EA title. They have Ghostii doing fun tik-toks and showcasing quirky builds, people on Twitter doing fun things and linking to positive articles, they're all over Discord where people can just spam thoughts and they get large numbers of bodies daily -- all of which would be acceptable if the game was what we expected (and likely what PD wrote their Communication Strategy around) : functioning, fun and awaiting key elements. That strategy would be fine if the game were as performant as other EA titles - like Satisfactory (for example). The game did not release functioning like an EA title. It released like an Alpha/Beta hybrid with a few EA elements. You talk with Alpha/Beta players differently than you do with EA communities. You acknowledge the bugs. You collect the bugs - communicate priorities and tell the testers what you're working on. You under promise and over deliver. You don't ignore them - or keep up some semblance of your original marketing plan when the game is this buggy. Case in point: Dakota's content That's my beef. They're not communicating with us in any way that reflects the reality of the game. That failure of communication is actually accelerating the reputational harm. Increasing the frustration. They should be managing expectations - not ignoring them. * Video Link

Not really a discovery worth hashing into its own thread, but... Can we talk about how eclipses darken the surface of bodies now? I just discovered this while searching the Mun for anomalies, it's wild. Sun still has a lens flare but the mun's dayside surface is significantly darkened Ohhh, okay! Doing a little more discord digging, cause I seem to be unable to stop myself from attempting to gleam every little nugget of information possible about this game According again to Dakota, we might get a little more insight into the process of how the team approaches releases. Not that they haven't already communicated that they prefer bigger patches over a bunch of small ones, but, a little more elaboration on that will be nice.

I should preface this with saying that it is a hypothetical - I have no insider knowledge, and I wouldn't be able to share it if I did. So while I'm basing a lot of this on information we've had and my industry experience, there are educated guesses sprinkled in between. Anything I claim about motivations of people and companies behind this is entirely my own invention and I can be 100% wrong. People have seen a rough pre-recorded tech demo behind the closed doors at 2019 E3. Some phone-captured footage of it is floating around. I'm assuming, the original pitch for KSP2 was to base it heavily on KSP, give it a graphical update, and add colony mechanics and a second star system. You know how some sequels could have been a big DLC? That's what I suspect the original scope was. Star Theory seems to have been an even smaller studio*, and with T2 purchasing Squad in mid-2017, proper production of KSP2 at ST couldn't have started until late 2017. In order for them to be ready by early to mid-2020, I can't imagine the scope being much larger than that. In 2019, it was likely decided that there is enough interest to make it a bigger game. I imagine Nate S. was the main driving force behind that push from the Star Theory side, having a bigger creative pitch, one that would eventually become the KSP2 we know now, ready to go. I think the reception of KSP2 teaser at E3 was the big signal that everyone involved was waiting for, immediately giving a green light to that larger vision. So, you know, everyone who cheered for KSP2 at E3, well done. Unfortunately, that didn't go well for the Star Theory as a company. As we know, the negotiations for extended development time and budget broke down, Intercept was created, and KSP2 was effectively rebooted. * Star Theory was reportedly around 30 people before a fraction of these people jumped ship to the newly founded Intercept. Intercept's site currently claims 40 employees, but since ST was independent and Intercept is managed by the PD, I suspect a larger percentage of Intercept are directly involved in game development. So I would estimate the Intercept's dev team to be about 50% larger. That doesn't translate directly into time spent on a project, but it gives you a rough idea. Yeah, we knew that. The customizations have to do with time-warp stability and continuous collisions to prevent tunneling at large relative velocities on collision. There was also some talk of LoD for physics, effectively freezing some joints at certain times, but I don't know if that's been implemented. The actual collision detection, constraint solving, and rigid body simulation is on Unity's side. So this is exactly what we expected to find there.

No. They are a really frustrated user that really love the game and are losing the hope and doing whatever they can in a less than ideal attempt to get heard in the hopes this could change something. They need someone to hear them and to explain to them why things may not be so bad as it appears, why the people they think is the responsible for the mess may not be and, so, they are only making things more harsher for the dev that they need to be - what ends up increasing the risks of things going to the south. Something that I'm almost sure it's not what's they want, because - look - they didn't asked for the refund, they are yelling for the fix! Dude, this Fellow Kerbonaut didn't asked for a refund. They are fighting for something they want badly, and bickering with them will not improve things - au countraire, will cement the conviction that the ship is going to capsize. They need someone to talk with them acknowledging where they are right, where they are wrong, in a way that doesn't sounds like a spin doctor hired to save the Company's face on the Internet. You don't ask a paying customer "Are you a dev? A QA tester?", this never ends well. Sooner or later the dude will be, and so they will chew you and your team to their colleagues on the field, trashing the company's reputation - and when not, they will just give you the finger, taking their money back and giving it to your competition. While telling everybody why they decided to do so. Do you want this game to succeed or not?

problem is that everyone who's ever worked in IT (or most any other industry) knows that corporate talk like that rarely reflects reality. "we are tracking to deliver" means absolutely nothing. Team I'm in at the company I work are "tracking to deliver" our current project as well. We KNOW it won't be done by the deadline, doesn't mean we're not tracking progress. Meanwhile the blame game is going on full swing, people are seeking to hedge their positions and make sure as many higher ups as possible view their contributions in a positive light so when heads start rolling it will be others getting the axe.

I suggested performance improvements to kerbal space program support, and they requested I post it here because they thought it would greatly help the developers. First off, I love KSP2 and think it's a great game. Y'all added a lot of features I really appreciate, like procedural wings, coloring (man do I love coloring), and the SAS control and UI I like so much more. I'm also really excited for all the features in the roadmap. Secondly, I'll say what I believe to be true and what you should do working off of those assumptions. I don't mean to sound pretentious, just writing this because I want to help if at all possible. I could also be completely wrong because I don't have that much experience. I believe if you knew all this though, you wouldn't be having the performance issues you're currently having, but I could be wrong. If my assumptions are wrong then my suggestions won't help much either. My assumptions: KSP2 is currently built in Unity, which uses PhysX engine for its physics, which is really good for collision detection, but only that. Therefore, your structure is probably something along the lines of every part is a prefab, players then are basically dragging prefabs to build a ship that is then loaded into the world. These prefabs probably all inherit from some part class that handles gravity, joint force, and aerodynamics. Then fuel tanks and engines (where you're currently having performance issues when users add several) have additional scripts handling fuel and force application. This is probably all within FixedUpdate, which is called serially. This means that every single part is executing its script on the main thread sequentially, which is why some computers with good single CPUs instead of multicore CPUs are performing well. However, most modern CPUs are built with multiple cores and threading in mind because of how much more efficient it is. This doesn't matter though, because Unity's APIs aren't thread safe and prevent multithreading. Final assumption, you're not using the GPU for a lot of your calculations. Where I believe you can go from here working off of those assumptions: It's kind of infeasible to just improve performance. Like sure, you can make your functions better, but only so much better, and there are some calculations you just have to perform. Once you get to colonization you also get ridiculously large structures and physics. Unity may not support multithreading (which honestly at a colony part level won't help too much), but it does support compute shaders which would allow you to perform a massive amount of calculations very quickly. For most of your parts you probably have the same function, just different inputs depending on the size and shapes. Then engines probably all have the same script that handles fuel consumption, just different thrust and ISPs, which is perfect for compute shaders, which are really good at performing the same function with different inputs in parallel. Unity even allows you to pass structs to the compute shader, which means each part could be simplified to a struct of its various variables, and then sent to the compute shader. Each block of the compute shader could be a different function / calculation, i.e. aerodynamics, gravity, fuel consumption, and each thread a different part (or be really fancy and use textures for input output through rgba values). Meaning most modern computers will be able to handle 1024 parts at the exact same rate as 1 part, because most have about 1024 threads. Worst case scenario you only get 512 parts, but even so Unity's compute shaders allow for a third dimension which means expanding beyond 1024/512 parts is simple. Or if you don't have a GPU, it will default to the fastest device which will be your CPU and now you've threaded it since CPUs just simulate the GPU and thread if there isn't one. Basically, any where you have for loops, double for loops, or scripts on every part that perform the same calculation, you could probably offload to the GPU to increase performance. Concerns: - GPUs are slower. Yes. But if you have 1000 calculations and the CPU runs 3 times as fast (approximately maybe), the GPU does all 1000 calculations in 3 CPU time, because they are parallel. The CPU does 1000/3 = 333, which is a much bigger number than 3. - GPU answers are a large array you'd have to loop through on the CPU anyway. Just do thread reduction. - It'll slow down rendering since we're using the GPU now. Well, rendering waits for the CPU calculations, and your structure would look something like this CPU (initial calculations and storage) -> GPU (parallel calculations) -> CPU (handle those calculations and store them for the next frame) -> GPU (render). Besides, slower rendering doesn't really matter if your calculations are the bottleneck. - You don't have that many parts. Yea, actually the GPU is worse for if you only have like 10 calculations. Best I'd say is if you reach a threshold offload to GPU otherwise use CPU. But I imagine for colonization you will have to use the GPU. I have two examples, one using CUDA, the other a compute shader to prove how many calculations you can achieve. The compute shader performs collisions, collision reaction, and gravitational constants (which are bad for the GPU since there's a cube and a square root involved in the calculation) 1.04 e10 (like 10 billion ish) times a second (10 blocks of 1024 threads that have a for loop going over all 10240 objects at an average of 100 fps - given, I took a lot of shortcuts to make it stupid efficient which you won't exactly be able to do in Unity. 10 * 1024 * 10240 * 100). The CUDA program is the same principles as the compute shader wince it runs on a GPU, but the CUDA program has a reduction implementation that's quite simple since it's only thread reduction. It performs about 20,000,000 calculations in .3 seconds. If you partition each function onto a block you can do the block reduction on the CPU since block reduction is difficult and can be risky. You have to go back to the CPU anyway to store the information for later frames, and looping over blocks isn't going to be that long of a task. Both of these examples are using OpenGL and C, but Unity's compute shaders are pretty easy to use and comparable in principle, just use HLSL instead of GLSL. I have the repositories for the two examples but don't particularly won't to blast my personal information so if requested I'll send links to them (they have my name and some info and such). I hope this is helpful and you didn't already know all of this and I just sound like a jerk. I think that with great performance nobody cares as much about bugs since they can just immediately restart and not be waiting 10 minutes to see results again. I think performance is especially important since you want to make science accessible to everyone, and most people not properly exposed to science don't have modern hardware. I'd also be happy to talk through some questions or concerns if you have any. Thank you for your time.

The information below is just my guess about what happened during the development of the game from a conceptual and software engineering point of view. I talk about some of the major challenges that had to be tackled by the dev team - which caused the delays and are the main reason for the current state of the game at EA release. Please be tolerant of my many suppositions. TLDR: cut the development team some slack.. they've worked a lot during the past years and we don't see most of the work yet. It will all be clear as we step through the roadmap and the game will speak for itself and for the team. Prototyping, refactoring, rewriting Based on things mentioned during interviews, I believe that KSP1 with mods was initially used for prototyping, then there was a major refactoring of the game after which the Star Theory drama happened.. which I think forced the devs to do a major / complete rewrite of the game. As you can imagine, after announcing delays, the developers probably wanted to do something more ambitious than just an improved version of KSP1. So... Interstellar - "simulating a multi-light-year spanning 3D volume at a sub-millimeter level of resolution" The "problem" with KSP is that it's played by very smart people that know and love science and technology. It's meant to be a realistic simulation of space travel and a lot of other things. This is kind of a trap for game design because it means avoiding instancing and other tricks. Blame Descartes for making us think about space as it's own thing (Cartesian system) instead of relationships between object. If spaceships were teleported from one star system to another we wouldn't have all the issues people complain about. But... "...we're enabling players to travel from planet A orbiting star B to planet C orbiting star D, continuously, without any loading screens, pauses, faked out transitions, "warp drives", or other trickery. We're simulating a multi-light-year spanning 3D volume at a sub-millimeter level of resolution, and enabling players to travel to any point in that space if they can build a ship capable of making the journey. Unprecedented in gaming." - Paul Furio, the Senior Engineering Manager / Technical Director at Intercept / Private Division, April 2022 This is why I wouldn't be quick to judge the work of Paul and the developers. They tackled something that is generally only done using supercomputers. We're talking about distances that are just incomprehensibly large for the human mind. It's a HARD problem and solving it is groundbreaking for gaming. Add the need for a trajectory solver that takes acceleration into account and it all gets very complicated. Multiplayer - solving the time-warp problem and delivery routes As many of you know, I've written about my wishes, dreams and theories related to multiplayer. I might be wrong, I might be right. After thinking about it .. a lot .. I have come to the conclusion that asynchronous multiplayer that allows time-warp in space (and other features like delivery routes) requires an innovative and complex system of recording events and placing them on a common timeline. If the devs chose this route, it is/was very hard to implement and I'm sure it took a lot of time. Actually, because it's built on top of the previously mentioned simulation system.. it's even more complicated. Early Access - stripping down the game for EA IMO this was done in a hurry and has generated the most bugs because you have to work around a lot of issues caused by the way fundamental systems interact in the game. Why was it done in a hurry? Your guess is as good as mine. But certainly the game would have benefited from another 2 months of testing and debugging. Is this reason enough to be disappointed or hostile? Of course not, bugs will be fixed. And then we also have: Creating the teams, processes and development pipeline Creating the new PQS system for celestial bodies (the textures and details are there in the internal builds, but there's not enough performance budget to use them for now) Parts mechanics for vehicles and colonies Physics (aero, liquid etc.) Creating / iterating the user interface (which seems to have been left to the last moment - which has generated bugs) Performance optimizations (this is usually done at the end of development and I don't think is the biggest issue for now) The scale of the project is GIGANTIC from a software development point of view. It's innovative work. So please cut the development team some slack and support them. Thank you, Paul Furio, for all your work! It will not go unnoticed and unappreciated by the community, I assure you. Have a listen to this older KSP2 related podcast with Nate and Paul: http://forum.purdueseds.space/pspodcast/episode2/ For specific dates please check out this great timeline created by @DrCHIVES.

I would keep it in 3D the only thing it would require is some random reason to have at least 1 person in it that actually can talk ^^ I also dont think that Anime could really capture what is important in KSP - showing off space, space flight and awesome planets etc. I sometimes wonder if Minions were inspired by KSP aswell - even their piloting skills are the same ^^ - I think a similar artstyle would be a perfect fit:

KSP 2: Dishonored 3 Some decided to cancel the job, distracting from game; some were caught by their manager, while playing at the workplace; some failed university trials, and had to join the army. At the moment it looks like the behemoth was for seweral several years giving milk without pretending to anything but a part of the future profit. Yet nobody complained about changes forced by the behemoth, in-game commercials, or microtransactions. The only thing the behemoth is blamed for, is that they forced to release the game too early, after just four years of successful development. The design is ok, the code looks isn't. These are different people. If they had, how could they test it? A wobbling planetary base? At least, they have successfully ported Kraken from KSP-1. The colonies can wait, but Kraken is a mascot, it's a Kerbal must-have. presume Maybe, this is exactly what's optimized. And that's the answer about the colonies. Btw, some colonies are put on ground. What about the FPS on the ground view at KSC? They'll talk to T2. Futile excuses. You're just haggling over $50, and thinking out some unrealistic, fantastic, impossible requirements. *** I haven't purchased this game exactly for the reason I said a couple of years ago. Only when the essential KSP-1 mods will be ported to KSP-2 it will make sense to migrate. But looking at the system requirements and the game itself, I think that once I have upgraded my hardware to the requirements of KSP-2, I will better add 50 more mods to my KSP-1.

I want information that actually makes me feel secure about a purchase for 50 USD. I know what he said but i also found it weird how he said it which is why i pointed at the things i wanted more clarity about. If there are layoffs coming and the general reviews are negative its not very reassuring when someone writes "continuing as planned and we will continue to provide updates about the game throughout the coming weeks and months" - at least to me when the game is probably far away from a release within the next year. But yes maybe im reading to much into it - who knows. Also messages as "KSP2's development is continuing as planned " isnt very reassuring to me when the next news i read is that the Technical Director leaves because of cut costs. The person that "Lead the engineering team that built Kerbal Space Program 2". If t his wasnt EA i would have way less questions but EA means that consumers suddenly take a business risk at almost full AAA price - people should have questions. I do realize that he probably doesnt know everything and cant say everything still - when the purchase of a product actually inclucudes a lot of risk since its not a pre-order its obvious that i want more clear answers - but thats probably not his job - but maybe he can talk internally and maybe they can make some official statements to reassure their customers and potential customers. This would be different if it wasnt an EA release.

We're here to talk about a game, not to criticize each other's behavior and motives. For that reason, specifics of the person in question have been removed. Also, the creator of a thread can always ask the moderators to close that thread. He or she doesn't even need to give a reason, and we're not going to guess at what it is.

What specific questions did you have in mind? I would be curious to know how Intercept was affected by the layoffs. We know about the lead engineer, but were there others? The thing is that it’s really not OK for Intercept to announce this about individuals or individual roles that would let people figure out exactly who was let go (except executives). That’s personal information. You don’t do that to people. But I agree that a bit more communication could help, like, how many roles were cut? When did Intercept know about them? Other than that, what could they say to allay worries? I can’t think of much TBH. They’ve already said development continues apace and according to plan. You can choose to take that at face value, or not, but what more could they say to convince you? The problem is that fans aren’t reasonable people you can talk to reasonably. You can share your internal roadmap with reasonable people because they understand that it’s subject to change; the milestones can change and things can even be dropped from it altogether. You can’t do that with fans because imagine the reaction if, say, they have wind, rain, and snow on it, and later on it gets cut. It would be just a continuous outrage machine. I really wish fan culture would change so there could be more direct and “adult” communication between studios and fans but I just don’t see that happening. You’re by far one of the more reasonable fans @RayneCloud but even you are showing a quite a bit of fan entitlement in some of your posts — and it’s precisely that which makes studios hide behind baby-talk and corpo-speak. You don’t want to say anything to provoke another hissy-fit so you end up provoking one but not saying anything. In sum a big ❤️ to community managers everywhere who have to deal with us. We suck, yet you manage to remain almost invariably positive with us.

I remain as supportive, positive, and optimistic as I possibly can be. However, the public news of layoffs, the review scores, the absolute denial and "all is well!" "just do another weekly challenge!" attitude is not helping. Not when 50% of the community has an extremely degraded gameplay experience, and the viewpoint is that there is a straight up refusal to address the communities fears and worries. The fears and worries being that KSP 2 will not see a completed road map. We need, and deserve, answers. Not corp speak, answers. We need and deserve communication, not "in the coming days and weeks and months" Now. Talk to us, the community, and answer our questions, honestly. Please. Side Note: This is not an "Oh god even Rayne is scared!" situation. I've been supportive, positive, and over all optimistic and I will remain so, but todays news of layoffs was an incredibly huge blow to my own moral and hopes and dreams of KSP2 as a player and a lover of this franchise. It was a huge blow to the morale, faith, and overall atmosphere of the community. That, is why I am asking for answers. So in short, Talk to us, please. Respectfully, Rayne.

Haha zero difference. Oh well. Can we at least talk about how much nicer everything is? or will be when it gets ironed out? OMG the base game is amazing. The ease of part connects, every click (when they work) is better. Things are so clean. I wasn't around playing KSP1 when it was EA, but I've watched it grow over the last half decade. The groundwork that is laid here will be built on so amazingly. I'm glad the haters cant kill this game. I'd hate it if it went the way of cyberpunk because people cant manage expectations.

But rule 5 doesn't state that. It states that if you have an issue such as that in your EA build, you need to communicate that clearly and concisely everywhere you talk about your game. So one could argue that since Intercept might have known that, and they certainly didn't communicate it anywhere that I'm aware of, it could be a consideration for counting as unplayable. Just not so sure where you got the idea that it implicitly stated that the game save issue isn't an unplayable qualifier, especially considering no one knew about it until release, though the devs might have.

If we get nothing good out of defending the devs, then, once again, what good do you think you gonna make by simply blaming them? "Weeks" is acceptable, because there is nothing left for you to do than to accept the fact and live on with it. If you think otherwise, go talk to the management, make them rehash their processes in the studio, maybe learn something and get employed to kill bugs and help the devs make patches faster. Whining on the forums doesn't help. But something tells me, that gamedev professionals already know all the things you are going to tell them, and maybe some more. Like the inside kitchen of the project, that makes it that much harder to bring to life in reality, compared to perfect world you are imagining.