K^2

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.

I honestly don't know if it's relevant anymore. I know the site says it's coming to PC, PS4, and XBox One, but they haven't even updated it to include PS5 and Series S/X. This game is coming out mid to late '22 now, not early '20. Some of the terrain tech they've been showing off is pretty expensive. Not a huge factor for PS5, but I've recently worked on standing up something similar and we have been testing it on PS4. Which ran alright, I guess. But it was starting to eat into frame rate and this was on a custom in-house engine at a AAA studio, so it was actually pretty well optimized to do this work. KSP2 is supposed to run this with Unity. Even with as much shifted over to compute as possible, CPU is going to struggle a lot. Then we should talk about the core game. Yeah, they're optimizing it. But they are also adding new features. Continuous collisions are new. Time warp will have to support a lot more physics if we're going interstellar. Colonies. None of it has to get particularly expensive, but this is a small team making a big game. Not everything's getting optimized out of the box. I don't think PS4 being a target is realistic. PS4/XB1 are either getting dropped or back-ported with a lot of features cut. At which point, the development platform for KSP2 is going to be PS5. That's going to be the benchmark for "good enough" performance in a lot of QA. Which means, maybe they can optimized it a lot better, but there is high risk they don't, and PS5 CPU will represent a realistic minimum spec. That's not a guarantee, and it's entirely possible the min spec will end up lower, but if you want to forecast and buy something now that will be nearly guaranteed to run KSP2 well, that's your target. So as I explain above, it's not a guarantee. It might end up a lot lower, but PS5 will very likely be their benchmark, which means that optimizing the game for lower spec CPU is not going to be nearly as high of a priority. And it's not that wild on the CPU side. Prices on 3rd gen Ryzen and 10th gen iCore have come down significantly. Either of the CPUs I've listed is ~$300 in US right now and sales are frequent. Which is still expensive for a CPU, but it might not even end up the most expensive part of your build. The GPU you want to pair with this will start in $300 - $400 range and goes up from there. If you want to play other modern games, probably way up. This is an interesting opportunity to consider on-board graphics, though. AMD's APU design is actually quite beefy, and if you can find a way to purchase something like Ryzen 7 4700GE, that can almost certainly cut the mustard on graphics for KSP2. It's a lot weaker than PS5 GPU and is Vega 8 based, rather than RDNA2, but graphics are way easier to make tunable, and I'm fairly confident that Intercept will try to target lower tier GPUs. Now, the catch is that Ryzen APUs are an OEM part, meaning you are only supposed to be able to get them with pre-builds. There are some on the market that are reasonably priced, though, if that's what you're going for. Alternatively, I know people have been able to buy CPUs and boards meant for OEM at wholesale prices from less reputable sources. It's a risk, but if you're familiar with these markets, it might be a great option. I almost want to recommend the Intel's i10700K for the same reason, but I'm not nearly as confident that the onboard graphics there will do the job. It's also going to be inadequate in a lot of other games, so it's a very shaky proposition. I still like it as a gaming CPU, but running it without a dedicated graphics card is very meh. A 12th gen iCore CPU with integrated might actually be perfectly fine for playing KSP2, if rumors are to be trusted, but then we're back to the problem of trying to buy the latest and greatest, in this case, something that hasn't even been quite released yet. So you probably won't be able to save anything overall with this setup, sadly. And yeah, it might go way down from this target. I just don't think even anybody at Intercept knows at this point where it's going to land, so if you buy a CPU now and you go well bellow these specs, you're taking on a significant risk that you'll have to upgrade for KSP2.

We don't really have anything concrete, but I would aim for something circa capabilities of PS5 for CPU min spec. That would mean AMD Ryzen 7 3700X or Intel i7 10700K. There is every reason to expect that while KSP2 will be much better optimized, it will still, just like KSP, be very CPU hungry. So while I fully expect Intercept to make every effort to make the game run well on PS5, I have serious concerns about anything at lower spec. So I think that's the low bar to aim for and, if you can afford to, I would aim higher. On the graphics side, it's a lot harder to say. The GPU on PS5 is very close to AMD Radeon RX 6600 XT, but you will probably be able to scrape by on way lower spec graphics. You will definitely want something capable of DirectX 12, but something like GTX 1060 might actually be adequate, depending on how quality settings are set up. However, unless you absolutely must spend money on a new PC right now, I would wait. Both because we'll probably get better indication of what we need and because there's a huge shortage of anything silicon right now, so prices on CPUs and GPUs are kind of outrageous. It looks like it should start improving in the next few months, however, so probably hold off a bit.

