K^2

Well, ok, I mean, it sort of does? But not in a way that makes it useful. Antiparticles behave in every way as negative mass particles traveling backwards in time, which still gives them positive inertial mass and positive energy density. So as far as things like exotic energy for warp drives, stable wormholes, and closed time loops go, it's absolutely no help. It's almost more of a mathematical quirk. One of the problems in physics, as far as making it easy to understand to people who didn't spend years or even decades studying it, is that a lot of terms have multiple meanings depending on the exact context. And while you can be precise and reference rest mass, inertial mass, gravitational mass, etc., very often we just say "mass", and people in the field know which one you mean. Usually. It gets even worse when notations change over time. Everyone knows E=mc2, and back when Einstein wrote it, that was a valid expression because m meant relativistic mass. Except in modern day physics, m usually means rest mass - Einstein would have denoted it as m0. But because notation changed, E=mc2 is no longer correct, not because of anything new in physics, we just mean a different thing by symbol m. So the correct expression would either be E=γmc2, where γ is the Lorentz boost due to not being in the rest frame where m is relevant, or you would explicitly include momentum: E2=m2c4 + p2c2. And you can see that if you flip signs of both E and m in these two equations, absolutely nothing changes. There is a more convoluted and precise explanation for why negative mass actually makes sense for antiparticles, but it involves Green's functions and functions of complex variable. Point is, mathematically, it makes sense to think of antiparticles as having a negative mass, but practically it doesn't make a difference. And the kind of mass we'd measure in an experiment, which is usually inertial mass, would still be a positive value.

In one of the videos, you can see what looks like a chart of Kerbol system with this little addition. It's never been clarified if this meant to imply a new planet on Kerbol, something beyond Kerbol system entirely, or just a silly Easter egg.

It's a bit more complex than that. Cable has to vary in thickness for anything practical and the counterweight is quite a bit more massive than the cable. You'll also want to absorb as much angular momentum as possible into the counterweight, so cable release will be done at an angle. The net effect is that initial orbit will differ from GEO quite significantly, and I couldn't tell you off the top of my head if it's higher or lower. I'd need to do a math for a specific example.

Commercial aviation "ditched" radio for INS because flying over oceans made using radio towers for navigation a little difficult. It took decades of improvements before INS was good enough to get you to a specific location, rather than just a vague area, because it's actually a very hard problem. Typical off-the-shelf accelerometers aren't remotely good enough for such work. And even with commercial INS systems, your terminal approach is still by-radio. The INS is still only meant to get you to a radio system that's going to guide you to the landing strip. Not to mention that GPS has become the primary system now, with INS being effectively a backup in case GPS goes down. If you shop for high precision accelerometers for UAVs etc, you'll see VRW on the order of 0.05mg/√Hz. This adds up to about 3cm/s per root hour. After a 9 hour flight, your position error is going to be about 1.6km. Which is actually quite amazing, but you don't want to be a mile off course if you are trying to find an airport in low visibility. You will have to rely on radio navigation. And this is with top shelf component that you have to sample and integrate at nearly 1kHz to get that level of precision, and we haven't even talked about orientation of the INS. Because if your axes are misaligned even the tiniest bit, the component of the gravity onto your XY plane will put you way, way off course. Not to mention the fact that gravity itself isn't uniform around the world, so you are going to get a drift in the Z direction as well. You can improve on that by combining input from several accelerometers and optical gyros and running output through an optimal filter. That's effectively what a modern INS does. But if you are anywhere over land, it's far easier and far cheaper to use existing radio stations for precise positioning. Or better yet, just buy a cheap GPS chip and read from it using an Arduino or something. Unless you are explicitly building something for safety and redundancy as a backup, GPS is by far your best option. Edit: Only marginally related, but I it's just too awesome not to mention: Pulsar-based Navigation. It still only puts you within a few km, but it will work anywhere on Earth, and on a flight to the Moon, and on a voyage to any other part of the Solar System, and on an interstellar trip to basically any star you can see in the sky with an unaided eye... And it will still be good to within a few km after you've traveled lightyears, because you're just counting the pulses and comparing it to frequencies observed from reference location.

