K^2

Addressed in multiple posts above.

The candidate branch update from 2d ago is very promissing, yeah.

This is a touch subjective, but I'm basing this on when people were being hired. Positions that got posted around Feb 2020 and filled summer-fall 2020 are consistent with game going from pre-production to full production. Yeah, these parts I completely agree on. This early access is not for everyone, and that needed to be clearly messaged. It wasn't. It was marketed as something that's a bit rough, but suitable for mass consumption, which is not so. My only point is that I don't think that reflects poorly on dev team by default. You can view it as a red flag, and it's fair. I was saying it in 2020. I can find you quotes if you want. This is why I'm with you as far as disappointment with messaging surrounding this, but also remain cautiously optimistic about development. It's clear that we're looking at summer release even if all goes well, which is a delay by any measure, but not an unreasonable one.

It's annoying, but you can work around it. A bit in advance of where you expect to drop the tanks, pause the game, go into resource manager, and set up the transfer. Unpause the game, and watch the gauges. Once the drop tanks are empty, jettison them. You don't have to time the fuel transfer perfectly. If you start a bit early or a bit late, you'll just be carrying the extra weight a little longer, but you'll still have all the same engines firing, so the loss of efficiency is fairly minimal. Because building up results in very wobbly rockets, despite the inconvenience, I would still recommend relying on asparagus heavily. It gives you good places to attach struts to give your craft the rigidity it needs to survive the ascent gracefully.

I don't know where you're getting an expectation for a faster turnaround, but it's not from anything resembling a real world of a mid-size studio. 2 weeks of work + 1 week of testing is fast-tracking it.

If you tell shareholders that the project is delayed to next fiscal year, you can buy yourself a year to distract them with something. If you tell them it's delayed by three years, you might be replaced right now and not get the chance. Name me a major game in the past decade that had its release slip by more than a year whose delay hasn't been announced in increments. I've held a title of director in a small studio with a modest eight figure funding. I've done engineering and mid-level management on titles well into nine figure budgets. And all of it is recent work that isn't out of date. I have done some indy work, but that was back in the day when I was still a graduate student, before I went into game development full time.

Au contraire. While you might have experience with the engineering, it's quite clear from your comments that your experience in management is, at best, lackluster. I know how I felt about the projects, where they are, and the dates we were given when I was a mid to senior engineer with no access to the decision making, even when I had been allowed to architect major systems, vs what it felt like in the director's seat or equivalent position, going to the meetings, and listening to CEO tell us what the board wants on the business end of things, and how we can make something that at least technically qualifies without compromising what we're actually making. There's a lot of horse trading. There is a lot of definition stretching. And there are a lot of dates that absolutely nobody has any confidence in, but we technically would have had the receipts for it if someone asked for them. Some dates only ever exist as Potemkin Villages, and it has nothing to do with the team not being capable. It has to do with someone pulling a trigger early on the marketing and then knowing how bad it will be to announce a 3 year delay the same year.

Except that it happens all the time. I've played nearly finished, never seen by anyone outside the studio games at every major studio I've worked at. One of these I've worked on myself before it got unceremoniously canceled. I've also looked at a couple of examples of games that did get handed over to another studio, including one that got fairly good response after its production reset. (Over 10M sales) In this case, the original work by the original studio is not widely known. It got ported to a completely different engine, so other than the Maya/Photoshop assets, no work on it survived the transfer. And yes, the version on the original engine was mid-production at least. Except we know this is what actually happened, as pretty much the entire creative team has been ripped out of Star Theory games and brought over to Intercept, including the creative director for the game. You don't do this if you think the team is doing poorly. Game's director is literally the first person you blame for any production problems. If you think the team did poorly, you don't bring the director. You might, however, do this if you can't reach an agreement with the executive leadership of the original studio, and you think you can poach all the talent along with all the assets and take a risk on the disruption. Especially, if you think the development needs to be rebooted anyways, because you think a larger scope will require a tech update. Which is what we saw. Most of the critical hires for Intercept post new studio formation have been in getting technical talent for an overhaul that wasn't needed for the original game. The people that ST would have had to hire anyways, and face delays while these people are onboarded. You obviously never had to deal with a board of directors trying to please investors.

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

Generally, a bad alpha is the one where some content is consistently unplayable. If a game-crashing bug would happen every time you approached Duna, for example, that'd be a good example of a bug that prevents you from exploring all of the game's content. If it only happens sometimes, that's par for the alpha. We have access to a good cross-section of parts, most identical to KSP, and pretty much all of the new tech features, save for multiplayer. This is sufficient to demonstrate what the game loop can be like, even if numerous bugs make it too frustrating for some people to play at this time. Again, goal of alpha isn't a nearly-playable game. That's what a beta is. This is like saying that Duke Nukem Forever was developed for 14 years. Star Theory went defunct. It never made the game they started in 2017. Development on KSP2 that we are seeing now started in 2020. There has been some asset reuse, but if you go by that metric, KSP2 has been in development since 2010, because there are some assets that have been upresed from the original KSP as well. This isn't how development timelines work, though. Intercept started production of KSP2 in 2020. If you continue arguing that we should be counting 2017, then start by explaining why we aren't counting from 2010. Or 2005, with first release of Unity. Or 1962, when Steve Russel made Spacewar! for PDP-1. Because, clearly, some concepts from that game have been reused in KSP2. Good state for an alpha, bad state for a public release with a marketing push. I'm enjoying it, but I enjoyed getting HL2 leak to work on my PC, because that's what I do with games. I tinker. Most people want a finished product. If a company starts selling access to something in an alpha stage, I don't think there's a problem with it, but I think better warning to people would have been nice. Some KSP fans clearly had different expectations of this early access. In either case, it's not a problem with how the game's being made. Just with how it's presented to the general public.

