K^2

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.

Fixed that for you.

You haven't. You specifically stated that you only have a problem with it being communicated - though, being silent about it contributes to toxic culture, which is a separate problem. But aside from that, other people have, quite directly, stated that they have a problem with the concept itself. Either because they went to a conference (which is unavoidably making public that they are taking time to do something else) or explicitly that they shouldn't be taking holidays at all at this time. I do when that vacation is during a disaster or other urgent need. It's something I'd never for a second consider doing myself, so I'm shocked when I see someone else do it. So rather than telling me to take a deep breath, why not take a moment and see who and what the discussion is aimed at and consider for a moment if you have a problem with demands quoted above. Also, not a fan of "dude" as a vocative expression directed at me. Please, consider alternatives if you'll need to similarly punctuate a dismissive remark directed at me in the future.

Not to mention that there is a perfectly neat, anti-aliased line under the same angle right next to it. "I see something that looks like a jagged line, so I'm going to claim it's a rendering artifact, even though it doesn't align to the quantization grid and shows up uniquely on this geometry and nothing else."

So wait, when you made your comment about being "built different," you meant constant underperforming? Because otherwise your comments don't add up. You should probably revise that. More importantly, and actually to the point, if the product is bad because my team shipped bad code, if I drive them harder and make them work more, they'll just ship even more bad code. If I thought the team underperformed because they're burned out, I might send them on a vacation and fix things properly later. Yes, it's a delay, but you get better product eventually rather than more crap. If I thought they were lacking experience, maybe a conference is a place they can pick up a few techniques. Finally, if they're actually just bad at their work, either because they're simply not good at it or because they don't do the work (and we've crossed solvable problems off the list), then I start the process to terminate the employment. There is absolutely no universe in which devs shipping a bad game is fixed by having these devs sent back to the office to work harder. That's just doing the same thing again and expecting a different result. And that's if it's even their fault to begin with. The schedule for the project overall could have been unrealistically aggressive. Priorities might have shifted really late in development. Build and test pipelines might not have been in place. What if the tech art was knocking it out of the park, but rendering engineers didn't realize until really late that there is a problem with the pipeline, and now a bunch of shaders have to be re-made? The tech art team is now behind, but they did everything right. They were never underperforming, but now they have to go back and work instead of taking their earned rest? Make it make sense. If after shipping a bad game, you deny people vacation, the only people you're punishing by that are people who worked hard in the first place, and these people can easily find other jobs. And then you're left with just the underperforming ones who are going to make an even bigger mess of things. So again, not a wise strategy under any circumstance.

I've been leading game dev teams for several years now, and my teams consistently outperform others, despite me giving plenty of vacation to my team and to myself as needed. Well rested people write better code that doesn't have to be re-written several times due to exhaustion-caused mistakes. Weird, huh? If your job is so simple, you can just toughen up and keep doing it, it at least explains why you're so afraid of looking weak to your bosses, as you'd be easily replaced. I'm sorry, that must suck. I work in a field that requires specialists that can work with their head, and so ability to say, "Hey, I'm not coming in today, because I'll just make a mess of things," is far more valuable here than whatever it is that you're trying to express with "built different". And you probably shouldn't apply your life experiences to game development.

KSP1 physics is only a blocker if you need thrust under warp. There are ways around that. I would imagine the original vision only having one new star system, and it would have been a lot closer to Kerbol. Everything else is dependent on scale and quality. There was room to improve planet visuals even on KSP1 base without a significant performance hit. And I imagine most of the work would be in trying to get everything else looking better. Add better scattering, clouds, and new materials for rockets. Some of it would need new code, but you wouldn't have to replace the existing terrain system for that. It would, however, restrict you in what you can do for new planets, which seems to have been one of the driving forces for replacing the tech. Finally, colonies could definitely have been done on existing tech. They'd be scrappier, though. In short, to meet Intercept's objectives at quality they set out to achieve, you needed a lot of the code to change. But if you simply wanted to stuff new features into the existing game, you could have used KSP1 as a base and take some shortcuts. It would look very much like KSP with some visual mods, though. So I'm glad that the concept was pushed a lot further than that.

I consider it very unfortunate that you do not think your own mental health is more important than your work, and happy to see that the industry is starting to embrace the attitude that puts the well being of the workers first. Whoever convinced you that you need to sacrifice yourself so that your company can make more money was not doing so for your benefit. Working yourself into a burnout is not a virtue.

Psychologists call that a parasocial relationship, and recommend avoiding it. I'll repeat for clarity. If you have feedback on the product, that's valuable and appreciated. Even if you're complaining about the game, talking about the problems, comparing it unfavorably to other games - there's value in that. Though, obviously, if you can keep it constructive, that's always better. If you have feedback about how the developers spend their time, that's probably best kept to yourself.

You should know all of that. You're the one who knows how to make the game better than people making it. Chop, chop. Money's out there, and you're letting it go somewhere else.

Would be very easy to make a micro-site like this hosted on something like GitHub. React (or even plain HTML) for data entry, with a 2D canvas to render. Standard double-precision numerical accuracy of JS is plenty for anything within human history, so you don't have to do anything fancy for the math. Just a calendar widget, conversion to time from reference date, reference date for the planets, and their orbital periods with sufficient accuracy for the computations.

That's more work than writing it from scratch. A lot more work. Plus attrition, because engineers know it's more work, and it's miserable work on top of it. You're welcome to open up your own games studio if you really think you can take an old game code, overhaul it to support a modern rendering pipeline, and do so on a smaller budget than it would to just write that stuff from scratch. There's great money in re-releasing classics with improved graphics. If you could undercut the competition with a better rate, you could be a rich person in no time. Go for it. I'm rooting for you.