Yeah, I have horror stories about how under-powered the CPU is on XB1 and PS4. One of my first jobs in Games was optimizing a game recently ported from PC to run at a reasonable framerate on XB1 and sacrifices had to be made. That was soon after the XB1 and PS4 released. The 1X/Pro versions have better CPUs, of course, but they are still garbage by modern standards. In terms of rendering, the terrain tech we've seen demonstrated might strain the GPUs on XB1/PS4, but it should be runnable. So the only real concern is the CPU performance. Yes, KSP2 is reportedly much better optimized, but it's also doing so much more. Additional computations for continuous collision detection, larger structures - even if things like space stations won't be simulated, that's still a lot of additional collision geometry to process, all of the resource and route logic, better physics warp - because you have to for interstellar, and so on. And Intercept isn't a very big team. It's not like Rockstar throwing bodies to get GTA V to run on PS3/360. Intercpet just has enough people to make the game. So I have serious concerns about the game being able to run smoothly on Gen8 consoles. Given that KSP2 is only expected to come out later in '22, and by that point we'll be coming up on 2 years into Gen9, Intercept and PD might chose not to bother with getting the game to run on the older consoles. tl;dr I wouldn't be surprised if we don't see KSP2 on PS4/XB1 or if it's a cropped down port, possibly, managed by a 3rd party developer on behalf of Intercept and Private Division.

In case you or anybody else reading this is serious about looking into careers in games, here's what you need to know. If you go to almost any studio's site, you can find list of openings they are advertising. Like @KSPStar posted above, Jobs at Intercept Games. Currently, the openings at Intercept all require engineering, art, or design skills. But in general, there's a pretty wide range of qualifications that game studios look for. Click on a job title, and it should send you to a page with a description. The two sections you are most interested in are Responsibilities and Requirements. Together, they give you a pretty good idea of what you need to know in order to qualify for the job. If you want to work in game development in the future and plan to train for it, these are good targets to set for yourself. Note that education and prior experience requirements can sometimes be waved if you have a strong background otherwise. I've worked with people who got hired into software engineering position in games straight out of high school. But in any case, you have to have skills that the studio is looking for. For some more examples, Private Division has a jobs page as well, and besides the jobs at Intercept, they are also advertising a few positions in main offices and at Roll 7 studios. These include management, production, and QA jobs. Take a look around, see what studios are hiring for what. It's exceptionally unlikely that you'll be able to be picky about which studio you work for when you start out, but you can definitely use this to set future goals. Game development is a big hard to get into from the ground, but once you are in and build up a bit of experience, especially if you are good at what you do, it becomes a lot easier to look for jobs at studios you specifically want to work at. And if you're really good, you can often just ping the studio HR and see if they'll hire you even if they don't have an advertised opening for your skill set. Studios are always looking for good talent.

If you tried to build it out of normal protons and neutrons, it'd turn into a chunk of neutron matter, absorbing most of the electrons. A few electrons that remain would most likely act as if they are inside a (super?)conductor. That is to say, they'd still be waves, and actually way less localized than they are in an ordinary atom.

Because it's a wave, like all particles. And orbitals are just a kind of standing wave you get in central potential. It's like if you grab a string, you can make a wave that's just a single arch going back and forward, or two arches with a node in the middle, or three arches with two nodes, etc. These are the harmonics or standing waves. Orbitals are the equivalent for electron waves near an atomic nucleus.

It's hard to get a moddable game past console reviews. Sony in particular tends to be very restrictive about content they will allow on their platforms. This means you couldn't get new models for components or any plugins into a console version without rooting the console. What could happen, if there is in-game scripting, is something similar to how Workshop works in Steam, letting you download craft, game mode scripts, and possibly game saves. That would still be very limited compared to PC modding, but it could help fill in the gap a little bit.

People have been doing pretty cool stuff with available parts. Personally, I'd prefer some sort of ability to implement logic with robotics, so that you can build a good walker controller. Then it'd be much more fun to just build custom mechs of all sizes.

Yeah, the terrain tech was completely overhauled since then. They might support cut-outs now, which are basically holes in your height map, and then you can stick a physics mesh in there. Kind of like the way you can get overhangs with Mun arches in KSP. If you allow for holes in the height map, it's a lot easier to include an entire cave system as a 3D model. Of course, I highly doubt they'd go procedural for these, as developing a good procedural caves generator, something you'd be happy to just run in an otherwise highly polished game, is actually a lot of work. So if there are cave systems, I'd expect just a few hand-made ones as special points of interest. I wouldn't expect a lot of cave systems to discover all over.

