K^2

This analysis is what "Lies, damn lies, and statistics," phrase was coined about. You've taken the difference between best estimate for KSP1, worst for KSP2, and said, "Yeah, 3.8% is not far off from 1%". I mean, even that is closer to 10% than to 1% in order of magnitude, and this is after you've basically taken the opposite ends of the bell curve to try to make it work. You're taking 5% of 5% in probability, and it STILL isn't supporting your claim. The lowest 0.25%-likely estimate is entirely too high to support the 1% claim. This is gross misuse of the stats that's either ignorant or dishonest. Neither of these is excusable to continue pushing after you got called on it. The fact that KSP2 likely (as in, P>90%) sold in a year more than 10% of KSP1 sales in over a decade, is a great indicator of how KSP2 was on as good of a track financially as PD hoped it would be as an EA title. Yes, they needed full marketing push and a console release to actually make it a financial success, which would require it to be in a better shape than it is now, but the risks involved are minimal. A competent team can finish it. Even if you don't think Intercept was running the team competently (highly debatable, but even if), PD just needs to put someone they trust in charge of Intercept, finish the project, and rake in the revenue. Even compared to T2 budget, which is orders of magnitude higher, you're really asking, "Should the company have invested another $20-$30M in a project they've invested ~$50M to have a guaranteed return in $50M-$200M range after console sales with no risk?" The answer is yes. This is the exact situation for which PD exists as a division within T2. There is zero sense in canceling the KSP2 project based on performance of Early Access. All of the reasoning for the layoffs and projects going on ice are in the financials that were just presented, which show monumental losses suffered by Take Two during the 2024FY. Yes, they took in record revenue, but they have way over expanded in 2022-2023FY, as shown by the huge increase in their operating expenses, far outpacing the growth of revenue. For a company of T2 size, the only sensible response is to shut down basically everything PD is working on that doesn't have imminent release. Since KSP2 wasn't planned to go 1.0 in 2025FY, it got the axe. It's that simple. It will be a little bit more expensive to restart the project in a year, but the company is bleeding money now and the loans are absurdly expensive. A year from now, federal interest rate is expected to be more reasonable, and a bit later in 2025, GTA VI ships. If nothing comes up earlier, there is basically zero chance the KSP2 isn't back in development then. And smart money is on T2 having some skeleton crew working on it from now until then - not to make the progress so much as keep it patched up and retain experience. And we see evidence of that in the movements in the game's repositories. All the nonsense about, "Take Two finally got fed up with mismanaged project," is misinformed, ignorant, and incongruent with any of the available data, from the financials, to the game's performance, to how mismanagement has been historically handled not only at T2, but at other publishers in similar situation, to messaging around the situation, to the fact that there is still some sort of activity on the game's repositories. The amount of double-think you have to get into to believe that T2 has just been twiddling thumbs for the past four years as Intercept ran amok, and then suddenly, having seen the not yet released game make something in the $10-$20M revenue, decided to just axe the entire studio for mismanagement letting go of absolutely everyone involved, is bordering on flat Earth conspiracy absurd. You have to both believe that T2 was happy to sign off on ~$50M in costs without checking in at all, and then suddenly start carrying when it turned out that it has only cost them 80% of that, decided that nobody at the studio was worth keeping hired, and fired absolutely everybody. This hypothesis doesn't survive the bare minimum of critical thought. Especially against the Occam's Razor of, "T2 just lost over $3B and needs to cut anything non-essential," which is what actually happened, and what T2 said happened, and what everyone in the financial circles reported has happened.

I suspect they can't just shut down Intercept for legal reasons. But even then, I would expect indication that they are reducing emphasis on it, or w/e. The statements as made are definitely not a good tone.

