Jump to content


  • Posts

  • Joined

  • Last visited


3,085 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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.)
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. 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.
  • Create New...