The big difference between KSP1 and KSP2 is that KSP1 had very strong reaction wheels from cockpit alone, giving you a lot of authority even at low speeds. With KSP2, you have to be more mindful of the aerodynamics. You also can't rely on stability assist as much, especially at low speeds and low engine thrust. So again, you have to make the plane more controllable with aerodynamics alone. I can see too potential problems with this particular plane - though it's hard to be sure without looking at the overlays available in VAB. 1. Pay attention to your CoM in relation to your fuel tanks. If your CoM is not centered on fuel, as the fuel drains, the CoM shifts. On this plane, I would guess the CoM shifts back, closer to the engine. If you start with CoP very close to CoM, it might end up forward of CoM, which will make the plane want to pitch up at low speeds, making landing hard. A good test is to enable CoM overlay in VAB, note where it is, then set all the fuel tanks to hold zero fuel. If your CoM shifted, that means it will shift in flight. If the CoM is shifting back, you need your fuel further back or move other parts to shift CoM forward. Once you have CoM fixed on the plane regardless of how much fuel is being used, place CoP just behind or just above CoM, and that will give you stable flight. 2. Pay attention to the control surfaces. This plane has a very shallow v-tail with almost no control surfaces, so your wings have to provide a lot of the pitch control. The control surfaces themselves are very close the center of mass due to the plane being fairly short. This means that at low speeds, you'll get very low authority. You can rectify it in two main ways. First, in the procedural wings setup you can increase both the width and the length of the control surface. That will give you more authority. Second option is to give it more leverage. You can replace your wings/stabilizers with control surfaces for the v-tail. These have more authority, generally. You can go with a more conventional tail, with a dedicated horizontal stabilizer that's taken out further back. Or you can also add a canard in the front that will help you with pitch control. Between these two, you can usually get something that's fairly good about gliding onto the runway. Once on the ground, another thing that's worth checking is making sure that your rear landing gear has no steering and front one has no braking. If you set the parking brake before touchdown with a configuration like that, you generally stay stable on the runway and have maximum braking immediately. You can play with adding a bit of braking power to the front to stop faster, but that might not be worth the sacrifice in stability.

The game-breaking bugs we see now should be relatively easy to fix, so long as they have a good foundation underneath. There are some inconveniences and design problems that might require rework based on feedback, but that's not what I consider game-breaking. Stuff like KSC teleporting to orbit is. And if that's just your basic origin relocation bug that got introduced by some of the work on MP, that should be a trivial fix now that it's known. If that sort of thing is hard to fix, that would be signaling underlying problems. And yes, I do suspect that there is still work being done on colonies, science, and so on. It's not necessarily all bug fixing. So if some new, unrelated bugs show up, that might not mean anything. But if we're seeing the same systems broken in new ways, it would be a significant red flag. Not an outright condemnation by itself, but an indicator that there is rot beneath the paint. It sounds from bits and pieces reported elsewhere like a lot of the flimsiness of the rockets and the relocation bugs have been found and addressed. That still leaves some critical breakages in save system and vessel physics. These are the ones to watch for, IMO. They are a little less trivial, but also would be far easier to fix if there is a clean architecture these systems are built on, and a nightmare if it's really bad.

Not particularly. We're seeing a good alpha build of the game. It's 4-6 months behind schedule compared to what I expected from a year ago, since I would have expected the game to ship in Dec-Jan, but a 3-year project slipping by 6 months isn't unusual. And as I expected, multiplayer is the part that's the most behind the schedule. The only part that surprised me is PD pushing for an early access in this state, which makes me think that some of the hurdles might have been hit relatively late, when the schedule has already been set. Looking at the list of what I would call A bugs vs what the team is focusing on for the first patch, so long as that gets delivered in the next week or two, I think everything's on the right trajectory. If the game's still as difficult to play then as it currently is, I'll start worrying. Otherwise, about what I'd expect to see internally presented to publisher at 4-6 months away from game's release. You don't usually get to see a game in this state if you're not working on one, but that's what it looks like. Welcome to the sausage factory. My only bit of real criticism is about some sort of a communication breakdown between marketing, community, and development teams. I don't know what they thought would happen, but doing a polished-looking launch trailer for the early access with no context whatsoever and then just dropping an alpha onto the Steam store has predictably led to confusion and frustration. People clearly expected an open beta type situation, and somebody should have done a better job to make sure that people know this ain't it. tl;dr, the next patch is crucial. If it fixes the A bugs and gets us to a clean, stable alpha, everything's good. If it still has as many problems as it does now, bad news.

