Jump to content

VlonaldKerman

Members
  • Posts

    275
  • Joined

  • Last visited

Posts posted by VlonaldKerman

  1. I think there should be “oxygen” and “supplies,” and the fail state is fatal. MKS has it configurable so that kerbals either turn into colonists who can be rehabilitated or die depending on the user preference and it works well.

  2. This thread is a good idea! My answers are in no particular order:

    1) Life support- doesn’t have to be complicated, can be tied to a single or maybe 2 resources- the goal is to make time a valuable resource. Perhaps it can be configurable or disabled. I think it should be lethal at a certain point, but with a lot of alerts and stuff beforehand.

    2) The new terrain system (I forget what it’s called).

    3) Asynchronous rover driving a la Bon Voyage mod… I’m not sure how this is best implemented, because Bon Voyage is a little overpowered. Perhaps the rover can only drive a certain distance with the feature, and the player has to drive the first kilometer of the route, to prove that the rover can actually drive and handle well? Less sure about this one, but it could be a very cool feature, and would really create interesting design/strategy decisions along with life support.

    4) Reusable booster recovery a la FMRS mod.

    5) Vessel construction times… synergizes well with life support. No more instant rescue missions! There are some game-design issues to be solved (should there be a craft hangar? What about repairs? How to make non-tedious and how to modify difficulty to be more forgiving?) but I would PERSONALLY like it and this is my PERSONAL list…

    6) Weather! Even if only cosmetic. Blackrack’s Duna sandstorms were very cool, even if they couldn’t actually impale Matt Damon.

    7) Considering clipped parts when calculating tank volume… seems like a massive technical challenge, but maybe not?

    8) Wear-and-tear. Like weather, this could be a purely visual effect, or have gameplay ramifications. Wouldn’t it be cool if your rover that’s been sitting on Duna for 20 years had dust on it? Could go all the way up to part failure.

    9) SCANSAT features like surface mapping, etc. Good for scouting out landing sites with intentionality.

    10) Testing mode. Especially if there are things like life support and construction time that make failure states more common and less recoverable, being able to test crafts and missions is important, and it breaks immersion to have to load up a different sandbox save with your crafts in it. Though, you can do that, so this is really more QOL than anything.

     

    I think that the unifying theme here is that the challenge is kicked up just a notch from KSP 1. I know that onboarding is a big priority, but new players won’t have to worry about LS for example when they are landing in the Mun. They might create a station in LKO to test out LS mechanics, before putting a base on Minmus, which is easier to land on but far enough away that it’s a good test bed for LS before their first Duna mission.

    In other words, the steepness of the difficulty curve won’t change, it will just have a higher ceiling, even before the player goes interstellar.

    I would also argue that persistent colonies are irreconcilable with the “one mission at a time” play style, so future dev decisions should not be made with the intention of catering to that desire. Therefore it seems very logical to introduce features that make time a valuable resource, and require the managing of several concurrent missions.

    But yeah, those are my ten! I also happen to be the arbiter of truth, beauty, and wisdom, so they are also the definitive ten! Boom!

     

    moar boosters

  3. 1 minute ago, MechBFP said:

    I’ve worked on a project before where the original estimate to completion was 6 months and it finally got finished just recently after 5 years since that original estimate was made.

    Asking out of genuine curiosity/ information gathering: at what point did you become aware that the project was taking way too long? Because KSP 2 had been in development, as I understand it, for at least a couple of years in 2019. So they were, as far as they new (supposedly) 67% of the way through development at that time.

    3 minutes ago, MechBFP said:

    There were a lot of reasons for that painfully long wait, and none of those reasons were included in the original estimate. I guarantee you that 4 year wait here has very little to do with actual hands on work but a myriad of other things that weren’t planned for. 

    Yes, I agree. I think, as others have stated, the vision for and direction of the game changed in 2019/20 at the same time as a lot of corporate shakeups. At that point, they should have been straightforward and honest with the community, rather than, “Nothings changed, new team, same game! Still developing!”

  4. On 10/28/2023 at 1:32 PM, PDCWolf said:

    It'll never be compatible to me to hear "I have 30 years making games" and "we underestimated by a huge margin how long it'd take those tasks to be completed. In this case it was 4 years".

    At least this interview puts the "wahh rushed into EA by evil t2" cries to rest.

    The claim that they just underestimated the time it would take to make the game is not just implausible, it’s impossible. Remember, when KSP 2 was announced for a full release in 2020, IT WAS 2019!!! “In this case it was 4 years” is very different if at that point you estimated it would take 10, but ended up taking 14, vs estimating it would take ONE and it ending up taking FOUR UP UNTIL NOW, WITH YEARS OF DEVELOPMENT LEFT. Not even the SLS took 4 years to do <1 year of estimated dev time.

    I also don’t buy the notion that they released the game on their own volition, in order to gather user feedback. A game intentionally releasing in a half baked state (even for early access) without prompting from its publisher and without oversight or objection from its publisher would be virtually unprecedented, I think.

    However, I’m not too pressed about him lying (I think) in the interview. What’s he supposed to say? As long as the stuff he said about the future is at least 80% true, it’s good news. And either way, I can’t do anything about it, so I’ll just wait and see.

  5. 2 hours ago, Kerbart said:

    My biggest fear is the impression that IG that they don’t think the bugs are a big deal. According to their messaging the game was great fun to play from day 1. They’re not pouring a lot of resources into bug fixing (there’s no way to explain the snail pace otherwise). The community backlash on the amount of bugs in the game seemed to surprise them.

    So, now that game status had advanced from “completely unplayable” to “playable but frustrating” my fear is that bug fixing will get even less priority. I can already hear the creative director crow “We fixed orbital decay and rocket wobble. The game is now bug free!” and the dozens of sheer annoyances will be there for years to come, just part of the KSP2 lore.

    Will the colliders on the KSC ever be fixed, for instance? It seems that the 3D artists have already moved on to other projects like grid fins.


    I think the critical error was releasing the game before it was ready for even an early access release.

    For one, they did not need the community to find bugs, so I think they actually gained relatively little.

    I also suspect that the general impression that bugfixes are moving slowly is due to the fact that there are SO MANY BUGS that when 80 bugs get fixed, it doesn’t seem like it to the player. This is a function of the game still being so early in development- earlier than a lot of other EA titles. The bugs are also back-end and fundamental. I suspect that their pace of fixing bugs is actually quite good, there’s just a lot of bug fixing to do and we normally don’t pay $50 for a game that’s at this stage, so it seems unusual when it really isn’t.

     

    Ill argue FOR the release of For Science… I doubt, counter to the various hints at internal builds we’ve gotten, that many of the major game systems have actually been hooked up together yet. When they do get hooked up, there is bound to be a whole new host of bugs to work out and there may be things that are broken now that will only become obvious when science etc is integrated. So they should try to integrate as many things as possible as soon as they are built, and then start the laborious task of sorting through the tangled web of bugs. But I’m not a game dev, so take this with a mound of salt.

  6. 10 minutes ago, MechBFP said:

    That’s nots how crowd funding works.

    Needing money, and wanting money, are two very different things. 

    Not if the continuation of your project is contingent on your corporate overlords being satisfied with sales.

    This is the big budget version of an indie dev trying to get a loan. “Look, the EA is popular, fund me!” Except T2 corporate is the lender.

    I suppose it’s not literally crowdfunding, but it’s close.

  7. 8 hours ago, Periple said:

    EA isn’t crowdfunding nor is it a finished game. It’s what it says on the label: early access to a game that’s in development, no more, no less.

    Why did KSP 2 release when it did if it wasn’t about getting sales revenue at that time? Several long forum threads have been about this- but I think it’s pretty clear that the game was pushed out by corporate, possibly because it was taking too long and they wanted to be reassured that there was actually a market.

    If it was released because they wanted $$$, then it’s probably crowdfunding!

  8. 20 hours ago, PDCWolf said:

    Thankfully we have sources that point to this not being the case. Development started 2017.  Why people keep hiding under the same scapegoats time and time again when they've been told by T2, PD and IG that the game started being developed in 2017, that COVID wasn't a problem and that EA was gonna be updated in weeks not months is beyond me.

    The fact that development started in 2017 does not mean that large parts of the game were not scrapped at one point. I don’t think it’s a scapegoat- I think it constitutes mismanagement and also dishonesty when they didn’t come out and talk about it and continued to promise that the full game was temporally close.

    20 hours ago, PDCWolf said:

    It doesn't even fit as coping, it's either maliciously spreading misinformation, or outright refusing to accept reality.

    Personally, I’m maliciously spreading misinformation.

  9. 19 minutes ago, shelshok said:

    I do agree that they don't owe anyone a number, but for the cost of EA, they do owe something to reassure those who bought it that they are going to get something worth $50, because what they did get so far ain't it.

    For my money, I would rather get snippets of gameplay from internal builds that are more feature-complete than details on the inner workings of the dev team.

  10. 5 hours ago, Lyneira said:

    Could the bottleneck have been prevented? Perhaps with different processes or a larger engineering staff in the years before launch. The confidence about "slaying the kraken" from communications prior to launch compared to what we experienced after launch suggests the engineering task turned out to be more difficult than expected.

    At the risk of beating a dead horse, there is a popular theory that development got restarted at some point in 2019-2020, likely because of unforeseen engineering issues or a different vision (different engineering vision) for the game. This would likely hit engineering/backend much harder than asset creation bc a lot of the models, SFX, etc would transfer right over. Given that they were shooting for a full release with no early access, all the features were developed simultaneously, giving no special priority to the one’s that would appear in an ideal “early access” build.

    This would explain why a) The cosmetic aspects (aside from technical ones like terrain detail) of the game (parts, SFX, etc) are so advanced relative to the engineering and feature aspects of the game, and b) Why so many “basic” features like reentry heat are missing from the EA build, while there are supposedly distant roadmap features in a relatively advanced state in internal builds.

    All we can hope for is that the apparent difficulty of KSP 2’s engineering challenges is surmountable to the point where they can deliver the ambitious, performant game that was promised. However, the reasons for skepticism are obvious.

    In other words, yes, I agree with @Lyneira.

  11. I think that these points speak more to the common-sense frustration that people have with the game. Is KSP 2 in clear violation of these to the point where it should be removed from steam? No. But does using these points as a framework for judging what an early access should be highlight the ways in which it is reasonable to expect a better game at launch? Yes.

  12. 39 minutes ago, Mikki said:

    I don`t want to revive this thread about wobblyness, but tuning down engine gimbal at launch solves also lots of troubles, just  as reducing/disabeling excess reaction wheels on subsequent stages, lets face the means we have to launch basically everything with a little tweaking...

    Ah, yes, good times. Just reminded me of that time early on in every KSP 1 science/career mode that I played where everything I launched I launched with a twin boar engine.

    I would say that it’s okay for things to need tweaking at launch if there are use cases for the extra gimbal. For example, would you ever find yourself increasing gimbal authority shortly after launch, or for short periods of time?

    The mere fact that you can make design decisions to reduce wobble doesn’t mean wobble is not a problem. Not saying that’s what you said, but I feel the need to reiterate that, while a lot of people seem to be saying that wobble imposes design constraints and that’s not necessarily bad, even though they aren’t always the right design constraints.

  13. On 9/25/2023 at 7:50 AM, The Aziz said:

    t's possible that they went into implementing as much as possible (colonies, progression, interstellar mechanics, planets, resource processing etc), but as a result they didn't have enough time left for basics

    Preface: I’m not a game dev…

    BUT I feel like things like the joint physics system are so fundamental that you would be worried about those first? Like, why would I try and figure out how the game stores information about active vessels and their orbits in order to have persistent resource consumption and physics applied if I don’t know how part joints work? Maybe that example is bot actually a problem but in general I’d have to imagine that an ideal dev arch follows the (fundamental systems) —> gameplay implementation/system integration —> cosmetics and optimization timeline, perhaps with cosmetic aspects like part designs and music being developed at the same time as the technical stuff.

    This is what I’ve made several posts (and threads) about already: the problem isn’t that there is a bug that causes rocket wobble, the problem is that rocket wobble will probably be addressed by implementing exactly the kind of back-end fundamental system upgrade that the entire game is predicated on, and that should have been done AT THE BEGINNING! These backend systems are what will make or break the game- modders can add in all the fancy parts they want, but it will be as buggy as modded KSP 1 unless the backend of the game is totally fresh.

  14. 5 minutes ago, The Aziz said:

    Oooor design a craft that won't tip over. Isn't the whole game about engineering your way around problems?

    In KSP the ground is inelastic and unrealistically frictionless so it’s too easy for crafts to bounce upon landing and slide once they’re landed. Not the same as tipping but other reasons to have some kind of anchor.

    Myself, I like the act of scouting out landing sites ahead of time so I usually land on a nice and flat surface.

  15. 3 hours ago, chefsbrian said:

    Part of the problem is that the player doesn't really have any engineering tools to control those joints, or the ability to make any of the engineering tradeoffs that could be used IRL. We've got lego bricks, and the bricks go together as the developers designed, and we have no ability to sneak in with a bit of superglue to fuse that lego together. We just got a system where we get what we get, but what we get isn't presented or explained to us, we just get to observe improvised slinkies and question what we could have done to prevent this.

    RO allows players to choose the type of tank (structural, non-structural, reinforced in various ways) they use. Beyond that, and with respect to joint connections, would there ever be a benefit to making the joints as weak as they are now?

    In other words: the game also just decides that your cabin is pressurized. This is not a reason for the cabin to randomly depressurize (rocket wobble), but for it to ALWAYS remain pressurized because the player would never choose to have it the other way (stiff rockets). There is no need for there to be a joint stiffness option if players would always choose rigid.

    3 hours ago, Kerbart said:

    Wobble is the way the game gives feedback that you're flying an unsound design. People freak out when their rocket, shaped like a hot air balloon, flips over when they yank it to a 45° angle at 10km. Imagine the complaints of people when their rocket explodes for no reason.

    In the suggestion I’m referencing, the forum member gave examples of other ways of giving visual feedback ex. Sparks, visual vibration, an alert system, etc. Real rockets also have internal sensors which give data- I see no reason why this couldn’t be in KSP 2.

    In the abstract: does it really seem likely that having rockets wobble is the best way of communicating to players that their design is bad? There has to be a better solution.

  16. 6 minutes ago, shdwlrd said:

    So much this... Don't get me wrong, auto struts was useful in certain situations for experienced players. (Ex. Large to huge space planes.) But it doesn't need to be a crutch for bad design choices.

    I’m not an expert, so please correct me if I’m wrong, but I’m pretty sure that in real life, rockets very rarely fail due to structural wobble. This is either because it’s such a solved problem that it never goes wrong, but in principle it might, or because the way rockets are made minimizes wobble naturally and easily.

    In the dev chat, they alluded several times to “realism”, and to be sure, in reality things bend under torque. But I’m reality there is also n-body physics! Would it be accurate to say that, in many or most cases, a jointless or nearly jointless approximation would yield sufficiently realistic results, in the same way that Newtonian gravity simulation does? I think the answer may be yes.

    I like the solution one forum member came up with wherein torque was calculated for certain joints within a vessel, but rather than bend, when a joint experienced torque beyond a certain threshold, the joint would fail. Again, this would mean no bending, so less realistic, but as they said in the chat, “[we] could make a perfectly realistic physics simulation that runs at one frame per five seconds” or something like that. If we’re already resigned to approximating, as far as I’m concerned, the aforementioned approximation is fair game.

    Again, I say this with little actual knowledge. But if I’m wrong, someone is yet to explain why, I think.

×
×
  • Create New...