K^2

And? Suppose for a moment they were twiddling their thumbs for three years. What's it to you? Are you an investor in TakeTwo? If you are, you should take it up with them at the next investor meeting. If not, how they developed the game shouldn't be any concern of yours. You aren't an uninformed customer. You were right here complaining before the early access was even announced. If you purchased the early access, why? If not, what's your complaint, exactly? Nobody owes you a game. The devs can decide how they spend their time. If the publisher is unhappy with how the dev budget is being spent, that's a discussion between the developer and the publisher. If you're not happy with the game, don't buy the game. Sitting here saying the devs shouldn't go to a conference because they should be working on a game you want (do you even want it?) is the kind of an absurd tantrum that I expect from a kindergartener when they don't get a toy they want.

It's a trait associated with studios that don't drive their employees into 80 hour weeks and end up on the wrong end of a class action law suite. Letting employees take a break when they need it, regardless of the schedule, is a trait of studios like Supergiant Games. And if you think Hades review scores suffered from it, you need to re-evaluate what you know about game development. Studios that did keep the developers working after a lackluster release? Bioware after shipping Anthem. Crystal after shipping Avengers. Do I need to go on? Or are you seeing a pattern emerge?

"How dare the developers do anything other than what I decided is the top priority for them!" - Wait 'till you find out that some of them took a vacation after shipping early access, because they were stressed after trying to get the game into as good of a shape as they could. The scandal! I am always amazed by the entitlement in the gaming communities. If anyone ever wonders why most developers don't spend time talking with the fans, this is basically the reason. Even if you find it amusing, it gets old after a while. For the record, conferences are the most important thing we do in the industry as an industry. Certainly trumping a couple of days of work on bugs and features for a few of the major conferences throughout the year. That is one part of game development that continues to work more like academia than an industry, and where the ideas, successes, and failures are shared freely. It's the greatest source of learning for the team. And having access to a right talk can save a studio months of R&D. Every developer is happy to give back to that pool of shared knowledge, because without it, we wouldn't be able to create games that we do.

Could have been a factor, but there are other ways to fake HDR.

You might as well claim that R-7 launched the Vostok spacecraft by the same exact logic. Atlas LV-3B is a significant improvement on Atlas D. Looking at the boosters alone, the Rocketdyne XLR-89-5 of the LV-3B are about a 10% improvement in thrust over LR-89 of Atlas D. Do you think that maybe significant? Or do you suppose that North Korea is likely to squeeze a 10% improvement out of the RD-250 they're using for Hwasong-17? North Korea is not building their own engines for their own rapidly emerging space program, where an ICBM is just a prototype for a bigger, more capable rocket once they improve the tech. They are using old Soviet designs and trying to make them fly with their ICBMs for the past 30+ years. Hwasong-17 has a 15,000km range, because that's all you're squeezing out of a Hwasong-17. They aren't getting another 2km/s out of that rocket. They will need a new rocket.