Until very recently, Havok was basically the only dedicated engine worth considering, and they've, erm, always lagged a little behind top-of-the-line. Some in-house engines have had that feature. But being able to handle that kind of a network load in the first place is a relatively new thing in gaming. So it's not a huge surprise. Chaos is the first one that's going to be fully networkable out of the box, and it kind of makes sense. Epic ships with a networking solution already included and, despite some problems with it, it's what everyone will at least start with. So making physics work with that just makes sense. Well, you wouldn't do this in C# either even if you were building it for Unity. A Unity plugin can call native code, and you'd put all your serious code into that. So C++, likely. If you have worker threads already spinning, they can just increment an atomic to get the next index to work on. That's typically the simplest thing to do, and gives every thread a sensible stop condition. Not mine. I don't know who introduced the term "physics island" - might be Erin Catto, but at any rate, it seems to be fairly well established in the trade. It doesn't have to be spatially-limited. Just any collection of rigid bodies and constraints that are guaranteed not to interact with anything from another island. A number of engines only ever use one island (hence guaranteeing the requirement is met) and I know of at least one that still uses the island terminology for that lonely island. If you do multi-island solver, you can take an optimization that static colliders (like planet's surface) can be interacted with by multiple islands without causing the two islands to merge. Since the planet's infinitely massive (for the purpose of simulation) it can't transfer recoil from one island to another. Colonies are another matter however. Actually, colonies deserve their own note. If you're doing custom physics (and maybe even if you don't) I would make colonies rigid. You can still simulate joint limits without allowing the joints to flex. The advantage is that you only have to solve the constraints matrix once per configuration. So unless you enter build mode or something breaks from impact, you don't have to recompute it. And even when you do, you might be able to spread it between several frames, and you'll have a good starting point for iterations. So you just compute the inverse of a matrix and store it. When an island touches the colony, you solve for the constraints as if the colony was perfectly rigid. Once you have the contact force, you apply these to relevant structures in the colony, and run these though the stress matrix to see if any joints are overloaded. If they do, stuff breaks, shenanigans ensue. Otherwise, the colony remains as solid as part of the terrain. This breaks a little with orbital colonies in theory, as you could have forces on one ship docked to a space colony transfer recoil through colony structure to another ship docked at the same colony, at which point they're really become one island even if you can treat the colony as rigid, but also, maybe just don't? While being able to boost a space colony with a docked ship seems like an interesting game mechanic, I think having colonies be fixed in the orbit once constructed would be a reasonable simplification. In that case, a space colony's basically a tiny moon with "infinite" mass, and then you treat it exactly the same as surface colonies, and problem solved. In this approach, two ships only become the same island if they collide, and again, that ought to be either slow and gentle, where things will probably settle naturally, or catastrophic, where you don't care about precision nearly as much, making it a simpler problem. This approach to colonies would work even with stock physics, so long as you can basically create separate collision scenes for each ship. Or maybe each player? The latter would allow each client to run their own physics simulation for whatever ships are "theirs", adding other ships into sim only if some bounding box collision is detected, at which point they're removed from the owning player's simulation. It's something I'd have to experiment with in Unity to see how workable that is, but it lets you split the work between clients, at least, and still work together on building the same colonies, including any docking procedures that don't directly involve two ships touching each other. Tough question, and I'm probably not the best person to answer it. I have limited experience with both. From what I do know, Godot is better if you have a small team that's more engineer/tech-art heavy. You can do more custom stuff that fits your team's needs. For a larger or more art-heavy teams, Unity's probably still a better choice, because it has more built-in tools and pipelines. But the problem is that Unity's been getting more and more bloated, and project restart and build times are getting obscene for larger games. Basically, they're hurting exactly where Unity needs to be the strongest to be competitive. So the domain where Unity is the preferred engine is shrinking, with Godot and Unreal taking larger and larger bites from it from each end. For 2017 Star Theory composition and size, I think Unity was still the best choice. For 2020 Intercept, in retrospect, I would say they should have switched to Unreal. Problem is, a lot of it is hindsight. I'm sure if you searched, you can find some posts of mine from 2020-2021 where I say they had no reason to switch. I was involved in evaluation of Unreal 5 for a developer in 2021, and my early impressions of Chaos were not as good as they are now. Also, I don't think we really understood the scope of the new KSP2 design back then. Knowing where Unreal 5.4 is now and what KSP2 looks like, Unreal was a better choice. A lot of the tech Intercept spent a lot of time building for planets is just standard features in Unreal 5.4. They were raw and not production-ready in 5.0, which only officially released in 2022, but previews were available as early as late 2020 for some studios, and a lot of this was available as experimental features in Unreal 4. So it would have been a very hard sell in 2020, but had Intercept gone with Unreal back then, they'd have a lot more time to work on gameplay, would have much better physics and networking out of the box, and would have a better art and asset pipelines available to them. All in all, KSP2 would be half a year to a year ahead of where it is now, possibly nearing 1.0 release. Assuming the team was able to hire Unreal specialists early enough, but that's generally a lot easier to do these days than some specialist roles they had to find to hack these features into Unity.

