K^2

These specs are above the recommended. Performance-wise, if you're seeing slow framerates, it's because everyone's seeing slow framerates in that situation. Unless something's just straight up broken, which you'd probably notice, there's nothing wrong with that setup.

You keep saying that, but you refuse to tell me what is the opportunity I'm missing out on. What am I supposed to do with these $50? Buy another game? I already bought the games I want to play. I don't have time to play more games. If I buy another one, it just sits in my Steam library. That's an actual waste of money. Invest it? Then the cost of opportunity is the interest on $50. That's a cup of coffee over the next few years if things go well for my investment. Not meaningful. What is the opportunity that I'm missing? Or, you know, I can do that for a game I'm actually paid to develop. I'd have to undercut Steam to make any sales. Even if I was going to buy the keys for $50, and they were going for $70, maybe I could sell for $60. (Though, there are so many key scams, that "Trust me, this is a good key for $60," is not always a convincing pitch.) Then pay the cut to the storefront where I did the sales (or roll my own, advertise it somehow, still pay a cut to Stripe or whomever). Then do all the tax work. If I make a 5% RoI on these keys, I'd be lucky. And that's if the game doesn't release for $60, which is a real possibility here. Why would I do any of that? I can dump money I can invest into my mortgage principal and get 4% over the next couple of decades. And that takes a couple of clicks for me. Why would I want the headache above? Money shouldn't be a foreign concept that needs to be explained like this. Unless you're still in college, and probably even if you are, you should have better grasp of finances and what is actually worth doing and what's an absolute waste of time if not an actual waste of money.

I've provided details in a number of threads over a number of years. But to save you trouble, here's Kat in a nutshell: Particle Theory, ABD. Two startups, two AAA studios, one mid-size, and a FAANG company in no particular order. One published paper. Two software patents, both implemented in shipped games. Two shipped products. Three shipped games, about to ship a fourth. Two you know, two you might have heard of. For the past four years or so, I've been leading teams with total head counts from 3 to 7 engineers, including various combinations of direct reports, indirect reports, and contractors. That includes hiring, performance reviews, promotions, road maps, sprint planning, and milestone approval processes. On the engineering side, I specialize in bespoke engines, with focus on physics and animation and everything that heavily involves, like memory management, numerical performance optimization, and threading.

Which is fair! The statement was always a conditional.

Generally, you'd place these on a radial decouplers, so that they can be jettisoned, not attach them directly to the main body. They will wobble quite a bit if you don't add struts, though. I would add at least one strut near the bottom of the side tank and one near the top, connecting it to the central body. All of this, starting with placing the decouplers, should be done in 6-way radial symmetry mode. I have seen a symmetry mode bug where physics joints just aren't created, but that tends to happen when you try to build a sub-assembly with its own symmetries, then attach the sub-assemblies in a symmetry mode. Hopefully, that gets fixed, as it's annoying. But simply building out the side tanks in place seems to work just fine.

In this analogy, I already got the cars I wanted now. I don't have the time to drive more cars, and the rare wreck that I, personally, have confidence will get fixed, makes for a nice conversation piece in the meanwhile. Again, I repeat, if spending money on KSP2 EA right now blocks someone from buying and enjoying another game right now, they shouldn't be buying KSP2 EA. A lot of people here are time-limited in how many games they can enjoy, not budget-limited. That doesn't mean that simply throwing away $50 would be sensible, but it drastically alters the marginal utility of spending the money now vs later. Well, then we don't really have a topic for conversation. Wait for a deep sale. Even if KSP2 EA was flawless, if this is your stance, you still want to wait for the full release, then another few months, and pick it up during one of the Steam's holiday sales, and the state of the game makes absolutely zero impact on that decision. Either you take the position that it is sometimes worth to buy the game for its full price, or you take the position that you should always wait for a sale. I'm not saying that either one of these is wrong - it's honestly a personal choice involving a multitude of your own preferences and even, to some extent, your self-restraint of buying something while it's new and shiny. But you can't have it both ways. Either you wait for sales, and then you're not the demographic for this game - PD is not going to get the full price out of you anyways, so why should they give you a discount now? Or you're the kind of person who will purchase the games early after the release, and then we go back to the balance described above. Either one's fine, but you have to recognize that people who are making the other decision aren't acting irrationally. They have a different preference and marginal utility of the money they can spend on games.

