K^2

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.

You mean inter-player? Because I would appreciate it if people didn't build research stations inside of me. (intra- vs inter-) For comprehensive inter-player economies, you might need mods. Given the current team composition, I would guess that it's way beyond the scope of what Intercept is planning for multiplayer. But it is well within what you should be able to achieve with mods.

Though, if there is a dedicated server, I'm sure there will be mods that will let you play the game in a similar way.

I highly doubt that majority multiplayer will be anything other than inviting other players into your save game, effectively. Think Multiplayer in something like Terraria. So long as you can trust people you invite, it shouldn't be a problem. But hey, maybe have a backup of that saved game just in case. Now, hopefully, dedicated servers will be a thing at some point, and people will be able to host community servers. That stuff will take moderation. If you make it open, people will grief. If you don't ban people for grieffing, it will get out of control. But it's not really a new problem. Minecraft servers are kind of in that category, and so long as there are good community moderation tools or if you are a bit more selective about people you invite it should be fine.

That depends on nature of NDA and relationship between influencer and company. There are definitely examples of companies going exceptionally heavy-handed on this, but there are also examples of high-caliber influencers pushing back on that. The purpose of an NDA between a publisher and influencer is to make sure critical information that's meant to be revealed in due time isn't shared early. An NDA that prevents an influencer from actually sharing their opinion of the game is garbage, and it's not even an NDA at that point.

Depends on a lot of factors. Our best tool for measuring how fast stars are moving is still going to be red shift. That means that you have to be able to detect spectral lines. If you are looking at a star in our own galaxy, you can resolve individual star with Hubble and then you just have the spectrum which you can use to measure the movement speed precisely enough that you can tell what kind of planets are orbiting the stars by the wobble in speed. The precision of measurement can be as good as a few m/s. When looking at stars in another galaxy, you aren't going to be able to resolve individual stars, but so long as there are a few particularly bright stars in a "pixel" of the image to give you clean spectral lines, it's good enough. So for "nearby" galaxies at least, so long as their plane of rotation causes stars to move towards and away from us, we can do very good measurements on velocity distribution around the disk. These are precise enough for us to tell how much dark matter there is in the galaxy, for example, and we've been able to corroborate it with gravitational lensing in some cases. There is also obviously a limit to this. As you are looking further out, the stars are going to all blur together, and at some point, you're lucky if you can get an average speed for the galaxy. There is a way to put some theoretical limits on this using the size of the Hubble's main mirror, but I have a feeling that the instruments capable of spectral analysis aren't going to be able to have the same resolving power as the main cameras, so I don't know if that would be a useful estimate. Orientation of the galaxy will also matter. If we are looking more along axis of rotation, there is less red shift for us to measure. All of this combined, I don't really know at what distance the above methods are actually effective using Hubble.

That's actually a great point. Yes, spending time actually providing better data to influencers is absolutely worth it. I still don't think a blog post linked from a forum is the right way to do this. A modern marketing effort should include direct outreach to influencers, and whoever's in charge of that, should be able to figure out what information is useful to provide to influencers. Fortunately, most influencers that actually reach high popularity know that having access to information is helpful to their career, and treat NDAs very diligently. So you can usually trust them with information about the game, knowing that they'll be able to build up hype without saying anything you ask them not to share too early. Yeah, and it's a factor, but it tends to work as a multiplier. Prior to game's release, the only place where overwhelming majority of word of mouth originates is still marketing material. Again, very few people will have special insight into how the game is made, so most of the people saying, "Wow, take a look at this game, it seems fun!" are going to be influenced primarily by trailers. So the fact that word of mouth helps the information spread doesn't change your marketing tactics. In practice, very few people do. Ability to refund certainly helps, and very public disasters like Cyberpunk release help to improve the landscape, but the numbers still show that trailers and marketing sell the games. Just because numbers on this ended up fairly public, number of pre-sales of Cyberpunk that were not refunded was enough to cover cost of development, despite it being the most refunded (in absolute quantity) game on record. Any sales they made on top of pre-sales are cherry on top. It's very important cherry, so fortunately, there is still an incentive to make a good game, but marketing is so much more important to game's sales. And I'm saying this as someone firmly on the dev side of making games, absolutely loathing the fact that good marketing sells more games than good production. But I'm also involved in enough meetings where marketing numbers are shared to know that this is absolutely the case. And almost all of the marketing return is from trailers. How these trailers are shown to people still matters a lot, but it starts with a sequence of pretty pictures. I should probably add that I'm mostly talking about the sort of things that game creators have control over. Sometimes a game blows up because it became popular with streamers, and sometimes it's purely on good game mechanics. Games like Among Us absolutely deserve it, but it's also not something anyone can possibly take as an example of doing things right. And sometimes something becomes popular just because it's a meme. Either way, it's not something that helps you figure out what information you should or shouldn't share about the game in development, unfortunately. The only rule of thumb that's been developed is that it's more damaging to share too much than too little. And in that light, I'm actually glad whenever developers take a bit of a risk and give us some early previews.