Fair enough.

You mean a game they so far have put in about $50M into and that raised over $10M in Early Access already, before having a full marketing push or having a console release? Again, I'll say it a little louder for these in the back. KSP2 was on track to be a positive RoI despite all of the delays even with existing leadership. If T2/PD really believed that Intercept was being mismanaged, they needed to replace 3-4 people to create the minimal disruption to the project. The Intercept layoffs had absolutely nothing to do with T2 having doubts about KSP2's financials. This is purely about cutting costs. T2 just posted a $2.9B loss. Their operating costs shot up from $1B in 2023 to over $3B in 2024FY. The interest on loans was $14M in 2022, $140M in 2023, and $100M in 2024FY. The company has been borrowing and hiring aggressively over the 2020-2023, and currently cannot be sustaining these expenses. They had to cut costs dramatically for 2025FY, because GTA VI isn't shipping until 2026FY. And that's the ENTIRE reason for KSP2 getting suspended. To not come back to KSP2 development the moment the situation changes would be just leaving money on the table. T2 simply has bigger problems right now than smaller titles PD normally handles.

EA->1.0 would be on that list. Though, possibly under the "New Iterations" heading.

It's worth noting that KSP2 was never listed as an independent title. Here's a snippet from Q3 2023 report. Immersive Core still has 22 titles in flight in the latest report. KSP2 is no longer one of the bullet points, but clearly, neither are most of these 22 titles for the FY 2025-2027. Only the ones with highest impact or impending releases are listed. We have it confirmed now that KSP2 is not planned for FY2025. It was obvious from the rate at which EA progressed even if Intercept didn't close, however. So there is really no news on what they're planning to do with KSP2. Whether it's one of the 7 titles they've said were canceled, or if it's on ice pending transfer to another studio at some point in the future. Both of these options are still possible given the report.

They do if they have impact on earnings estimates. But the thing we can say with certainty is that T2 is not expecting KSP2 in FY2025. Which isn't a surprise either way. The speaker has mentioned several cut titles and restructuring, but no specific names mentioned.

They just talked about PD on stream. Not a word of KSP2.