Ground effects are relatively easy. You can do most of this with decals. Ideally, you want to use virtual texturing for terrain, in which case, the cost of decals averages out to almost nothing, since you don't have to render them every frame. But even with traditional decal rendering, if you don't have too many, it's not a huge overhead. Displacement mapping can really sell the footprints being 3-dimensional despite being rendered as flat textures. The landers not sitting on the surface is a separate issue. It has to do with how collision is built from the height map, and the rendered terrain is smoother than the physics terrain. This one's a little tougher to fix. In general, terrain LoD is not an easy problem to fix gracefully. Simple fixes invariably lead to some amount of floating. Thougn, IMO, that would be preferable. The correct fix for this is for wheels, kerbals, and lander legs to use a direct look-up into the terrain texture. Again, ideally, you'd be using a virtual texture and a compute shader to probe the heights. That allows your physics to have the exact same terrain height as your rendering. You would have to handle LoDs separately, but so long as you store the exact position when lander was in highest LoD and then freeze it when you move further out, it should be fine. From the distance, it does mean the lander might hover above or sink a bit into terrain at lower LoD, but as that happens from a bit of a distance, it shouldn't be nearly as noticeable. You'd also be able to expand the range at which this happens with better graphics hardware, as this is now entirely a GPU problem. The real challenge is getting all of this to work under Unity. It does now come with basic virtual texture streaming support, which might be adequate. Ideally, you'd want to do some custom rendering to virtual textures, so that you can add decals, etc. But even if it just handles LoDs for you, that's technically enough to have the functionality described above. All you have to do is make that texture available both to rendering and compute passes and you should be set for running pixel-perfect terrain collisions for landers, kerbals, and rovers. P.S. The real power of virtual textures used for height maps is that you could actually do dynamic cratering. I know that Intercept said they have no plans for it now, but if they were to use virtual texturing for terrain they could introduce it in the future.

I'm not saying it won't be ready. I'm saying it won't even be worked on as a core feature, because it's not feasible to build a game with multiplayer core given the resources available. Moving multiplayer development to a supporting feature is exactly how the risk is mitigated. If it doesn't land, you still have the core game and you can land multiplayer in a patch. Once multiplayer lands, whether at release or a few months later, great, you have a much better product. My impression is that this is the problem with your entire analysis. This is what you want from the game. That has no bearing on how the game is designed or what the team's objectives are. I'm seeing absolutely no supporting evidence for multiplayer being something more than a way to play the game co-op, and that's not a core feature. There have been no mentions of social, infrastructure, or any sort of features in support of multiplayer as core. What we have seen a lot of evidence for is expanding the game's progression and new user experience. These are all core features of KSP2 and they are clearly there to make sure the game is a complete experience out of the box even without the multiplayer. Very clearly, Intercept's design team thinks they can have a complete user experience as a single player game. And this is a crucial disagreement with your premise that KSP2 cannot exist as a successful product without multiplayer. Once you accept that KSP2 can be a game that a huge number of people can enjoy without multiplayer, that such a game will sell and generate revenue, the rest falls into place. You build core gameplay around single player experience. You start with the gameplay loop of KSP, which is perfectly solid, and you work on improving progression. The basic pitch of KSP but with new star systems to explore and with a good, well-designed progression system to replace career/science in KSP is absolutely solid. That alone is a game a lot of people want to play. I'm fairly confident that this was the entire pitch for Star Theory's original project. The next iteration on top of that is adding better tutorials, base-building as part of progression, and multiplayer. This increase in scope is why the game is coming in '22 and not '20. And while tutorials and base-building have clearly been integrated into the progression, meaning they are now core features, we've heard hardly anything about multiplayer development. Which wouldn't make sense if the entire game was overhauled to be multiplayer-first. But if you look at multiplayer as a bolt-on co-op feature which doesn't alter fundamental game progression and merely lets you experience the game with a small group of friends, then all of it makes perfect sense. There are multiplayer-specific design challenges that have to be addressed, such as what happens when two player ships dock together and how to handle time-warp, and there are some fairly hard challenges about synchronizing KSP2 gameplay across clients, but nothing an engineer with multiplayer background can't solve. This approach fits into the team size and background, presumably, because it fits within the budget Private Division was willing to invest in. It also fits into development timeline and history of the project transitioning from Star Theory to Intercept. If you think you have plausible hints to the game being a lot more than that, I'm actually curious to take a look at your sources. There could be something I missed. But right now, everything looks like a complete picture with assumptions above and there are a whole bunch of missing pieces or pieces that don't fit if we make your assumption about multiplayer being a core experience of the game.