Why does that factor into it? If I'm sure that I'll buy the game eventually, what is the actual difference between me spending $50 now or $50 then. (I'm not even considering the likely price increase. Forget about it. I'm not trying to save on the difference here.) The net loss to me is $50 either way. The difference is that I get to try the game and see how the development is going and to have something to compare it to as the game gets finished. I can try it for an hour and decide it's unplayable. (In reality, I've put in about 20 hours total by now.) Or I don't do any of that, and still get the full game later on. Either experience costs me $50. Where am I taking a loss by getting the early access now? At 35% off from $70, it's still $45. I'm sure I can look for a deeper discount at some arbitrary point in the future, but then by that logic, spending $70 for any game ever is stupid, because it will go for $20 eventually. Again, I'm not trying to save $5 here. We're talking about the bulk of the purchase for someone who would get the game day one or near that when the game is finished. You clearly don't think the game will ever be finished or be good. You shouldn't be getting early access. And that's fine. I'm not sure why you're trying to convince other people that your pessimism is the only rational state of being, and everyone else is an idiot, without any relevant experience to actually help you make predictions like that. You can make your own decision. Unlike you, I'm not trying to convince you to buy the game. And I'm not trying to convince anyone else to buy the game. At this point, you're just being a person on a soapbox telling everyone the end is near.

You're making a strawman. If you aren't confident that you'll want KSP2 when it's finished, you shouldn't get early access. That's true of literally any game in early access. Don't buy early access if you aren't certain you'll want the finished game. That's not a controversial statement. So the only people who might consider getting early access are people who are pretty sure they'll buy KSP2 when it hits 1.0. That's the only assumption about quality being made up there. Again, it's a necessary one for anyone to consider early access of any game. KSP2 doesn't have to be perfect for this to be true. It doesn't even have to be great. Just of sufficient quality for someone to make that purchase eventually. Everything else is covered in a point-by-point. If you don't understand it, feel free to ask questions and I'll walk you through in more details. If you have a problem with a specific assumption, you can bring it up and suggest modifications. Right now, you're just presenting a strawman argument and thinking yourself clever.

If you have gateways that talk to both protocols, and can implement tunnels for the parts of the network that doesn't support one or the other, then the network remains fully connected. It's a bit like tunneling IPv4 traffic over IPv6 or vice versa. In practice, I expect Russia not to have resources to implement a new protocol at all, because where are they going to get enough custom switches even from? And China isn't going to shoot itself in the foot so hard as to cut themselves off from the WWW. I fully expect China to have gateways and tunnels natively supporting TCP/IP.