I'll start with tech overview, if you are interested. Physics and performance for custom engines has been my main area of work for the past few years, so I can go into a bit of a detail, but I'll add a tl;dr near the end. Multithreading and multiplayer for physics are two separate problems, fortunately. Networking physics is hard because in most games multiplayer relies on rollbacks, and physics doesn't guarantee deterministic outcome on a rollback unless you have history of the constraint caches. The latter isn't too hard to keep, but you do need a few floats per joint or contact point in general for every frame of simulation you want to be able to go back. If you implement something like a circular buffer and have a strategy for dealing with blowing out the contact cache count, it's not too bad. I think that's roughly what Epic has been implementing for Chaos in their latest updates. (Though, I'm not fully caught up yet.) Unfortunately, it's not a standard feature of Havok, so you'd have to tinker to get it in. If you have custom physics, you're on your own, but then hopefully you have a good team to handle that. Note, however, that all of this is if you're doing rollbacks. If you're not, non-determinism isn't actually a problem. Other than that, simulated objects are a lot like players. Each island can be predicted locally, but someone should have authority. In traditional server-client, the authority is always the server, so nothing special is going on, but you are in rollback territory if you want good response to player inputs on simulated rockets. In something like KSP2, you have an option of making each player an authority over their own ship. This can be done in P2P setup, or even server-client with client-trust on anything ship-related. The advantage here is that rollback isn't necessary. For the authority player, the inputs are taken into account immediately upon the first simulation, and for anyone else, rubberbanding is fine. If two players are trying to dock, both are either moving slowly enough where it shouldn't matter much, or too fast for anything but an explosion to follow. So this is a perfect game for this kind of an approach. Networking aside, physics basically does four things. 1) Gather forces and torques, 2) Find collisions and generate contact constraints, 3) Solve for constraints forces, 4) Update velocities and positions based on net forces. Step 1 usually happens while you're updating all of your components or whatever game logic you have. E.g., applying thrust force to one of the rocket engines. The last step is almost trivial. It's O(N) and there's barely any math to do. So the steps that take a lot of computation and can benefit from being parallelized are 2 and 3. Collisions are very easy to split between threads, since each collision test is independent of all the others. Just have an atomic for next rigid body to grab, and ignore anything with a smaller index if it comes up in a relevant BVH leaf. Oh, and you have to have a strategy for the contact cache that allows for multithread access in some way, but that's a standard mutex problem. You will probably trip over the CPU cache a lot, so if you want the most out of this, it becomes a harder problem, where you want to respect the BVH when you are assigning out the work to threads. And if you have any static colliders (planet surface, etc) you really want to make sure you organize things in memory for it. But that's squeezing out the last 10-20% of the gain here, so not as critical as just having a way to run it in parallel. Step 3, solving constraints, is the hardest to divide up. Usually, it's not where you end up with the worst cases on performance, though. Standard way of optimizing this solver is to just run one iteration per island. So long as your contact cache isn't changing often, and the spikes in forces aren't too dramatic, the constraint forces don't change much frame-to-frame, so one iteration is enough. And in something like KSP2, you do have very clear islands - most of the time rockets aren't colliding, so you can assume each rocket is its own island for the purposes of simulation, and dividing islands between threads is trivial. It does mean you'll have to do extra work if you found an overlap between colliders from two different rockets, including running a couple of extra iterations on the solver, because you'll have new and likely catastrophic forces, but that's sort of how you get the most out of physics in a game like this. How much of this can you implement in Unity? Depends on what you're doing for physics. The stock physics is an old branch of PhysX which is just bad. It's single-threaded, has poor quality (as it's pre-Box2D revolution) and you can't do much to change any of that, since it's basically just a black box in Unity. It is, unfortunately, what KSP2 was stuck with. At the time KSP2 work started at ST, it was basically the only option, and by the time Intercept rebooted the work, alternatives were still new and untested. Recently, Havok became an option if you run your game with ECS and DOTS. KSP2 was written with old MonoBehavior components, but if we get a development restart, the new team might chose to overhaul the components and go with ECS. I think that's what I'd want to do, but it depends a lot on the team. With Havok, you'd get threading for free, but Havok does absolutely nothing for networked physics. So you basically have to go with no-rollback solution for multiplayer, and it will have to be an entirely custom networking to handle all of that. Finally, custom physics is always an option. I'd still cut a branch from an existing physics engine for collision detection, because it's just a lot of work to write from scratch, but you have options there. Bullet has decent enough collision detection and is open source under ZLib license, so you can use it in proprietary software. Then write custom contact cache solution that plays nicely with my networking and threading strategies, and write a custom solver that keeps KSP2 specifics in mind. There are a lot of cool optimizations you can do when you know that your rockets are almost rigid bodies, and that you can always use a rigid body solution as a starting point for a lot of the math, working with smaller deltas as a result, leading to much better physics fidelity with no computational overhead. The downside of this is that there are maybe a few dozen game dev engineers who have experience with this. Most of them work at Epic. The rest would have come primarily from id, Havok, Crystal, or Blizz. So rare and not cheap. tl;dr: With KSP2 codebase as it is and under Unity, there are no real options. It's old branch of PhysX, which will be single threaded and awful for multiplayer. If we get an overhaul with the new team, that can be swapped out for Havok, which will give you multithreading for free, but will be a pain for multiplayer team to deal with. Still, probably the best possible outcome. And finally, custom physics is probably a non-starter, even though it's by far the best solution for something like KSP2. In all of these cases, multiplayer is going to be solved differently than in most games, and your best option is a no-rollback approach with each player having authority over their own rocket to avoid non-determinism problems. Any standard server-client solution is going to be a disaster with KSP2. I'd check on that. The only sources I've seen for ~30 is for late 2019, when KSP2 went from ST to Intercept. That could easily have been 20 in late 2017 at the start of the development, and hired up to 30 for work on KSP2 specifically. If you have sources for ~30 developers at the late 2017, I'd appreciate the link. I know there were more people at the studio, but that was largely on administrative side, and these were never transferred over to the Intercept.

Star Theory has made some beautiful games with a team of fewer than 20 people. A lot of people they hired for Intercept were seasoned Unity developers and artists with great successes on their resumes. They are quite capable as game developers. If you don't recognize that, you're being angry at clouds.

Honestly, expectations of what games look like outpaced the growth in tech, IMO. I don't think the retro graphics are there only for nostalgia. For a lot of indy devs it's a good way to focus on the overall style of the art without the nightmare of modern rendering pipelines. Second point's valid. People should have learned from the mistakes. ST and consequently Intercept leadership did suffer for their hubris; I can't possibly deny that. So fair point, but obviously didn't happen. Intercept ended up stepping on many of the same rakes. Measured by overall user experience (which is the ultimate test) yes, I completely agree. The reason for my point is that I expect problems plaguing KSP2 would eventually be solved. Even by the same team, given time. And I'm not yet giving up on this happening with another team down the line. Just like Squad managed to stumble their way to figuring out how to make a space simulator rocket builder game, so I suspect would Intercept or their successor. And that's where we can measure the two games on another metric. I don't think you can polish KSP1 past where it is. You can add mods, but that will cause performance and stability issues. You can try to add some improvements in vanilla by spending more time on the game, but you run into fundamental limitations of the architecture. KSP2 has a better framework. You can add more interesting planets, more varied materials, more procedural components, larger structures and eventually larger rockets. It's possible in KSP2 because it was designed to be expanded in that way. It is part of the reason why KSP2 is so full of bugs - they built a system for a much larger and complex game than what you see, but you're getting all the bugs upfront. And that's fine for a game in EA. (Less fine that it's at this stage of development long after it was supposed to release, but again, scheduling is a separate discussion.) Finished version of what you can build on KSP2 framework is a better game than KSP1 could possibly be. And this is a crucial point, because it's the answer to, "Why not just continue work on KSP1?" Because KSP1 could never be everything that KSP2 can be given the same amount of work on new features. Yes, that came with a huge upfront debt for the Intercept which they never managed to work through, but the end goal is worth it if the projects get finished.

I happen to remember how KSP1 played and looked in 2014, a year into its early access and four years into development overall, same as KSP2 now. The latter's doing much better.

I think ST and Nate personally didn't like what they made, but not for quality reasons. So this is largely speculation. I got some second hand confirmation for parts of it, but for the most part, I'm going with what we've seen starting with E3 presentation and up until first serious WIP footage started emerging from Intercept, and filling in blanks with my personal experience. Lets start with pre-KSP2 Star Theory. The two games they shipped in 2016 and 2017 were Unity games for PS VR (Wayward Sky and Dino Frontier) and the credits for both games list Uber Entertainment (then name of ST) as 18 people who are directly involved in building the game, including a 1 (one) engineer. 2017 is also when the talks with Take Two would have started. I'm sure ST hired additional people to work on the contract for KSP2, but even most generously, you don't look at that team and say, "Yeah, they're going to build a AAA game from scratch in under 3 years." As far as I can tell, what we know as KSP2 was not what Star Theory was contracted to make. The biggest guessing game for me is narrowing it down to the rough specs of what ST was meant to deliver in 2020. I think the trailer was meant to represent that game, but potentially with a lot of artistic license. I'm picturing a game that's entirely based on KSP1 codebase, with basically two large DLCs strapped to it. Colony building - including parts and some basic resource management letting you actually build stuff there, and interstellar - one new star system and parts to get you there. Plus some visual improvements for an aging game. I think Star Theory of late 2017 was capable of that, and with a few hires probably on schedule for 2020 release. Somewhere along the way, the dream got bigger. The E3 trailer was likely created with two goals in mind. 1) Stay within bounds of what's already on the roadmap, but 2) Present it as dialed to 11 under an excuse of the NOT ACTUAL GAMEPLAY disclaimer to gauge the reactions. I don't think it was meant to mislead, but rather represent the game ST wanted to make. And I think the pitch for that larger and bigger KSP2 was already in the air, and pending approval based on public reaction to the trailer. Reaction was good, lights were lit, and Nate is giving us a pitch for a bigger game pretty much from the first interviews. Multiplayer, colony management and transportation network are brought up, as well as plans for more star systems, realistic scale of space in between, physics overhaul, etc. It's hard to say how quickly the team realized that this is going to be a lot more work than anticipated. We know that by November 2019, T2's earnings report had KSP2 pushed back to 2021, but it's not clear if that was still a realistic expectation, or just, "Push it back a year until we figure it out." What we do know is that Star Theory was renegotiating the work contract based on larger team and a later deadline. We also know that the negotiations didn't go well for ST, and about a dozen of developers jumped ship to start Intercept Games. Later, more of the 20-30 developers ST had joined Intercept as ST got dissolved in early 2020. From there it's fairly straight forward. New road map got made, the team started hiring people, and while the exact scope is still hard to pin down, it sounds like they were planning for late 2022 to early 2023 release, which suggests that either they had harder time growing the team or underestimated the problem or both. But rolling back to that transition from Star Theory to Intercept, what can we say about the state of the game? We did see a preview of gameplay at Gamescon 2019. What do we see? New KSC, but still mostly blocked out with old terrain system. Rocket that does have shinier parts, but seems to be mostly KSP1 assets with an update to the materials. Very flimsy physics - suggesting they started experimenting with the physics overhaul, but got as far as removing autostruts. Abysmal framerate. (Clearly a priority on that last one, since they got it into the game so early. Sorry, couldn't resist.) What we don't see, but was probably heavily in the works are new parts for interstellar and colonies, and a bunch of planet work. Plus, probably tutorials. That last bit might seem like it's not a priority, but ST started out with good 2D art team, so I think they were trying to make the best use of the people they had. The problems with all of this is that the overhaul made a lot of that work place-holder quality at best. The new material system meant that even the parts that would have been made at quality, needed an overhaul pass. Planets likely had to be scrapped almost entirely, because a completely new system was built. Code, likewise, mostly thrown away. The parts that would have survived are concepts, UI work, tutorials, and whatever assets were good enough to be used as a starting point. Everything else had to be built from scratch, which, if it sounds like, "Rest of the game," yeah, I agree.

I'm not sure how you'd even do that as a mod, TBH. If some mod achieved it, I'd be interested to see how they've done it. Granted, Unity is probably the engine I have least experience with, but load-on-demand is a pain in the rear in general. And in KSP1 you have an added bonus that part configs are parsed from text (slowly and painfully, which is why loading time is that bad) every single time. I doubt part configurations end up taking a lot of space, but the way KSP1 is architected, decoupling the configs from assets would not be trivial for a mod. I have a feeling a lot of custom loaders would have to be written and replaced in game's memory to make this viable... Sounds like a lot of work for something likely to be an unstable pile of jank. KSP2 loading was organized differently. Though, I was still a little disappointed with the fact that transitions still existed at all. This might be some hard Unity limitation. I'm having hard time believing a commercial engine doesn't have facilities to support seamless scene transitions, but it wouldn't be the first time Unity surprised me this way. But at least the game avoids loading everything everywhere at once, and that's good for a start.

Not at all reasonable. You're making assumptions without looking at the numbers. Per @Mutex post above, ST was not large, and only fraction of developers transferred over. And there are a whole bunch of other factors you are ignoring, including differences between pre-production and production work, as well as how much work actually carries over when you re-start from pre-production. There are estimates for studio sizes and significant number of devs had Linkedin pages, so you can get a pretty good idea of how many people were working on what at what points in time. The studio strength of 70 people is valid for approximately the most recent two years, and a lot of these people aren't directly involved in the making of the game, again, just like the above post mentions. I also recommend you take a look at the KSP2 credits. Keep in mind that Intercept did end up listing everyone who worked on the game, so not all of these people have been involved concurrently. What you'll find in the credits, which is also just over 70 people, is everyone who ever worked on KSP2 under the umbrella of Intercept. And you can find hire and departure dates for a lot of these people. The last couple of years under Intercept, KSP2 started approaching a mid-size development. It's been a tiny indy-sized development for most of its life.

I mean, KSP was basically a hackathon project by beginners in the industry, who managed to make a successful game despite all odds and sometimes despite of themselves. It's full of problems, but I think you're being too harsh on it. I get that you're annoyed that people want to pretend that there were no flaws, and HarvesteR and the rest of the team were game development savants who got it right on the first try. And I mean, even HarvesteR doesn't believe that, clearly. But you're still overcorrecting. You core statements are not wrong, but the way you're delivering them is antagonizing. You know that classic, "Soylent Green is people!" scene? It can be like that sometimes. And HarvesteR did say something that's very much true about how KSP1 happened. He essentially said that the fact that they didn't know what they were doing has got them to try things that others would have discarded, but ended up working for the game. And that's sort of the value of an indy and hackathon projects. But on the technical side, yeah, KSP is one giant technical debt. Even some of the things they correctly stumbled into and talk about as learning experience, I could have told them on day one, because it's a fairly typical problem. And that's the bottom line. A game can be a technical and design disaster, and still be good, because it did things other games didn't. You really have to recognize both aspects of it if you want to try to replicate the success while cleaning out the debt, because it can be very hard to tell one from the other. The rocket wobble of KSP was clearly just a side effect of using Unity's joint system. But would completely, perfectly rigid rockets feel like playing KSP? I think the question alone can start a fierce debate between the fans and developers alike. And that's kind of where we are with the whole project.

There is no question that EA hasn't covered development costs. At an absolute minimum, KSP2 needs to be available on consoles to have a chance of making the money back, and I would argue needs a differentiator, like colonies ready and working, to do so. Which is a strong incentive to release 1.0 at some point in the future. My only point here was that $10M+ is by no means poor performance for Early Access. Imagine if you saw a game on Kickstarter take $10M. We'd be talking about it as an overwhelming success, even if we're comparing against games that have had demo on Steam at the time of KS. I don't know if we have any sort of confirmation that his profile changed, or if he always had PD listed on Linkedin. Currently, his profile lists work at PD since Feb 2020, id est, immediately after leaving Star Theory. No mention of Intercept Games. You can change these things retroactively. Unfortunately, I'm only seeing a May 2nd capture on Web Archive as well, so I don't know if he just always had it listed as PD, or if he changed it at some point on or before May 2nd. It does look like the same info is coming up in some 3rd party scrapers, but again, I have no idea how frequently these are updated. It is possible that Nate has set his profile to Private Division before Intercept was properly announced and never bothered to update. He might actually be affected by layoffs and studio closure, same as everyone else there. Unless someone has a screenshot from before May 2nd showing Linkedin page with Intercept Games listed, I don't think we should put too much stock in this.

Ah, I see we've gotten to the, "I'm not saying it's doomed, but BFG 9000 did spawn in the main lobby," stage of the discussion.

So? A lot of studios are WFH now. The only reason I've been in the same room with some of my colleagues is because we used to work at another studio together previously. A bunch of others aren't even in the same state. If you contributed to the game, you're part of the team. Don't take that away from people. Not yours to take.

I don't know where this is coming from. Lowest estimates I've seen are 240k, with a lot of reporting pointing to 500k+. It's probably not on the high end of these, but even at 240k, we're talking ~$10M in revenue. This is very not bad for EA. T2 still spent several times rhat on KSP2 already. In fact, if KSP2 was on EA sales budget from the time EA came out, they'd be running out right about now. I don't know if that's a factor in timing or just coincidence, but it does make the situation feel a tiny bit less unfair. Though, only a tiny bit. Intercept isn't an indy, and T2 took on responsibility of seeing the project through. So I'm still waiting for the Earnings Call this Thursday to hear how they explain it.

It was work-for-hire, making all assets property of T2 the moment they were created. The issue was never with anything ST made being lost/destroyed. The issue was that the game got heavily rescoped, sending dev cycle back to pre-production, and very little ususally survives that. Code would have been restructured, art pipelines changed... A lot of the ST assets would basically only be good as placeholders. I think what we saw was consistent with that. UI and audio work carried over. Some 3D models from ST pre-alpha footage have resurfaced in some of the early teasers. But most of the ships we were shown upclose got a visuals uplift, materials changed, and planets were completely redone. I can only speculate about the code, but it sounds like ST was sticking close to KSP1 code, and what went out with KSP2 EA was drastically different. So yeah, I am pretty sure that all work was transferred over, and relatively little of it could be used.

That was a hard problem for most studios, actually. You'd be surprised at the amount of traffic you need. Normally, a studio has LAN that can take it, but the internet service to studio usually isn't as robust, and mostly one way. Studio can receive decent amount of data but send a lot less. Due to security concerns, all of the inbound traffic to the studio is going through VPN and it can only take so much on existing service and gateways. Normally, upgrading this isn't a problem, but if you're in a large tech center, like Seattle, at the start of the pandemic lockdown, and suddenly every business and many residences need a service upgrade, while ISPs themselves are also operating under lockdown... Yeah, that took months to sort. That's kind of how being a game dev was then. Some studios were more cloud oriented or had foresight to work on remote connectivity earlier. They were lucky and suffered just a few weeks of disruption. And others weren't and lost months of productivity. On the flip side I also remember all the delay anouncements that came out around that time. And a lot of them did lean into WFH as an excuse. Watching that from inside the industry, when I knew some of these were already behind, and public release was making it sound like the game would be on time if not for the pandemic, that did get a little silly. And a lot of places that lost a month or two realistically, were pushing projects back by 6mo or more. I'm not upset if people were spared crunch, but we should just normalize being honest about schedule slips. Nothing ever ships on time and without crunch. Lets just be honest about it and avoid the crunch.

I think you're getting a bit dramatic on this. Is someone going to take notes on how this went down? Maybe. Could be useful. Was the silence orchestrated on purpose just to gauge the reaction? Definitely not. That part's true, though, and fully explains the silence without having to imagine a conspiracy. Saying anything will only fan the flames, so they're choosing not to. The silence is ethically questionable, of course, but that's a future T2's problem. Corporations aren't known for planning particularly well past the next quarter.

Studios don't like selling off IP, because even if unused, they're considered an asset that the company can claim to the company value. Somebody would have to offer a very significant sum of money for the Kerbal IP for it to make sense from T2 perspective. I don't see this being a small indy studio.