Original scope implied smaller budget, a tiny team, and 3 years of development. But even if they wanted to rescope while keeping the original code base, you seem to be under some faulty impression that a mod doing everything we see in KSP2, even just the visual stuff, would be any better in performance and stability. The mods are there. You're absolutely welcome to install a high-res terrain, parallax cranked to the max, cloud mods, lighting mods, engine FX mods, and report back on how you enjoyed the loading times, frame rate, and your overall experience. One of the big differences I see on the forum is between people who looked at modded KSP footage on YouTube and complain about KSP2, and people who actually took time playing modded KSP, and seem to be of much more favorable opinion of the state of KSP2.

Here's the chain of accountability. Developers are accountable to studio leads. They are accountable to the publisher. The publishing side is accountable to the corporate leadership of the company that provided the funds to make the game. The corporate leadership is accountable to the investors. If you are an investor, you're in that chain, and you can bring it up at the shareholder meeting. Otherwise, you're not part of that chain. You're not holding anyone accountable. The feedback about the quality game is always welcome. If you can provide constructive criticism of what can be improved about the product, that's even better. How the studio makes the game, and whether the developers get to go to conferences is absolutely none of the customer business. The product is the game, not how the developers work. If you want to be paying money for people to be doing exactly what you tell them, the product you're looking for isn't a video game, and you shouldn't be demanding it from game developers. It is absolutely sensible, as I am a game developer, and I have to deal with this kind of crap attitude all the time. The comment was talking about Intercpet developers specifically, but directed at the industry. So yeah, it was directed at me as well, and the following quote shows precisely that it was so. It's not the job of game dvelopers to respect customers. Or interact with them in any way. Or provide them with anything. The developers are responsible for making a game for the publisher to publish. And it's up to the publisher to decide if the developers have done it to their satisfaction or not. If you want customer care, I direct you to the customer support line at Private Division. They are actually paid to show you respect. Otherwise, you are being entitled again, and demanding things that aren't part of the product. As I've pointed out earlier, Alexoff was here on the forum complaining about the progress being made on the game from before early access was even announced. If he purchased early access and got exactly what he said he was going to get, that's entirely on him. Out of all the people who might complain about purchasing early access, that would be one example that's 100% crocodile tears.

That's reaching a bit. I don't think STG started out making the same game that the Intercept did. It's hard to say precisely at what point the scope went from, "We're making a big enough expansion to KSP to sell it as a new game, but still, fundamentally, on the same tech, recycling much of KSP code and art," to "We're reworking every game system, building a new art pipeline, and will need completely new code and assets for KSP2." I'm obviously guessing a bit on the specifics and even more on the timeline, but it seems that when STG were contracted around mid to late 2017, it was the former, and by some time in early to mid 2020 the game was with the Intercept and it was scoped to the latter. If the scope was already rapidly changing by late 2018 to early 2019, yeah, STG completely dropped the ball on getting their act together, communicating needs for significantly more resources and development time, etc. If the scope only started changing around E3, possibly just weeks or days prior, it's much more hazy, and it's easier to excuse STG, shifting more of the communication blame onto PD. But the latter might have been restricted in what they could say at the time if they were negotiating with STG for the scope expansion. We know that STG was trying to get more funding and dev time from PD by late 2019. I have no idea how reasonable their requests were, and we were still in the dark at that point, but the outcome is known. Negotiations broke down, STG got the boot, and Intercept was created. So, while I agree that there was a failure at some level, saying that STG was doing a poor job of making the game they initially set out to make might be unfair. We don't know what that really looked like, and we might never know. That wasn't the game that was eventually made, and whether the quality was a factor, or if it was entirely just a matter of PD deciding on massively expanding the scope of the game, is not clear from the public information we have. I understand if it wasn't obvious at the time. I work in games, so this might have been more clear to me than general public as soon as the first concepts screenshots of WIP started dropping from Intercept in late 2020 - early 2021, and I had absolutely no expectation of the game coming out any time soon back then, but to everyone else, yeah, maybe the ETA of late 2021 release sounded reasonable. And the fact that it wasn't communicated then is definitely a misstep in my opinion. But in retrospect, now that we're seeing an alpha build being released as early access in 2023, I think it should be pretty easy to look back at the info that was available about the studio shakeup and realize that, yeah, Intercept basically started the work from scratch. Like, a lot of the detail is missing, but I don't see a need for further explanation of why the game is so late. Some sort of an explanation for why it wasn't communicated clearly right away? Sure, that'd be nice. Don't think it's happening, though. Corporate doesn't like to talk about such things. (And in some cases can't due to legal restrictions.)

Release date scheduled by Star Theory Games, which, by that point, was shut down. What's your point, exactly? I don't mean to paint STG as a scapegoat for all the problems, but in terms of the information being out there, the original devs were very publicly dropped, new studio to work on KSP2 was spun up, and all of that was very in news with coverage going as far as being an article on Forbes at the time, because newly created Intercept was "poaching" (according to the article) people from the sinking ship that was Star Theory Games at the time. Kotaku, Polygon, etc. had mutliple articles as this was developing. I understand that you might have missed all of this, or for some reason haven't connected it to the delay, but the information was there. To be more forthcoming, Private Division would have to make flashing neon signs. The fact that Private Division hasn't immediately announced a TBD delay for the release date was a bad move, of course. I have no idea what sort of corporate checkers were involved in decision to keep pushing it back about a year at a time instead. I don't know if Intercept was involved in setting these intermediate release dates or if this was entirely T2/PD internal shenanigans. In either case, that's one place where there should have been more transparency. "The game is delayed, and we'll let you know a new release date once we have it," would have been a much better call, at least in terms of optics. Again, I have no idea what sort of internal pressures they might have been dealing with.