You are making it way more complicated than it needs to be. Simplification time. Forget about the price change. Forget about the inflation, investment opportunities, etc. You and I both agree that the impact of these is minimal. For the purpose of keeping it simple, make following assumptions: Game costs $50 today. (Rounding, ignoring tax.) The game will get finished eventually, even if it's 10 years from now. (Fiat for the purpose of discussion.) The game will cost $50 when it's fully released. (Or if it's a bit more expensive, you can get it on sale.) The buying power of $50 is going to be the same now and ten years from now. (This estimate gets worse the further off the release, but lets keep it simple.) Your options for these $50 are: Buy KSP2 Early Access. Put $50 in your checking account, and buy KSP2 1.0 when it's ready. I'm intentionally ignoring possibility of using that $50 to buy something else, not KSP-related, because that's exactly the opportunity cost addressed earlier. In this case, the cost to me of getting KSP2 EA now is zero. The $50 is already destined to pay for a copy of KSP2. It can happen now, or it can happen at some indeterminate point in the future. There are no other outcomes that give me a different value. The only difference is do I have access to EA or do I have $50 sitting idly in my checking account. In one case, I'm getting value out of it, even if absolutely marginal, and in another I get zero value. In order for this equation to change, there has to be an alternative use for the $50. Like buying a different game. But then it's not a strict alternative either. You don't get $50 to spend on games for your life ever. You're not just choosing between buying KSP2 now and buying something else and not buying KSP2 at all. So lets modify it to reflect something a bit more realistic. You get $50 in your games budget every X days. There is an effectively infinite pool of games you can buy for $50 each. On average, you play a good game from the pool for Y days. KSP2 is available as EA in the pool of games, and will eventually hit 1.0 where it becomes a game you want to play. In this simple model, there are only two outcomes. X > Y - you are money-limited, and you are always looking for a new game to play. If you buy KSP2 EA now, you don't buy a game you want, and spend the next X days not having a good new game to play. Your opportunity cost in this case is the full $50 - or its utility equivalent of X days of playtime. Y > X - you are time-limited, and you always have available budget to pick up the next game. If you buy KSP2 EA, absolutely nothing changes. You still play all the other games from the pool until KSP2 1.0 is released. In case 1, the opportunity cost is $50. In case 2, opportunity cost is $0. In the real world, all of this gets more complicated, but you still have the same end points. The "cost" of playing Early Access is somewhere in that $0 to $50 range that will vary from every person's preferences, time available for gaming, and financial situation.

I think you misunderstand what an opportunity cost is. The opportunity is to spend $50 on something else right now. Say, all I had was $50 to spend on games for the next X months. Would it make sense for me to get KSP2 EA? Absolutely not. There are a lot of better games I can play in the meanwhile. Locking up these $50 in early access, even if I'm sure it will come through eventually, would make no sense. In contrast, the situation I have is that I'm going to be able to get the games I will actually have time to play either way. And whether that $50 ends up in my savings/investment account and sits there until KSP2 releases, or I just pick it up now doesn't really make a financial difference to me. Not the kind that's going to matter. It's all within a cup of coffee difference at the most. So what's the downside of getting the early access and trying it out in this case? These are the two endpoints on the opportunity cost analysis here. There is an entire spectrum in between. The monetary value of the opportunity cost will land somewhere between $0 to $50 depending not only on each person's financial situation, but also on how they budget their finances and how easy it is to amortize the $50 now vs later. So it will always be a fraction of these $50.

From a purely utilitarian perspective, the cost of participating in early access comes down to two factors: How certain are you that the game will eventually be playable, and you will purchase it? And what is the opportunity cost of shelling out the $50 now? That is, is there anything else you'd be missing out on because you spent the money already? I'm fairly confident that KSP2 will get done, and will be interesting enough for me to buy it at full price. Even if things are going a lot worse than I think, and there will be some shakeups in the studio forced by PD, and the game eventually releases in full in 2025 - just to imagine a particularly bad scenario, whether I spend $50 now or $60 then isn't really impactful. There's a chance that the game doesn't get finished at all, and then I'm effectively out of $50. I think the risk is very low, and it won't hurt me much if I'm wrong. So for me, the effective cost of participating is very close to nothing. That math won't work out the same way for everyone. For some people, spending $50 on KSP2 now would mean not getting to enjoy something else they wanted to buy. In these kinds of situations, pre-orders and early access of any kind are just a bad idea. Hold on to your money until you know what you're getting. Alternatively, some people might be very pessimistic about the development so far, and evaluate the risk very differently. If the risk of the game not finishing is very high, then the expectation value for the cost of participating in the early access goes up to as high as the full $50 in the worst case. The concern is valid, and I would absolutely make sure that if I'm making a recommendation, the person I'm telling this to is fully informed about the state of the game, the delays, and anything else that might impact their evaluation of the risk. But simply deciding for another person that, "Nah, it's not worth $50," is unfair to them as well.

I think, for someone who both enjoys KSP and is interested in getting into game development, this might be a good recommendation. Like, a lot of things one has to do with KSP2 to get it to cooperate are the sort of things you end up doing with a game during development. Being able to both reproduce a known bug reliably and to step around a known back reliably are survival skills.

This is effectively an alpha build of the game. It's playable, but only just enough. There will be fixes and patches over the coming months, but it will be some time before the game is ready to be really played. For now, see it more as a preview. There is a Bug Workaround Thread if you want to try and get some missions going anyways. Otherwise, the only thing to do is wait.

No plan survives contact with the enemy. But I agree, they needed to communicate this better. More frequent, more detailed, and not stepping on the same rakes over and over. I get that there is probably some tension between Intercept and PD on what should be communicated, how, and when, but that's true of basically any developer-publisher relationship, and a lot of them find a way around that to deliver a more consistent narrative.

I don't disagree, but for the purposes of the forum ToS, modding in general is fine, but anything that involves code decompiling is going over the line. Or so I've been informed last time I brought up decompiling as an option.

I don't know if you've looked around any KSP2 modding communities, but they're doing some really cool stuff already. Of course, at this point, it's all involving EULA-violating kind of code scraping, since there's no SDK, so I can't link to any examples, and we'll probably have to wait for some official mod support before that changes. But the community is already forming, and that's good to see.

I don't know, modern mod managers for Skyrim, with virtual file systems, where you can create different configurations without having to go and delete everything, as well as being able to quickly and safely toggle things on and off, are rather nice. I haven't been able to get that level of mod management in KSP1. Maybe I haven't looked hard enough, though. On the net I agree. KSP1 has some decent mods, and good community support overall. The way the assets are loaded hurts scalability in mods quite a bit, which is a hassle, of course, but not a deal breaker for a lot of people. Some people just don't like playing with mods, though. And that's something that has to be kept in mind when comparing games. For some people, the fact that some of the problems that KSP2 addresses that could be solved with mods in KSP1 removes all advantage of KSP2 over KSP1. For others, mods aren't a viable option, and KSP1 just doesn't have these features. And then there is a whole spectrum in between. None of these positions are wrong. These are different demographics, and success of KSP2 isn't going to be measured by just one of these groups of players.

- "There is a secret pixel you have to click to open this sub-menu." - "A secret pixel?" - "A secret pixel."

Oh, no. The shadow map is not blurred! Unacceptable! I'm going to complain to the highest authority! I'm going straight to Carmack with this. People who don't know anything about rendering trying to hunt for visual artifacts is always funny to me. Tell you what, you won't take the word of anyone here. Why don't you find a rendering community somewhere, get them to comment on the screenshots, and ask them if this is something that's total garbage and the devs wasted years of work for nothing, or if this is totally normal for an alpha build of the game. Let us know how that goes.

It's getting better in a lot of places. People calling attention to it in social media, and both the popular backlash and various stricter labor laws (esp. in California) have been pushing the needle in the right direction.

If you've taken a deep dive into how it's currently set up, I'm prepared to take your word for it.

That's about the worst take I've seen, and I've seen a lot of bad takes. First of all, a lot of the stress comes from heavy mental workload. I don't know what you do for a living, but you clearly never had to solve a problem that's actually new and takes more than five minutes to think of a solution to. So we can basically exclude any software work from the list of things you've ever attempted. Second, if I'm working at Google, as I have, and I screwed something up, and it caused our service to fall for a few minutes while the revert is being processed, do you realize how little I care about it? It might cost Google a few million, if it's an important enough service, but I don't give a damn. There is no consequence for anything you do, and it gets boring after a while. I left precisely because there is zero impact. Most software jobs are like that. Yeah, there are a handful of people working on things like self-driving cars and crewed Falcon missions. If you screw up on one of these, it'll get people killed. Though, it's super unlikely that you'd ever be able to trace it down to a mistake any one person made. Some people can manage that better than others, and it's not a job for just anyone. Other than that, though? Medical and military software goes through so many validation checks... The only place where you have to follow more strict guidelines is software for slot machines. It takes enormous level of carelessness from the corporate for any one engineer's mistakes to propagate to an issue that causes people to die, at which point, it's not on the engineer. It's an extremely different environment. Security is somewhere in between. Realistically, though, nobody works in security feels that sort of personal responsibility for people losing money due to leaks. Again, it's closer to the impact of just a general corporate work. What sets gaming industry aside is that we're all working on things we actually personally care about. Nobody goes into games for the money or prestige. You go into games because you want to make games. And it's not about making some little brat happy about playing a game. It's about making an art piece that you're proud of. And when you screw up as an engineer on a game, you're not letting down the corporate or the gamers. You're letting down your colleagues in art and design, who have worked for months on a feature, that now either can't be shipped or works like total crap, because you didn't fix something in code. Or you weren't able to solve an optimization problem. You're not letting down some arbitrary person out there. Someone you'll never know or hear from. You're letting down people you work with day after day for many years, many of whom become your close friends. I have experience across variety of sectors. Academia, where I started, corporate giants, like Google and a certain media company I do not even wish to name. Several games-adjacent startups that were sort of related, but where it still felt more like just a job in fintech than anything creative, and a number of large and small gaming studios. I've never worked on a project involving autonomous guidance, where I'm literally holding someone's life in my hands. I suspect I'd hate that, and they are probably under more stress than anyone in the tech industry. But outside of that, games are the easy second. No security or financial works come close. Your attitude is ignorant, based on nothing but your own imagination, and is toxic to the industry. I've taken vacation time two months before we had to ship a feature that we were on an X million dollar contract to deliver along with the game, while I was acting as a tech manager for that feature from distributing work to certain aspects of negotiation with the corporate entity that was paying us for it. We were running behind, because the entire project was on fire, and my engineering and art resources were constantly getting pulled from me. I had that vacation time scheduled from way before, back when we were still supposed to have the feature already delivered by that point in time, and I refused to shift it. Two reasons. First, I was tired and I needed this time. I already scheduled it for way further out than I was supposed to, and I was already losing PTO hours due to them being unused. But more importantly, I knew that if I don't take this time, nobody on my team would, and these final two months would be absolutely devastating, because the entire game was far behind schedule. I've made my vacation public within the relevant teams. I publicly asked not to be disturbed while on that vacation. I've also privately made sure that people who might need to reach me for some emergency could. Two or three people from my team have requested PTO after that, people I knew needed it, and nobody from upper management tried to fight me on approving it because that would be bad optics if I had my PTO already approved. We shipped the feature on time. We got the payout for delivering it, we got praised for it in game reviews, and five names from my team ended up on a patent for a certain part of that feature. It's purely a defensive patent, but my team still got bonuses for it, and it looks good on the resume. If you are leading an exhausted team during difficult part of development, it's critical to make a big show out of taking PTO, because some people will absolutely not take the PTO they desperately need because they feel like they're letting the team down. If you, as a manager, don't set a good example on good work practices, who will? I don't know what the exact situation is at the Intercept. I don't know exact causes for the delays. I've said before and I'm saying this still - they shipped a decent alpha. Some problems, sure, but nothing that wouldn't get green-lit to go into the next milestone, and absolutely nothing like a disaster some people here try to claim it to be. Yes, people are used to seeing betas in early access, but the business case for an indy studio releasing beta as early access is very different than publisher-backed studio releasing an alpha build. So I don't know to what degree the Intercept has been mismanaged if at all. All we know is that the game is taking longer to develop than it was estimated from a few years back, and we don't know the exact causes of that. So with all of that in mind, do I think Nate has done the right thing about publicly taking vacation right now? I don't know. What I know is that there are good, legitimate reasons to do so, and I don't have enough information to call it a misstep. Even in terms of how it was communicated, because that wasn't for your benefit. That was for the benefit of the team that worked hard, and might not take the vacation if all they're seeing is harsh criticism from the forum and are thinking they're letting their colleagues down. And if that's the reason it was done the way it was done, then it was the right call.

I haven't experimented with it myself yet, but the documentation and tutorials suggest that you can go mixed bag. You only need simulated parts to be in ECS. So all of the game logic, FX systems, UI, etc can be kept in GameObject format. And the way the game relies on modules, apparently for moddability, the GameObject scripts for the parts are merely invoking these, it would seem. The cross section of code that has to be replaced might actually not be that great. That might actually be more work. If you go this way, you have to manage the collision scene pretty much manually. Anything with collisions will have to introduce or remove itself from the scene. Dynamic objects will have to update their possitions on every game tick. Terrain's LOD and streaming will have to be tightly integrated into this setup. Any FX that might need collision data will have to be completely redone, and any game logic that uses collisions re-written, which includes wheels, lander legs, kerbals, and colony placement and editor. Some of it is still going to have to be touched even with ECS Havok, but with custom Havok it's basically everything. It's an option, but I'm not convinced it's an easier option. And same constraints on time would certainly apply.

This is all fairly well known. Well, at least if you work with physics engines. I won't go as far as saying that KSH wasted their time testing it, because it's always good to fact-check yourself, but the results are nothing new. Unreal's Chaos might be a new entry for some people, but I was actually doing similar testing for a different studio a couple of years ago, and we had reached similar conclusions. So on paper, yes, the new Havok, which is available in Unity, is a far better choice than basically any other off-the-shelf solution on the market, and all else being the same it would be a fantastic replacement for KSP2. Unfortunately, switching KSP2 to Havok would likely require a significant overhaul of the game at this point. In particular, enabling Havok requires switching from GameObject model of Unity over to the ECS model. At the time that KSP2 would have been kicked off at Intercept, this was only supported as a preview, IIRC. ECS became a production-supported feature some time last year. If the game was only starting production now, I think it'd be an easy choice. Retrofitting KSP2 with Havok now, however, is a much trickier proposition. In principle, converting the components themselves shouldn't be too much work. Looking at the saves and modules setup, there might actually be one main component script that makes calls to relevant modules based on what's hooked up for any given part. (So, like, an engine part will have an engine module hooked up in the script. And it's the engine module that will do all of the actual updates to make the engine work.) Alternatively, there could be a unique script for each type of module, in which case, there would be more scripts to convert, but even then, it should be fairly boilerplate on the surface. Lots of copy-and-pasting. The problem is that this will upset all the thread timings, as the GameObject scripts and ECS scripts are executed fundamentally differently by Unity. For GameObject components, the game objects are updated one at a time, each of its component scripts running in sequence. For ECS components, every type of component is updated together independently of the entity (part) that these components belong to. If built properly, that should actually improve the game's performance, as the workload is easier to split between threads under ECS, but if these threads start modifying shared data, the quick fix is mutexes... Long story short, you might end up with a significant performance degradation that you would then have to fix. Likewise, a lot of new crashes and memory leaks are likely to result from it, and these would also have to be fixed. The game's quality is likely to get worse, and might potentially require a huge amount of work to bring it back to even the state that the early access is in right now. tl; dr: It's a huge risk. Even in the optimistic outcome, I'm not sure there is time for this work right now. In the worst case, if Intercept starts this, we'll get our next update some time next year. I don't have all the info to say for sure that this is impossible, but based on what I've read about this tech over the past year or so, it doesn't seem to be viable at the moment. Once the game is shipped, and we get a few patches, assuming that the game does well enough for the work on it to continue, and if there is a quieter moment before Intercept has to ship the DLCs, there might be time to attempt switching from GameObject to ECS. If that's done, actually toggling on Havok is trivial. But that's a lot of conditionals, and best possible ETA of late 2024. With all of that in mind, Intercept has to figure out how to make the game play sufficiently well with PhysX. I don't think there's a magic bullet approach that lets them bypass that.