Short term, yeah. So in context, it might not matter, but on a slightly longer term, the rate at which SRB fuel burns depends on the internal pressure. As the pressure begins to drop, less fuel will burn, causing the pressure to drop further, causing an even slower burn, etc. In an extreme case of nozzle being completely removed, it can take the process down to a gentle burn with almost no thrust. Nozzle diameter on solids is actually a very delicate matter. There is a range at which pressure is self-stabilizing, but you make the nozzle too large, and pressure drops to nothing. Too small, and it's a runaway to an explosion. So depending on the nature of emergency. blowing out the nozzle can actually be a way to safely shut down the boosters almost completely. But it's not going to be instant.

It's not quite that simple. The shorter half-life means you get more decay events in the same concentration, but short half-life products also don't accumulate as much, because shorter half-life, so you don't usually get the same concentrations as the longer lived stuff. Not to mention that the kind of radiation matters. In waste, gamma and alpha might be nasty for handling the waste, but they aren't going to poison ground water, dust, or what might have you. Basically, neutron radiation is the only one you really have to be paranoid about long term, and the energy of the neutrons matters a lot. Particularly slow neutrons will just bounce around and decay to trace amounts of hydrogen gas. Very high energy neutrons tend to either not interact or convert whatever they hit into something very unstable, causing immediate collapse, and generally, safer products. But if you hit the energy sweet spot for a particular nucleus that a neutron might encounter, something entirely harmless might become radioactive with long enough half-life to get out there and cause harm, and that's the kind of radiation you really have to watch out for with radioactive waste. Radiation that makes other things radioactive. And some isotopes are a lot worse for that than others and it has nothing to do with their half-life. Now, reactors were never my jam, so I can't tell you off the top of my head how the waste is going to compare. There are complex decay chains for different isotopes of Uranium and Thorium all resulting in all kinds of candidates for bad neutrons, and it would take me entirely too long going through isotope table to sort it out. I'm sure people have done this work and there are probably some summaries out there on how the wastes of Uranium and Thorium reactors compares. The only point I'm trying to make here is that it's not as simple as "short-lived, therefore, nasty."

I can't say with certainty that EA doesn't operate on whole another level, as I have no insight into their internal marketing, but I highly doubt it. Places where I have had a good look at how the marketing is done from the inside don't operate on anywhere near that kind of forethought. Game marketing is entirely reactionary. And to be clear, this isn't a critique - at least, not in whole, They do what works, and trying to plan for the next successful strategy a decade ahead is absolutely not a thing that has been working for anyone. You invest in some number of smaller games that are trying new things, including new monetization tactics, most of which will fall flat, and then you invest the bulk of your effort into replicating what has worked before the demographic preferences change. And they'll do plenty of underhanded things, but horizon on this is measured in months, not years, unless it's something very generic that can be adapted to many different ways of marketing. You know, like match-making against pay-to-win players, because that's something you'll be able to milk no matter what you're actually selling. But loot boxes are too specific. By the time major companies went all in on the idea, the questions of ethicality and legality were already being raised. Current maneuvering reads to me like trying to suck all the profit they can from loot boxes before regulation clamps down, partially in disbelief that it hasn't happened already. Interestingly, a lot of companies are starting to learn that chasing hype with a game that has a six year development cycle doesn't actually work. It's something you ought to have been able to predict, but there is quite a bit of tunnel vision when you've been making games for decades following the same formula. Large studios will have to adjust to build more flexibility into their development cycle. And I do wonder if this is going to propagate into how games are monetized and marketed or if it's just going to create an even larger rift between developers and marketing teams.

And amazingly, tha almost worked. It's hard to abort docking after it is over, but Nauka gave its best and was very close to making it so. On a more serious note, I'm apalled that there are no safety checks on this. You don't write mission critical code that simply executes to completion if a particular routine got called. This is a known bad practice. Whoever's in charge of software needs to be fired and replaced with someone who knows how to write safe code.

I don't think it's meant to. It's meant to take a bite out of that market, sure, but it's clear from price point and capabilities that they aren't going after the whole market. Just taking a bit off the top. For me personally, if I'm carrying a backpack already, I can just put a full size laptop in it. I don't mind the extra weight. It's the extra bulk that I would like to avoid, and Deck does open up some options in that regard.

I believe it's still a UDMH+N2O4 fuel. So theoretically, it is hypergolic and can self-ignite if the valves were opened, but you'd have to have both fuel and oxidizer valves happen to fail simultaneously and in a way that still feeds the propellant through the turbopumps. So I don't think this can be anything other than an error in the control systems. Something had to actually command both valves to open for the engine to kick on.