It's entirely possible that they just really wanted the background with rings, but the planet that was supposed to go in there wasn't anywhere near ready enough for a close-up shot, so they dropped in Duna instead. So this very well might be a Duna/Ovin hybrid or something like it. The terrain does look very Duna, though, so I doubt this is actually something new either way.

I'm not sure you've spent enough time in modding communities of either of the games you are quoting. Back in GTAIV days I was helping out a team trying to port San Andreas to IV engine by writing an air sim, since IV had no planes. The team fell apart, so this was never finished, but I had a working prototype. I've put a video in a spoiler. Aerodynamics ran as a custom component tick on vehicles, read in relevant parameters, computed aerodynamic forces, and applied them to vehicles. It also controlled animation on relevant control surfaces. The mods worked as injected C++ code and could control just about any aspect of any spawned entities or spawn new entities. With GTA V, the modding tools have only become more complete. I can say with confidence that it's easier to remake entire KSP in GTA V than it is to make anything like GTA in KSP. And this is based entirely on community-made tools. R* has never intended for their games to be moddable. Skyrim's only problem is a really bad, really outdated engine. There is absolutely no limit to what you can do with mods there other than just the engine sucking abysmally. There are complete overhauls of magic, combat, crafting, etc. If you look at what people have done with mods there, it's way more extensive than any other game out there. People have made entirely new games in Skyrim. Although, they do tend to stick to the theme, because if you're not sticking to it, then you might as well work with FO4, which also has plethora of complete overhauls. And, of course, you have to remember that real mudding started with id Tech games. I learned a whole lot about game programming by making Quake II mods. Later, I've messed with HL2, which is its own engine, but heavily inspired by design and style of id Tech. These were games made on in-house engines that were good enough that these engines ended up getting licensed out. But they were first-party engines first and foremost and they are practically responsible for us having expectations of mods that go beyond simple graphics replacements. The only thing Unity has going for it as far as mods is that there's already a huge community of people creating tools for modding any Unity game. Which means that even if Intercept isn't going to put in an effort into allowing mods, people will be able to mod KSP2. Which is great. But first party mod support is always better, especially early on. And it's actually easier to give people modding tools as a developer if you have full access to all aspects of the engine. Allowing for easy mod import in Unity requires adding side-loading capability, which is not something Unity is designed to handle gracefully. Unity expects all of your assets neatly packaged, and working around it actually means inventing back doors. You don't have to do that if you have your own engine. Games by Bethesda, id Software, and Valve that are designed to work with mods will specifically search directories for additional archives, scripts, and even dynamic libraries to load because they are designed to be moddable. Which means you can package new assets and game code in the way that engine actually expects it to be formatted making results far more consistent. Sure, but no explanation of early work is going to do anything for majority of people who might buy KSP2. The percentage of people who are going to read any kind of explanation on a forum is tiny. Most sales will be made on trailers and marketing that will be released in the last couple of months before release, and these will be tightly polished just to show the game from the best angles. None of it has anything to do with how the game might or might not run either now or in the future. It sucks, but games just aren't sold on facts. They're sold on pretty trailers.

I'm not sure the overlap between people who would understand a write-up on that and don't already know all of that is large enough to worry about. Anyone who worked in games knows that Release runs like molasse and Debug doesn't run at all. And anyone who hasn't but has the tech background can at least appreciate the difference between /Od and /O2 and extrapolate from there.

I don't have the full story, and probably nobody but their top execs do, but there have been several key turning points, I think. First, Unity chose to monetize via asset store. Which is questionable choice if you're trying to make a good generic game engine for small size professional teams. Even Roblox has a better strategy, combining asset store with in-game micro transactions. Second was their boom in mobile, simply because there was very little competition. Finally, they branched out into non-gaming applications. Do you know that there are amusement park rides that run on Unity? Yes, I'm scared too. Fortunately for Unity and unfortunately for the rest of us, they have taken in enough investments to the point where they didn't have to compete on profitability for a very long time, and maybe still don't. Which means they don't have to have a good business model. They just have to keep growing the customer base. Yes, but this has been the case since mid 2000s at least. The only reason we haven't had a gaming crash yet is that we are in new territory of market growing so fast that the threshold for disaster has been moving away at equal or faster rate. But yeah, we need new alternatives and new companies making better choices, because the current situation isn't infinitely sustainable. Eventually, the games market will not be able to grow further.