No real surprises in this talk. A lot of what they ran into are the sort of things many teams working on large, open world games have been finding, with a caveat that because the world is spherical, Intercept had to re-implement a lot of the tools from scratch. (Having worked on an in-house engine that went from canned maps to open world, I'm pretty familiar with all the rakes hidden in that tall grass, as we had to make similar kinds of tools for our teams.) Things that was a bit unexpected for me is how often the Intercept went to more artist-tunning over more physics-based parameters for lighting and scattering. This isn't strictly good or bad, but I would have guessed Intercept going more towards physics on that. Might be good news for modders. Want some really wacky color combination for sky and sunset colors? Just change some of the atmospheric parameters to the desired colors. Nothing in the game, apparently, is going to stop you because that combination is non-physical.

You need nearly 2km/s of delta-V to go from 15,000km range ballistic to LEO. Plus mass of the engine to provide that delta-V and the tanks which all counts towards the payload mass increase, since you can't jettison them until you have established orbit. I also don't know where NK is going to get orbital insertion engine stage with a 3.5km/s performance. You can't get a particularly long nozzle into the rocket anyways. The closest I'm seeing that should be available to them is something like the Soviet RD-0109, which was used to push the final stage of the Vostok rockets to orbit. That has less than 3.2km/s in vacuum. So optimistically, 1.7T for Mercury orbiter + kicker stage, multiply by exp(2/3.2) = 3.2T. Which is way over the minimum warhead mass given, which is where you get the maximum 15,000km range. And that's with optimistic numbers and giving North Korea a lot of undeserved credit. Wikipedia claims 1.4T for Mercury, but the source link is dead. Best I was able to find is Boeing claiming it's over 1.6T here. Which is still quite impressive. Vostok 1's orbiter was nearly 5T split almost evenly between the lander capsule with its massive 800kg+ heat shield and it's service module containing reentry engines. In short, no, even cutting NK every bit of slack we can, they can't get a human piloted vehicle on Hwasong-17. And if NK had the tech to build something even sleeker and lighter than a Mercury capsule to do it, they wouldn't be struggling so much with the ICBMs in the first place.

Of course, reentry heat is up in the air. Where else would it be? And I don't know how much we can read into the "doing science" status. That might be entirely incidental. Otherwise, though, yeah, it's entirely possible that some of the roadmap targets have shifted a bit. We know that engineering was way busier than Intercept probably expected with the first couple of patches. That could have allowed the content team to run ahead, and that can easily result in some things being ready earlier or some other things getting delayed to later, allowing the team to swap things around a bit.

Remade it in 3, and that's closer to the real development time of this game. Which sounds like a lot of time, but not when the team is as small as Intercept. I know that saying that Intercept started from scratch isn't entirely correct. A lot of the same people came over and a lot of the assets were available. But given the project rescoping, company re-org, etc, for the purposes of thinking of how long it took to make this game, you can think of it as entering pre-production when Intercept took over, and starting full scale production when they were fully staffed. So summer 2020 is when real work on what we now know as KSP2 would have begun. Again, asterisks and caveats, but for the purposes of discussion, that'll do. Also, just FYI, the games are always buggy late into the development. The kinds of bugs can vary, and certain kinds of bugs later in the development can be an indicator of poor organization in some cases or insufficient resources in others, but here's the relevant bit. KSP2 isn't finished. If KSP2 was released into early access and had no significant bugs - either the game should have been shipped as complete, or the scope should have been greater. Given the roadmap, you're playing an alpha build. It looks like an alpha build and it plays like an alpha build. And that's a reasonable condition for the game to be in if it's not getting released in the next 2-3 months. A lot of indy games are released into EA in what plays more like a beta. That's because they're trying to raise money to increase the scope of the game, and they know that an alpha build won't do that, and the game might never leave EA. Intercept knows that they have money to finish the game, presumably. KSP2 EA only needed to be playable enough to get feedback, and that's what we see. I think you misunderstood what I was saying. It's unsustainable for developers.

I thought they said console release concurrently with 1.0, no? Either way, yeah, I wouldn't expect the console version until the EA is done even if Intercept didn't say anything. For one thing, EA implies fairly frequent updates. Even if we get an update "only" every 3-4 weeks, for consoles, that's not a sustainable pace. Lead times required for approvals are pretty long. There are workarounds, technically, and little content fixes can be pushed more frequently, but right now, majority of fixes are of the sort that would require cert, and that takes time even for larger studios.

No idea. Could have been a bad merge, could be different branches, could be something else entirely. It's not really that uncommon for there to be a bad build sandwiched between good ones. QA is supposed to try and catch regressions like that in time, but they don't always have time to test everything. Until we see more updates, it's hard to say if it's systematic or a fluke. I don't think so. No reason to do that. There could be some parts further along that are more finished than others, but are blocked by less finished parts earlier in the roadmap, but other than that, if it was ready, there'd be no reason not to release it. These definitely exist. I'd be willing to be that multiplayer is one of these. Warp and trajectory stability are probably still issues as well. And the performance problems aren't helping. But there are also a bunch of smaller bugs of the, "The game isn't finished yet," variety that are obscuring a lot of that. Hopefully, devs have a clearer picture of what's a real fire and what just needs some polish and are triaging it appropriately.

It's up to the devs who they give access to which depos. They can use it to let people access older versions, participate in betas, give early access to media, do QA play-tests... Regardless of whether access to older depots is granted to players, it's very common to see a few older versions left uploaded in case a critical bug is discovered and they have to rollback. Or if they want to see if some newly reported bug was also in the older version and was simply unnoticed.

Glad I don't have to worry about that working custom engines. Any integration's custom anyways, so good or bad, at least we're not stuck with some 3rd party crap only because that's the only thing that's integrated.

It sucks that depending on weather conditions it can be a dice roll even under perfect execution by the pilots, sure, but even so, I'll take a slim chance over none. The psychological factor of that should not be undervalued. People aren't always rational. Perceived safety is more important than actual for this to work from the business standpoint. It's unlikely you'll have people trusting the space flight is safe if you don't make it so in fact, but that's not in itself sufficient. I disagree. You can always pivot the passenger seats. I would expect orientation consistent with HL to be more viable for longer flights as well. If you're going to coast to Mars, you better have something more convenient than Starship's HT orientation for the passengers. Ideally, I would expect a horizontal arrangement of rows and a tethered counterweight several kilometers away providing for centrifugal gravity on board. But that's just one more thing that Starship isn't built for. So it's kind of an academic discussion, I guess.

Git doesn't handle art assets particularly gracefully. At least, not out of the box. And even when configured to handle these kinds of files, for artists, there is zero benefit. For code, though, Git is absolutely the best way to go, so more and more studios end up running code repo in Git and art in P4. The reason we have SVN for some of the code is because the code base is, indeed, old. I don't know how much survived the re-writes and refactors, but the foundation is from the 90s.

With a reported range of 15,000km and upper estimate on warhead at 3.5T? No. You still need a pretty significant kick from that trajectory to orbit and then de-orbit the payload, and if you squeeze another stage into this ICBM's payload, what's left for orbital mass is tiny. They might be able to put a small satellite into space with it, but not a human. Especially not with any chance of returning back. Hwasong-17 has very similar performance to early R-7. That one had a touch shorter range with a heavier payload. And indeed, the Sputnik rocket was effectively a modification of R-7, whereas the Vostok rocket that carried the first human flight mission was a significant upgrade. On top of that, R-7 was built from the start to be upgradable to heavier payloads, in part, helped by the four booster design. I don't think Hwasong-17 would be easy to upgrade to a human flight capable rocket without attaching boosters to it. SRBs might be a cheap option to achieve that, though. These weren't as viable of an option in the 60s as they are today. It would still be a huge project, and a very unsafe one under the best circumstance. The safety margin on something like this would be hair thin with basically no spare mass for any safety features.

Current generation of chemical rockets is not sustainable for the kind of mass commercial flight that gave us 787 and the like. Superheavy will never be a 787. It fundamentally can't. I'd also point out that a 787 can glide to a survivable landing with total engine failure and is designed to climb with a single engine failure. Most critical systems are at least tripple-redundant. Starship would have to be built to this kind of standard to be even considered for passenger flight without an escape system. A Starship with dead engines is a coffin.

You have to go procedural for fine features. One thing I've seen that shows a lot of promise is AI-generated erosion, which can take a low-res height map, and generate the fine features that can be old and smooth, new and jagged, and cut with water channels as appropriate. In combination with virtual textures, you can get a very realistic looking terrain with no memory overhead (since you want virtual texturing for visuals anyways) and limited impact on performance. There are challenges associated with it. Running neural networks on GPU is still a significant workload, even if you split the work between frames using virtual textures. And this does alter the heightmap, so you need to integrate it into your physics somehow. That means having a compute pass for the terrain, or worse, moving all of your physics to the GPU, which would increase GPU workload even further. Caveats above in mind, the proof-of-concept demos I've seen look great. With ray tracers being a hot topic in GPU hardware, we're getting more and more dedicated silicone for working with AI and BVH, which can both be leveraged for terrain upsampling and physics respectively. So I expect that we'll be seeing tech like this integrated into large open world games in the near future.

I wish it was always Git. In game dev you're practically guaranteed for at least some of your project to be on another version control, and if you think merge conflicts suck to fix in Git, P4 wants to have a chat with you. A few years ago, I was working on a pair of AAA games, one nearing release, the other in pre-production, and we were using the common engine code. And every time we'd take fixes from one game into another, it would take a literal month for engineers in charge of it to get through it. Edit: Oh, and while I'm at it, the project I'm currently on, an even bigger AAA title, and we have our code and content split between Git, SVN, and P4. Thank the gods nobody suggested throwing Plastic into the mix.

Steam depots don't have to be 1:1 with branches. In fact, I'd be confident in saying that most of the dev depots are probably coming from the same branch, but it would also be an absolute nightmare to manage if everything there came from the same branch. It also depends a bit on what version control Intercept uses. For example, we see 0.1.0.0 and 0.1.1.0 depots. Under P4 or SVN, these almost definitely correspond to branches. Git, in contrast, has a good tagging systems, and both of these could be coming off something like release branch tagged something like 0.1.0.0 and 0.1.1.0 respectively. And, of course, if Git is used for code, there's probably still P4 or SVN for content, which would still be branched. From there, things get interesting. The thing that makes git so fantastic for working with code is that you can switch between branches very easily in the same clone directory. If there is an experimental feature being worked on, I can throw it in a branch, and simply check out to it or back to main or dev whenever needed without having to re-download the entire repository. With P4 and SVN, it's more painful. I would actually have individual directories for each check-out on these. Consequently, creating a branch for an experiment is a complication. On P4, I'm much more likely to simply work with an experimental shelf than a branch. So the branching strategy is going to be very different. So a typical P4 game project would have branches like: trunk, release, release_0_1_0_0, release_0_1_1_0.... and individual developers might have shelves off of any of these to work on experiments and fixes, wile git project would typically have main, release (with tags 0.1.0.0, 0.1.1.0, etc) and then a whole bunch of branches that individual developers created for patches and experiments. For bigger features like that, you usually have them in the release branch and simply disable it for specific versions. There is no good way to drag development of something like this entirely in parallel with everything else due to conflicts. You'll spend more time fixing things that got broken because somebody else modified code that they can't even see, because it's in your experiment branch, than actually working on the feature.

Fair on communication, but the rest is bad comparison. SpaceX is nearly 10k strong. For comparison, NASA employs about 18k. SpaceX is one of the largest space orgs, not just compared to other commercial providers, but even among government organizations. It is a huge company. In contrast, Intercept has about 40 developers. AAA games are typically made by teams of a few hundred and well into 1k+. Intercept is tiny by the industry standard. That's not a blanket excuse, but I expect someone like Intercept to step on rakes that I would be more critical of if it happened to a AAA studio. On top of that, budget for Superheavy has quite a few more zeros attached to it, and the large chunk of funding comes from the government sources - read mine and yours money too, and unlike our choice to get early access for KSP2, this was allocated by the politicians in Washington. Now, I'm not saying it's a bad use of the money, but again, a different standard for transparency is called for. And yes, of course I expect any kind of a space launch to be a much harder problem with way more caveats and hidden risks. But because of that and all of the reasons outlined above, with SpaceX being far from an underdogs these days and the government spending, I expect a lot more diligence and transparency from them than I do from a tiny game studio.

Very mixed feelings. On one hand, yeah, I get that the fact that it flew at all is a success. But I'm also seeing a lot of people trying to over-sell it. Yes, we expected something to go wrong during the flight, but a lot of things went wrong during this flight. Chunks of the platform coming off, fragging 3 of your engines, a bunch of safety equipment, a camera, and a car in the parking lot is not how you expect the engine start to go. And it somehow went worse from there. While I'm sure the damage to the underside of the rocket from liftoff could have led to some of the following problems, it sounds pretty incredible for all of the issues to be related to that. More engines flamed out, some with clear engine-rich exhaust flames. Ok, yeah, I suppose damaged plumbing could have resulted in that. But then we had a separation failure, engine shutoff failure, and was the flip supposed to be part of the booster slow-down procedure post separation? In which case, should that program have ran? Yeah, I get that the ship was lost by that point, but this is supposed to be human-flight rated eventually, and booster doing basically anything but that would be preferable for any sort of an abort procedure. Even if you're going to remote-detonate an uncrewed rocket, keeping the rocket pointing forward would give it better chances to coast clear of population, so this definitely isn't a good failure mode to have. I also see people pointing out that the rocket didn't disintegrate from the flip as a positive. That's another problem. Not with the structure, obviously, but it makes you pay attention to the numbers, and it was over 30km up going less than Mach 2. Two minutes into the flight, Falcon 9 is going Mach 5. The Superheavy was climbing way too slow and never made it close to its Max Q. I think we had an official flameout of what, six engines? It sounds like way more of them were underperforming. Again, could be damage on liftoff, but holly crap, does it show how the failures cascade on this thing. So yeah, by the time it started flipping, it was over 30km up, where the atmosphere is very thin and the rocket wasn't going that fast. Aerodynamic stress would be significantly below what this rocket is designed to survive during the booster's normal return flip, and certainly nothing like what the Starship is designed to survive on reentry. This test actually failed to see if the rocket is sturdy enough to do its job. And yeah, to some degree, all of these are nitpicks. But there are a lot of them, and if SpaceX opened up with, "Yeah, that went poorly, we're going to have to go back and look at what went wrong across the board," I'd be happy to focus on the things that went well. But their response has been, "This was great, better than we expected, and we have another one practically ready to go!" And now I'm concerned about the transparency and what exactly being swept under the rug. Obviously outsider's perspective, pound of salt and all that, and I'd love to hear what people working in the industry have to say about this. Just sharing my first impressions.

A lot of the systems are there too. Obviously, I can't tell what sort of a shape they are all in, and at least some are definitely just stubbed in, but also, a lot of the parts the team can add can run on combinations of existing systems. It's certainly a constraint on what can be added, but it's not a hard blocker to add some new content to keep people playing and providing feedback. I don't think they want to drop everything related to surveying planets, deploying extraction bases, storage, refining, and transport of said resources all in one go. Yeah, having a surface scanner like what we had in KSP before there is a way to extract resources might be almost cosmetic, but it's the sort of thing they can do without dragging in all of the dependencies. They can also add the resources themselves, storage tanks, and some portable versions of refineries for some of them. Again, similar to what we had in KSP to store ore and convert it to fuel. I do not expect a full working system soon, but I do expect components of it to show up relatively early, gradually building up to it. It's a better way to use the team's resources, a better way to test for problems early, and a better way to keep at least a fraction of the community engaged. There are no real downsides, and if something along these lines doesn't happen in the next patch or two, I would actually start worrying a bit about the project. (Which, I'm sure a lot of people would claim is overdue, but so far the patches have arrived on the kind of schedule and with kind of fixes that I have expected, and the receipts are right here on this forum.)

That's not how it works. Different teams work on different kinds of problems. If all that Intercept does is fix problems, a lot of the team are left twiddling their thumbs. From the perspective of getting the most use out of people effectively alpha-testing the game, yes, having roughly the same content from version to version is good. But also, people will start losing interest in the game, and even these who play will fall into the routine, which is exactly the reason that QA isn't catching some of these bugs (besides, likely, being understaffed in a typical industry fashion). So it's very likely that we'll be getting a trickle of new content with future patches. I don't think interstellar is coming until a lot of the things are nailed down, but some new parts for science and resource gathering are extremely likely to land in the next month or two. Even if not all of the associated functionality is available right away.

"Everything below sea level is water" is a good optimization. KSP used this and I see no reason for KSP2 not to as well. So if you somehow managed to make it through the surface, it makes perfect sense that you'd end up in a fluid, probably eventually sinking to the center, where your ship would get krakened by the singularity. I do wonder, however, what caused this clip to happen in the first place. Were you time-warping? Switching between the vessels? Or did it just happen completely out of nowhere?