There's a pretty big difference between the kind of design that's hard for a computer to fly and one that's hard for human to fly. There's an overlap, of course, but it's not a one-to-one. Generally, computer control is good at fast corrections, which allows aircraft with unstable static equilibria to fly true. Think of balancing a broom on its end. Humans can do it pretty well when the dynamics is slow, such as with a long broom, but try the same trick with a pencil - this is where computer can take over and have no problem keeping things balanced. On the other hand, a lot of rockets in KSP end up with dynamic instability. The kind of setup where if you don't mess with it, it seems stable, but if you start making adjustments, there is a tendency to over-correct, and the rocket starts building up oscillations. You know, the sort of thing that you have to fly with SAS off? Humans can usually work with this type of instability. It's not great, but manageable. A computer, unless it's very carefully designed to handle this specific kind of problem, is going to be worse than just letting go of controls entirely. Of course, there are also design problems that are fixable. Asymmetric thrust is a good example. It's super easy to correct for it, especially, if you allow the control system to individually control thrust of the engines. In fact, making this work and having a stock system that can provide stability is actually a pretty good argument for having an assist. I also think there's a lot of ground for a compromise. Nobody thinks SAS is bad, even though it clearly assists in flying the craft. I would try to build on top of that and come up with something that helps like an assistant for complex craft that need it rather than a replacement for human pilot.

They as much as confirmed some of this. Yeah, there will definitely be some unique functionality with Steam OS. I'm just not sure it's critical for most PC gamers. On the other hand, new people coming onto the platform might feel differently. So we'll just have to see how much of an impact that makes in OS selection. Yeah, it's hard to get a good ultra-portable made for US markets. They just never took off here like they did in Japan. If I can find a nice keyboard, or better yet, if someone makes a flip cover with a keyboard specifically designed for deck, I might try using it as an on-the-go PC. I was actually looking at GPD WIN 3 for this very reason, but Steam Deck completely surpasses it in every way except for on-board memory. And even with that, Valve has confirmed that they are using off-the-shelf M.2, so even if it's not designed to be user-replaced, it should be possible. It's a short form-factor, but 1TB modules in that size are available, and by the time Deck arrives, there might be 2TB versions already.

Rogozin, you forgot to switch accounts. I'm not sure if it makes me feel better or worse overall. On one hand, problem exhausted itself. Great. On another, at no point did any of the systems decide that something's going horribly wrong and tried to shut down themselves. No safeties engaged, no cutoff triggered. It just went "%$#@ it, I'm all in!" If it had any more fuel to burn, it would happily rip ISS apart and keep going. That's terrifying.

Steam Deck might actually support Windows Unity games pretty well out of the box. It's mostly a question of how good the CLR emulation is going to be on Proton, and it sounds like Valve has been putting a significant amount of effort into it. Also, I'm not entirely sure that majority of gamers on Steam Deck aren't going to just pave over the Steam OS with W10/11 install instead. So long as AMD provides compatible graphics drivers, it shouldn't be a problem. So we might not see as much Linux gaming on Deck as people imagine right now. In either case, it makes more sense for Intercept to wait until Steam Deck is out in the wild and people are actually playing games on it before committing to it one way or another. But yeah, having more games come with good Linux support would be nice.

Mods! Honestly, I still hope we get some sort of a visual scripting system, kind of similar to how the mission builder works in Making History expansion, but with a bit more capability, and possibly being able to run custom scripts on specific ships - like maybe via a special part. That would let you build any ideas like the above into a series of custom scripts for whatever minigames you want. Making these an integral part of a game would also allow sharing scripts like that via workshop and then you wouldn't need to make sure everyone has particular mod installed before joining in. It can all be automatically shared from the server.

If you use the same trick he did for caching intermediate results and render it in a shader at a reasonable resolution, you can run it on a good GFX card. Lots of tricky math and good programming exercise, but very doable. Of course, if you want to be able to render a ship in transit, there is an additional challenge, since you can't just do an honest ray tracing of it. You'd have to utilize screen space information in a clever way. It won't be perfect, and you'll definitely have some distortions and smudges on the ship, but if it goes through quickly enough it should look ok. (If anyone is familiar with rendering screen space reflections - yeah, basically same problem.)

Eh. That's what mods are for. Ten internet points from my personal reserves to anyone who manages to implement realistic wormhole rendering in KSP2 mod, such as example shown by Scott Manley in the 360 Wormhole video.