Realistically, radiant heat is going to be a problem. Ever tried to hold your hand near a hot electric stove? Where it starts to burn your hand without any contact and not from hot air, but directly with infrared radiation? That's what you'd be dealing with. If it's hot enough to incandesce, the equilibrium temperature is going to be close to 1,000K. Hotter than surface of Venus. Now, while you are approaching it, and out of influence of atmosphere, there are ways to mitigate that. A thin foil shield, reflective on side facing the star and black on the side facing the craft, can give you about a 100x advantage on energy flow, and temperature ratio is fourth root of that, so we're talking a little over 300K, which is just a bit above comfortable room temperature, so that's perfectly fine. But you're not going to be able to maintain this arrangement going into the atmosphere. And because brown dwarves are large, you can't just go in for a quick dip. A glancing trajectory getting you into the atmosphere has you in atmosphere for a relatively long time. So now you have entry heat in addition to incandescent heat from bellow and very little in terms of where you can dump excess heat. You can probably get great data for a short while, but I'm pretty sure it's a one way trip for any probe. How much of that would get implemented into the game is hard to say. Even if they add radiant heat, you might be able to cover your craft with enough radiators to offset that and go in for a dive. But, you know, that's why it's a game.

For a personal or indy project, absolutely. Go Godot. That would honestly be my first recommendation for anything a team of up to about 10 people or so can make. I didn't mean to make it sound like it's bad in general. It has some good features, solid roadmap, and admirable goals. Unity and Epic are horrible companies, and it's great to have Godot as alternative to dealing with either. But it's raw and still in early development by engine standards. You can't ship a large game on it right now. So it was never a viable option for KSP2. Purely in context of KSP2, I don't see any engine on the market that would work better than Unity. Rolling their own, making good use of middleware, would be my second choice for it. And having maintained in-house engines, knowing how much work and effort goes into it, I'm not suggesting it lightly. Unreal comes in at solid third, but it'd probably force KSP2 into EGS exclusivity, potentially reduce ability to mod, and no guarantees that it'd end up performing any better. More uniformly across platforms, for sure, but I don't think Intercept would be able to avoid heavy use of bad Blueprints, which would tank any gains from a better engine architecture. You can complain about Unity, and I'll pitch in my laundry list of grievances about engine, documentation, and company, but there isn't actually a good alternative for this size project with this size team.

Simply clicking export to Linux, then fixing most egregious problems after they are reported by the community is not what I call support. More importantly, I don't think Unity provided a lot of support for running on Linux. Unity started out entirely in Mono. It sucked. I remember trying to just debug projects in Unity back when it was originally running in Mono and it was a bad experience. Half the time your breakpoints just won't even get hit. So Unity ditched it in favor of CLR on Windows, and that became the only version anyone cared about - both inside Unity and most of developers using it - for quite some time. Mono remained as the version that provides Linux and OSX compatibility, but it kept getting worse and worse, as it was clearly not properly maintained. Add to that the fact that C# 3.5 support was originally added via transpiling it to 2.0 in Mono, while it had native support on CLR side. And while all this mess is happening on the side, KSP is being developed and expands into a larger and larger game. Recently, as in the past 4-5 years, this has been rapidly improving. Mobile games got larger and more complex, and the older versions of Mono were no longer cutting it. Mono project started getting better updates and Unity started pulling updates to their fork more often as well as adding more fixes to their private fork. Unity2017 had improvements, but it's really only with Unity2019 that things started getting significantly better. Last update to KSP, as far as I can tell, was in 1.8 with Unity2019.2, which is from over 2 years ago. And even this version was more about optimizations for OSX and Android than Linux specifically. Though, it's still way better than what it used to be. This is all changing pretty rapidly. Apple is making big moves and has worked with Unity to make sure it runs well on M1 laptops. I don't know if it's anything that will make it into a public branch of Mono or will stay entirely within Unity, but either way, a lot of improvements have been made, and many are platform-agnostic. The most recent versions of Unity runtime are pretty dang well performant on both OSX and Linux. So there's still hope that KSP2 will be able to benefit from that. But KSP's almost entire life span coincided with what was the worst period for Unity games on Linux. So I don't even hold it against Squad too much. I just wish they didn't try to market it as fully equivalent build to the Windows version.

