Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

1,734 Excellent


About Master39

  • Rank
    Bottle Rocketeer

Recent Profile Visitors

2,399 profile views
  1. Not getting in this discussion once again. If you really believe that Squad presence can somehow magically transfer the long standing problems KSP has due to being an indie game developed as a hobby project into KSP2 I don't think there's even a point in trying to explain who things work.
  2. A lot of people think that KSP1 problems are some sort of infectious disease that can be brought on to KSP2 when Squad will get their hands on it.
  3. Point is, a 10 minute gameplay demonstrating that yes, a professional development studio is capable of making an indie game look better won't prove anything and won't change the situation. I don't think the technical side of the game was ever at doubt, like someone said regarding load times in another thread it's probably harder to make something work worse than some parts of KSP than it is to make something better with proper professionals and the benefit of hindsight. Again, the podcast interview contains more information that all of the rest of the footage and screenshots they released
  4. You get none of that with 10 minutes of gameplay. At best you would get a glimpse of the flight UI and half a good look of the part of the VAB they'll use, and a general idea of the level of polish they put in that specific cherry picked slice. Don't get me wrong, I can't wait to see the actual game in action, but I'm not trying to rationalize it, I just want to see the game, I really doubt we'll get anything more on their design philosophy compared to what they already said or written here. There are a crapton of gameplay loops we haven't seen yet: comnet, mapping, prosp
  5. The hype is not blind, if you followed even a bit of KSP development over the last decade. They're spot on on a lot of their design decisions and for a sequel of a niche, complex game made by an external studio from a big publisher that is a rare thing. Gameplay right now would mean nothing except that the whole team wasted a month or two of organized work to make a single vertical slice of the game good enough for the video (like it happened with the 40 minutes of gameplay of cyberpunk). If anything half a ton of reveals later the podcast interview remains one of the best sourc
  6. "this close" is realistically a year from now, and the original plan was for a reveal (just the trailer, no gameplay) 6 months before launch, I see no problems there. We got used with the hype machine in the last few years but non seeing gameplay since the last few months before release used to be a pretty normal thing, and it seems to be coming back as an idea given that in the last few conventions "no gameplay shown" was the main concern of most.
  7. Should people be paid for their work? I you think not give me your number that I need a gardener for the summer (for free obviously).
  8. This, I'm even against going fully procedural, but there's no reason to have every single tank length be its own separate part. Procedural length with a slider that snaps with increments that are the smallest possible tank and goes up to the longest possible one. Then it shoul have a selector for the content of the thank with the model changing accordingly (we have seen containers and we know there will be more than one resource to manage, so I'd say that this is a given). That way you have 1 tank part for each possible diameter decluttering a lot the whole category.
  9. I think any official multiplayer has to be able to handle both. Whether its 10,000 years or a day doesn't really matter, you're going to have combinations of players in the future, in the past, and sharing physics bubbles at 1x. Im sure you will have people synched to each other from time to time, but if we don't want to force players to wait while other players do something most of the time players will be in their own slice of time interacting with their own creations and the creations of others. Exactly, not multiple save files, but multiple non-active vessels sharing
  10. Think about it, you have to be able to see future crafts, bases and stations, otherwise you wouldn't be able to catch up and interact with them. At that point is a matter of why you landed in the same spot. You see it, at least on the map view, you know you can't interact with it if you don't sync before deorbiting, and you can deter someone driving or flying there with visual warnings. The only remaining reason to do it anyway is if you're intentionally trying to break the system but the only way to have an unbreakable system is to not have that system at all. And y
  11. That example is the same exact thing of the station docking one, if someone, 100000 years in the future, finds a spot just as pristine and untouched as he left it 1000000 years back it means that nobody else has touched it during those years and since you can't change the past, if you're not up in sync with that player you can't modify his building spot. You can sum up everything said up until now with "you can't change the past of any player". We're talking about a game that will work best with 5-10 people per server at most and it's going to have several star systems worth o
  12. 1) I suspect that D won't last long, if not in that group of friends at least in that server. 2) it's not a paradox, you're just watching it from the wrong frame, IRL there's only one map and every player is playing together, the first that claim a spot has it. 3) I don't think lack of space will be a problem in Kerbal Space Program 2. If I dock to a station 100 hundred years in your game future and I find it exactly how I left it 100 years back it automatically means that nobody visited it in the last century, so you, playing 100 years back, can't interact with it bef
  13. You don't have to have multiple save states of anything, just a single line with the timestamp of the last event happening to a craft to have the date the player has to warp after. Probably the system works better if you get your permission and sync up to the station/base before deorbiting/rendezvousing. In the grand scheme of explaining a player how to do a rendez-vous or a pinpoint landing telling him to sync up before doing it it's not that much additional information to remember. If the other player is actually interacting at the same IRL timeframe as you
  14. Which paradoxes exactly? If A and B are going to Minmus on year 1 day 200, and C leaves his station in LKO to go to Jool on year 1 day 350, A and B must warp at least past that if they want to interact with that station. And then timewarp all the way up to whatever date C is after the Jool transfer if they want to interact in real time on something else. There are no possible paradoxes if you don't allow anyone to modify things in the past. If nobody can warp backward or use any infrastructure before the last edit there are no paradoxes and no wait time you can't timewarp away, unles
  15. In my scenario C is the competitive player, and with synced gameplay he has to wait for the whole play session without doing nothing. It's not even that subtle that A and B could be NASA and ESA while C is China, more competitive than that there's only war and I don't want normal gameplay to be nerfed to low for a gameplay stile that's not supported by Devs and has traditionally never been since KSP original idea. And, anyway, the game being able do manage unsynced gameplay doesn't do anything to people that want to play in sync just like the existence of time warp doesn't mean you c
  • Create New...