The problem with this kind of analysis is that most games on PC are GPU-bound. So having a 1660 Super is usually going to be the performance bottleneck on that build, and that's a pretty decent graphics card. So yeah, most games should run fine, and in terms of graphics, there's absolutely no reason I can see why KSP2 should struggle with it. You might have to set vegetation density one tick bellow maximum, if that's a tunable setting, or something like that. However, KSP was a very CPU-hungry game. KSP2 is expected to be much better optimized, but also has a lot more to do on CPU, so it's still almost certainly going to be limited by CPU performance for most people. And this is where things get complicated. Like I said earlier, the minimum spec I'm confident in having decent performance is PS5. Because if they can't get it to run well on PS5, they might as well just quit now. On paper, PS5 CPU has more than twice the performance of Ryzen 5 2400G. However, most of that comes from extra cores. In single thread performance, the difference is about 20%-25%. Which is still considerable, but if KSP2 is still mostly bound by single-thread performance and Intercept manages to optimize that thread's performance a little better than PS5 would need, then the 2400G might do just fine. tl;dr: That setup might be entirely fine for KSP2 - there is no glaring problem that would make me heavily doubt it - but there is no way to be certain at this point. Good news, though, is that even if your CPU can't handle KSP2, that's the only part that needs an upgrade. You currently have an AM4 socket motherboard, and that will easily take the aforementioned Ryzen 5 3600X, for example, or even something a bit more modern. Obviously, no need to rush for anything, and the best strategy is to just wait until the specs are announced and then consider if it's something worth upgrading over.

A lot of these are worded poorly enough to be either ambiguous or just wrong. It's pretty clear that the author took some interviews not meant for purpose of creating this quiz and created the quiz without letting anyone proof-read it for accuracy.

Taking the most complex feature and leaning into it as your core without having people to actually land it is the exact opposite of risk management. KSP2 runs custom physics in multiple frames of reference on an engine not built to do any of that, let alone provide any frameworks for networking it. Just getting two ships to be in the same general area without getting Krakened to bits is a huge challenge. So yes, imagine that, making an FPS multiplayer game in an engine that's been used for over 20 years for making FPS multiplayer games is orders of magnitude easier. And having kept track of KSP2 development since first announcement. And having played KSP since alpha days, digging into its internals. I believe, there are some posts here where I analyze disassembled code of old aerodynamics functions and some reverse-engineering of engine thrust curves. And having experience with Unity as an engine as well as numerous others. And having worked directly on multiple game titles for better part of the decade. And having experience maintaining two in-house engines, including relevant components, like physics and networking. And leading game teams as a lead engineer. And... Do I need to go on? I've been involved in games as manager, engineer, and as modder for a very long time. I made it my career to know how games are made from the ground up across all available technology. I can take a look at footage that's been published, the articles that have been written, the time-line as presented and as it changed over time, and combine it with what information I see about engineering staff to make concrete predictions about what the team is and isn't capable of, because that's pretty close to my job description.