Lets leave aside the fact that KSP2 was originally meant to be a much smaller game and recycle a lot more of KSP work, which influenced Unity choice greatly. But lets pretend that you could start from scratch. What are other options? Well, Godot is just worse. It has great potential, but it will be years before it's even simply caught up to Unity in the best case scenario. Unreal can be a decent engine if your team has the discipline for it. You get the advantage of running native code if you write custom components and that can be more performant, easier to debug, and is guaranteed to run clean on all platforms. Great! On the other hand, none of the features of Unreal are especially useful to KSP2. From perspective of engine utilization, there is really no difference. But what's worse, Intercept is content-heavy engineering-light kind of team. In teams like that prototyping will be done in Blueprints. And if you don't go back and replace all the Blueprints with custom component code, it's going to be more performance problems and more bugs than you would likely ever have with Unity. Intercept needs to be 3-4 times larger as a company to make good use of Unreal. CryEngine/Lumberyard. One of the few I don't have first-hand experience with, but everyone I worked with who do say it's a nightmare. Content pipeline is, allegedly, very difficult to navigate, which is a death sentence to project like KSP2. RAGE is T2, so maybe R* would share. But you'd have to basically re-write physics solver, because Bullet is the only thing that's even worse for KSP2 than PhysX, and build a new component model for all of the ship parts. It's just not built to handle the kind of game that KSP2 is. You really might as well be writing things from scratch at this point. What's even left? id Tech? That one's actually not a terrible option if you could even license it. Zeni wasn't big on that in the past few years, and I don't know where MS stands on it. But you'd also be making glacial progress on new features. There is just no good path for designers to prototype parts. So again, you'd want a larger engineering team to be making progress efficiently. Source is basically in the same boat, as it's heavily inspired by id. Plus, we haven't seen a public update in a while, so it's hard to say what state it's really in as a 3rd party offering. Everything else is proprietary. You do get some sharing occasionally, but you'd have to make your own deal, and none of them come without the same problems as either Unreal, CryEngine, id Tech, or all of the above. So that really leaves one final option, which is to roll your own from scratch. You already need to roll your own asset system, effectively, to handle ship parts. Rendering for KSP2 is so simple that you can do a fixed renderer, rather than complex graph renderer. It's not best utilization of resources, but it'd make it very easy to create DirectX12, GNM, Vulkan, and even Metal versions of renderer. If you have an asset system, a renderer, and you slap Havok physics on top of it, you basically have a framework for KSP2-like game. You still need to figure out animation, FX, UI, and various I/O systems, but it's a manageable workload for a mid-sized team. The only options that get you to an Alpha faster are Unity and Unreal, and you aren't going to have the same Blueprint problems pushing it to release as with Unreal. So this is actually a really solid option. But it still requires a larger engineering team staffed with more experienced engineers, and you need a longer pre-production runway for engineers to build the foundation. None of this is available to Intercept, nor was it remotely likely that they'd be able to have these resources. So that's basically it. It's Unity, Unreal, or custom engine, and both of the latter options would require a much larger investment. Unity is the only one that lets Intercept leverage art and tech art without investing in more engineering, leaving the later to focus purely on gameplay components. It's the only option that gets KSP2 funding to ever be made. Simple as.

It's definitely theoretical. We haven't imaged any brown dwarves at nearly the sufficient resolution to confirm it. (Though, we do have grainy, a few pixels across direct images.) But it's also very plausible. If the temperature is just right, weather(?) variations can form brighter patches of visible light in some areas. The contrast and color filters would have to be juuuust right, but I do think you can capture an imagine similar to above if you were to be in sufficient proximity of a brown dwarf. A brown dwarf star system might be a bit dull to explore, though. There wouldn't be nearly enough starlight to light the planets and moons. So I think the only good place for one is as a part of a binary star system, which kind of makes it sound even cooler, so I'm all for.

There should be a lot more to research, so that alone should give you an incentive to keep going to outer planets to unlock interstellar tech. But even so, early game needs a rebalance. I don't know if starting with aeronautics is the right decision, but I think that should be an option. Ditto probes before manned flight. There is honestly enough there that you can gives you flexibility in order in which you progress through the tech tree. Maybe first tier of unlocks should be a choice between probes, aircraft parts, or larger rockets? With probe branch containing enough smaller rocket parts to get a satellite into orbit? This on top of rebalancing how career and science work would make things a lot more interesting. And to bring it a bit more on topic, I would really like to see props being improved and be viable as your first piece of airplane tech. The first plane you can build in KSP is a VLJ. The only reason to even consider props for anything practical is a tilt rotor. And even then, you're probably going to combine it with jet propulsion and hinges, using props only for VTOL. There's zero reason to build a conventional prop aircraft in the game, and it's kind of unfortunate.

To be fair, I don't believe swept wings do much until you get to transonic speeds, and I highly doubt the aerodynamics of the game will support that sort of nuance. For starters, it would turn designing functional aircraft into an absolute nightmare. Forgot to consider layer separation due to the fuselage profile? Well, you've just lost input from your tail control surfaces and are now in a supersonic dive into the terrain that you can't exit. Hope you didn't bring additional crew and can just eject the pilot! Though, some simple effects, like a sharp increase in drag at transonic speeds requiring afterburners to "punch through" to supersonic might be a nice addition.