Not with Unity. It doesn't scale like that. Even if you grab some exotic enthusiast grade CPU with absurd thread count on high performance cores, you aren't going to be able to leverage full performance of it, and there is no real way to distribute the load between multiple game servers without a major re-write to the core loop. If the game is well written, there isn't some silly cap on resources, and players don't build anything complex, something in health double digits might be doable. But I have a strong suspicion that you'll run into some bottleneck you can't solve with more expensive hardware before you're half way to 100 concurrent players. Now if the game handles ships that are landed or in good "parking" orbit elegantly, maybe you can have a few hundred players have their ships and bases in the game, but you'll still only be able to have a small fraction of them logged in and actively playing at the same time. Could still be interesting from perspective of player economies if there's a good system in place. There is a world where community writes custom infrastructure for this. The most mad lads thing would be a complete custom server written in a civilized language, like C++ or Rust. Problem is that you'd have to port every component, every behavior, every feature of every planetary body, make sure everything's simulated just so... Depending on how server-client is handled that can range from legendary challenge to impossible. But there is a more realistic scenario. Say you wrote a custom server that just handles open space in ballistic trajectories. So long as networking isn't too obfuscated, that might be a weekend project. Next, you make sure that while flying solo you can still interact with your craft and update server. If the game's client-authoritative on forces applied to piloted rockets, this might be a freebie. Otherwise, a bit of work is needed. At this point, this custom server can already handle a silly number of people - tens of thousands wouldn't be a stretch running in the cloud - who are all flying in the same shared space, but can't physically interact with each other. So the hard part is solving this interaction. And you do this by running Intercept's stand-alone server for every player hub. The easy version is to have pre-determined locations where players can meet up. Say, every planet and every moon gets a server. Maybe some specific orbits of some specific bodies as well for orbital stations. Only a fixed number of players would be allowed to gather at one of these at any given time, but you could absolutely instance it. So, like, if you are on Kerbin, you're playing on a version of Kerbin that has up to 8, maybe 16 players on it. But once you depart Kerbin and go build a colony on Lathe, or something, you could be meeting players from another version of Kerbin server visiting you there. Hence one big shared world for thousands of players. At that point, some sort of player economy would make sense, but it'd be basically up to whatever community builds all of that.

Correct me if I'm wrong, but I don't think there's anything concrete in that thread. Here's what I know. Intercept's LinkedIn page lists fewer than 30 people. Of them 10 have engineering roles, including one manager and one build engineer. There is no infrastructure, as far as I can tell, and only one engineer working specifically on multiplayer. Now not everybody is going to have a public LinkedIn profile, so we might not be seeing everyone, but this is a good starting point. Another point of information is that this is a Unity game. There are two general ways to build a real time multiplayer game in Unity. 1) You build it a lot like single-player game using Unity's native capabilities, making sure you specify what game state needs to be synchronized across network. If desired, this can be built as a stand-alone headless server for dedicated server deployment. 2) You write core game systems from scratch in whatever makes you happy. You then run the core either as a stand-alone server or as part of the game client, piping relevant information to game objects. Unity itself acts as basically a 3D animation player to render what's happening in the core. Option 2 is scalable and theoretically lets you stand up as many instances on your server farm as needed to support large number of players. It also requires a lot more engineering support. It only really makes sense if you're building your own infrastructure and focusing heavily on multiplayer. We don't see any of that at Intercept. This isn't something you can hide. So it is Option 1. With that first option, you are limited to two possibilities for core loop. You can have one of the players host a game and have other players join a game running on host's PC or console. Or you can run a dedicated server and have everyone join. Because it is a Unity server, don't expect miracles. It won't scale any better than running the game on your own PC. Which means the player cap is going to have to be pretty restrictive. They might not have a strict limit for number of people joining, but things will digress rapidly as more than a few players join. There are games out there that takes sort of a hybrid approach, where core game loop works via very limited co-op or PVP with just 2-4 concurrent players, but there's a larger metagame that's much more social. Unfortunately, even if someone was to come up with what that looks like for KSP2, even that would require more people working on infrastructure and networking, and we'd see evidence of it on LinkedIn in some way. So it doesn't sound like Intercept is even going to run their own servers. There might be something light for registration and user authentication and they might end up partnering with some cloud hosting service that will make purchasing server instances easy, but my guess is that if you'll want a dedicated server, it will be up to community or individual players to organize. So just based on the tech, that's really all that's left. Either you run your own game and invite a few people to join you across the network or you run a persistent dedicated server somewhere that allows several people to play on it concurrently. Think Minecraft multiplayer as a good example of what that might look like - you can have a lot of registered accounts, but not so many people playing at the same time before it starts struggling. There is still a lot you can do in terms of game design with that, but you have to stay within these technical limitations. Large multiplayer worlds just aren't going to be possible with what they have to work with.