Yes, as someone who was in charge of server architecture with a title of "Senior Software Engineer," I'm well aware of it. But I did have two years experience in working on character movement on an MMO by that point, and I had previous experience that prepared me for that. It's not just the title. You look at what people have done in the past. Networking is not something you pick up on a weekend. Yeah. Unreal Engine is made precisely for making FPS games and comes with built in networking support to make a team-based MP FPS game. You can make a WWII FPS in Unreal Engine 4 with exactly zero engineers of any kind. You just need a few designers with Blueprint experience. It's not going to be amazing without some custom work, but it's the exact thing the engine was built for. Consequently, a very small team can make a pretty decent FPS in UE4. None of this applies to Unity and KSP2. It's a tiny team with a lot to do. All of the game components have to be written in C# - there is no mechanism for designers to stand up something functional. (I mean, you don't want to ship a UE4 game running on Blueprints either, but at least the stop-gap is there.) UI also takes engineering work in Unity. And then you have the rest of the game. LinkedIn lists 11 people who have "engineer" in their title. One is an EM, one is a build engineer, one is physics engineer, and one is multiplayer engineer. One other is Animator/Engineer, so most likely a tech artist. That leaves you with six people to build you the rest of the game. Given that there is only one EM, this is probably the exact count. That's barely enough engineers to just make the damn game. Just replicating KSP with optimizations, adding colonies with all of the new systems surrounding that, new progression/science gameplay, UI for absolutely all of that, an onboarding and tutorial system, and then debugging and polishing and optimizing, because having KSP2 run like KSP is just not an option. All of that needs to be made in 3 years with 6 engineers, because the other five are spoken for, and we know that even some of these 6 didn't join until at least mid 2020. I'm an engineering manager - technically, my title includes the word "director" in it - and it's my job to figure out how to make a game happen while not having enough engineers on a team. And this one is hard. Doable, but hard. But now you want to also add multiplayer as core feature? One around which everything else is built? With all the dependencies and infrastructure night mare? Without dev ops, infrastructure, with one build engineer, and with multiplayer engineer not even available day one? Just... How? Looking at profiles of people in charge of KSP2 as a product, starting with Nate and going up, they are neither magical wizards nor incompetent. Competent person is not going to try and make KSP2 have multiplayer core with this team without having supernatural powers on their side. A big important feature? Sure. But one that can be removed from the game without making the whole thing collapse. Whatever precise form KSP2 multiplayer will take, it is a side feature. An addition to core gameplay to be enjoyed with your friends, and not the only reason someone might buy this game. Because if multiplayer was critical for KSP2 success, this game would not get a green light to be made with this team. If KSP2 could not be shipped without multiplayer, it would have been canceled when the contract with Star Theory was dissolved at the absolute latest and probably not even make it that far.

LinkedIn is how you get a job in the industry. Your resume isn't as important as your LinkedIn page. So you have one, you keep it up to date, and when you start at a new studio, you add it to your profile. It doesn't reflect the studio 100%, but it's close, and I can correct for discrepancy. No, for a multiplayer focused game you need about 20 multiplayer software engineers. Between infrastructure, networking, ops... That's actually an optimistic count. If your game is just some light co-op in a monster masher, or something like it, you can get away with a team of a few. But this still implies that you have a solid single player campaign and you're building on top of it. The single player part is still your focus. You aren't building a multiplayer-focused game with one engineer who has prior multiplayer experience. You just don't. They had vacancy listed for multiplayer designer for at least half a year after the switch to Intercept happened, and the multiplayer engineer wasn't a first month hire either. This game has had a significant chunk of its production done without any multiplayer experienced developers on board at all. They might have planned on inclusion of multiplayer, but to think that this has been game's core from day one is absurd. They were not staffed for it and they aren't staffed for it even now. Only if it's a core feature you can't cut. And if that was the case, you wouldn't start production until you have multiplayer designer and lead multiplayer engineer on board. They didn't have either. They still don't have a multiplayer lead, because there isn't a multiplayer team. So it's very clear that it was not considered a core element of the game. I have done game pre-production, so I actually know how these planning meetings go, and you absolutely would not kick off a game with multiplayer as core with the team they've had.