Mostly just with radial parts and moving, but I have definitely been able to assign multiple things to the same node, and now that you're talking about the file structure, maybe that's a bug, and maybe that's why the game doesn't like it? Like, if all the children you assigned to the same node still point to the "correct" parent, it might show up correctly in the editor, but only one of these gets a physics joint on craft spawn? I'll play around with that a bit more and see if I can find the craft where that's happening.

It's very easy to clip parts, but it also causes a lot of bad connections and Kraken visits. I would very strongly recommend avoiding part clipping for now for anything you plan to take further than low Kerbin orbit.

No, they aren't. Not unless we're talking indy titles with flipped assets or some smaller mobile games.

By the same token, the publisher doesn't care how you feel about the price. Only whether you, or rather, your demographic on average, are willing to pay it. They invested the money into marketing, because they intend to get it back, and then as much money as they can on top of it. And you might not care for it, but you're on this forum payed for by that same marketing budget, so it's clearly working as intended. How much experience do you have in making games? Because that's what it takes at an absolute minimum. You're not making anything remotely like KSP, let alone KSP2, with an artist and a programmer. This requires a team, which has managers, production, human resources...

Smaller studios tend to be more frugal, but yes, even the compensation + marketing estimate is certainly just a lower bound. 3x pure salary sounds very believable for larger studios.

There's definitely an issue on KSP2 side, but usually one of the parts (the one you're actually dragging) pastes correctly, so it looks like it might be possible to fix in data. But I've only looked at some specific cases where I was able to fix things manually, and the general case might be trickier. If you plan to have a repository for this, I don't mind taking a crack at it myself and submitting a PR. I'm just absolutely terrible at UI, so it'd take me an eternity to make something remotely functional from scratch, but I can contribute to something like this if you'd like.

Right now, there are problems with the symmetry sets when you duplicate parts, or try to attach something to a new location. So, like, if I build a sub-assembly with some symmetrical attachments, and then try to attach that sub-assembly with a different symmetry to a craft, the symmetry often ends up being correct on one copy of the part, but messed up on all the other instances. If you're looking for suggestions on where to expand the editing tool. I wouldn't mind something that lets me pick parts and fix the symmetry sets for cases like that. E.g., if I have a left wing sub-assembly and a symmetrical right-wing sub-assembly, have an option in the tool that fixes the right wing to have the same symmetry groups as the left wing. Right now, I have to try and do that by hand, or do various workarounds, and that's painful. Also, save files are JSON with a lot of similarity in how the craft are stored. Being able to apply all of the edits to craft in flight in a save file might be useful.

Clearly, they are a type of symbiotic slime mold of unicellular algae and yeast. Making them a fungus, a plant, and an animal at the same time. That explains the lack of Kerbal cities on Kerbin, as the natural state of Kerbals is just single cell culture living in the shallow waters and damp soil of Kerbin. What we know as Kerbals are just the fruiting bodies that gained sentience in their endless quest to spread the spores as far as possible. To that end, Kerbals are capable of building amazing machinery, mostly in coastal areas, to spread themselves to other worlds. Thanks to their symbiotic origin, they can consume a variety of food sources, but also just nourish themselves on the sunlight, endlessly recirculating atmosphere without needing an oxygen supply, as well as be able to spend a very long time in a semi-dormant state waiting for the right conditions to release their spores.

Unlike KSP1's smooth sphere, KSP2's Jool surface has features and dedicated material texture. It looks like too much effort for a placeholder. Granted, it's entirely possible that it was something that was considered, then got abandoned, so it's still possible that it will be cut, but I'm leaning towards it being one of the places intended for colonies mining for unique resources. Return from Jool would be by far the most challenging mission. What is better graduation than that into future tech, which would make the subsequent climbs out of gravity wells trivial?

Sometimes, not even actions. Sometimes, you just claim something's bad, because you're frustrated over some aspect of it, and then you don't want to take it back, so you keep finding reasons for why it's bad, whether or not it is so. Happens very often. I'm sure you can think of examples.

And the director salaries? And the C-suite? There's a reason why an average for incomes is generally significantly above the median. $100k average might turn out to be conservative with this range on currently open positions. The 60% has been addressed above, yeah, it includes a lot of the overhead you don't think about as an employee, but that get factored in when you start doing estimates for how much an employee costs to the company. Always hated these estimates. Feels like you're turning people into numbers, and that's not a good feeling.

*shrug* I don't know what that does in terms of gameplay or aesthetics. I'm just channeling my inner physicist. If a metastable phase of metallic hydrogen was to exist, and a planet had a liquid metallic hydrogen mantle under a mostly-molecular hydrogen atmosphere, and the temperature at the interface was below the melting point of MSMH, then a crust of MSMH would surely form. But it's a game, and the developers can go into any number of directions with that. All I know is that the above would make sense with the known Kerbal cosmology and that there are people on the dev team that were definitely thinking along these lines. Whether it's actually the intended structure is just a guess. It's entirely possible that these people got overruled based on much the same concerns that you raise.