So this is a tricky one. On one hand, yeah, PS4 could still be quite dominant - and, I mean, even 20% of the market isn't something you want to just drop, and that's optimistic for gen 9 - but it's also something that would have been forecasted from about a year back, and I don't think anybody expected launch of gen 9 to be this rocky, despite problems. So it's likely that either PS5 or XBSX is the main target platform - the one most of the development is being done daily. This means that getting everything to run smoothly on PS4 is still going to be a last-minute hassle (it really shouldn't be, but that's how these things go) and if the game still runs poorly on PS4 a few months from release, it might get delayed or canceled. Publishers right now are terrified of pulling another Cyberpunk. So they might just take that loss rather than risk it. Especially, if there will be additional costs and/or delays associated with getting the game onto PS4. To be clear, a lot of this logic also goes for XBox, so PS4/XB1 are a packaged deal here. XBSS is an interesting special case, but it's only slightly underclocked compared to SX and GPU shouldn't be the bottleneck. This means your best choice for target platform is still PS5, because if your game runs well on Windows PC and on PS5, it's almost a guarantee that it does well on XBSX. You get CPU coverage from PS5 and API/shader coverage from Windows, so there really shouldn't be any surprises other than some mislabeled UI. But some of this is hindsight. It's entirely possible that XBSX is the main target for console development in the studio. Oh, and you might ask, "Why doesn't everyone just run every platform?" That's actually a lot of overhead. You need one platform to be the go-to for the studio so that it always has a build in good shape. If you have to do this for every platform, that's a lot of effort wasted on fixing issues that aren't actually going to impact the shipped game. One approach I've seen that works well on larger projects is if you have multiple studios, they work on different platforms. But for something of Intercept's size, the most sensible thing is to pick one of the consoles and use it as primary.

I'm starting to think that you are expecting a different game than the game that is being made. I'm worried that you might be very disappointed. Going by LinkedIn page, Intercept is very engineer-light overall and has just one engineer working specifically on multiplayer. There might be more people involved, but there aren't a lot of people with multiplayer experience to begin with, so the multiplayer work being done is very light. Multiplayer is not the main focus of the game that Intercept is currently working on, so the rest of your argument does not follow.

This is starting to approach efficiency of industrial steam turbines. Not bad.

No it won't. Happens all the time with games that have way larger profiles from way larger companies, and it always goes over quietly, so long as information that multiplayer is going to be available via a patch is published with a bit of an advanced warning. Multiplayer is a kind of feature that introduces a whole bunch of fragility to a game. And if the game is in a shaky state, your options are delaying, releasing a broken game, working dev team to a mental breakdown in a crunch, or releasing without multiplayer. The later is by far the least bad option. You develop the game with multiplayer, then you look at your bug list 6 months before certification, and there are 10 months worth of fixes in there. Five of these are multiplayer bugs. What do you do? That's right, you focus on single player bugs, get them in to cert, and then spend the rest of the time working on multiplayer bugs. If cert was submitted, say, two months in advance, you manage to get 3 months worth of these multiplayer bug fixes in by the ship date, and you just need two more months of work before you can cert the multiplayer patch. The numbers are made up, but situation is real. It's more common that multiplayer bugs are fixed by ship and is enabled with day-one patch, but game as-shipped not having multiplayer is practically the norm. Of course, a lot of games ship as coasters these days, but that's a separate story.

From perspective of developers and publishers, if things aren't ready for launch and it comes down between finishing multiplayer or polishing main content, they will opt to polish main content. I'm not saying this has to happen at all, but if there is a problem, multiplayer is likely to be the first thing on the cutting floor. And nobody's going to abandon it - it might simply land a few weeks after initial release. Alternatively, it might be there, but missing a lot of features that would be vital for good experience, like synchronizing time warp or something. And I think that's fine. Even if the biggest thing you want is multiplayer and you won't play the game until that's in, I think a few weeks of delay isn't going to be a huge problem after we've had to wait this long. And yeah, it kind of sucks that devs might be pressured to release the game when not all features are ready, but I also understand that release schedule exists for a reason and it's a thing that sometimes has to happen.

^ I really hope so. We need nuclear power in this world right now. Green renewables are great and all, but they aren't going to be enough basically ever, and we can't wait until fusion becomes economically viable. We can't afford to keep using fossils as a stop-gap for this long, and nuclear is the only alternative we have right now.

Games just don't ship finished anymore. It just doesn't happen. There will be updates and patches. I wouldn't be surprised if some of the core features aren't enabled on ship and will have to come in as patch, like the multiplayer, for example. But also, yeah, I expect DLC. I would expect it regardless, but this is a Take Two game. They are going to milk it. It has been promised that there will be no micro-transactions, and I hope T2/PD don't go back on that, but that means DLC will be even more prominent. I would expect something fairly significant within the first six months. And yeah, multiplayer is a concern with DLC. There are good ways to address it and greedy ways, and I really hope they don't start pay-walling players out of multiplayer content. Ideally, yeah, I'd like to see a system where other players who have DLC can still build with DLC parts and you simply can't add them to your own ship if you don't have the DLC.