mattinoz

I think the tedious and boring might come from that being a dull game concept that has been made too cute for it's own good. KSP has an interesting game that would like to expand and that expansion would be aided by some automation at times. MechJeb does too much for the player out of the box to be stock, kOS does to little but still a fun kind of too little. It's a fun balancing act if they choose to do something for stock.

I've always thought it would be a great way to have Kerbal themselves a bigger part of the game. Say, give each Kerbal with a portrait a visual code block that fires off on a condition. Higher stars more blocks to use, different skills training add functions related to those skills. Bigger command pods more portraits more possibilities. Player can use as little of the system as much as they want. You could start simple and have say one Kerbal watch staging and fire them off add another with pilot skills watching when to kick in the gravity turn and changing SAS mode. Add a third watching atmosphere and firing faring and deploying solar panels. Commander Kerbels could even instruct other Kerbal to what they should be doing at a particular time so they become the full program fill that they can share with others Kerbals of the same skill.

Works either way and leaves room for more than 3 Kerbal portraits. Although maybe not the full compliment of a colony ship but maybe a dozen in large ships. Edit to add: Don't see the problem with curved throttle. Would like to see clickable throttle and maybe the over throttle zone become something of use.

Brand new code, all old bugs are gone, all new bugs that the dev's should have a bit a budget assigned to finding (and shipping anyway ;-) I kid, I kid). Similarly broke things in the game should go ie Career mode replace with a driving game play narrative like what the devs have nicknamed Adventure Mode. Nicknamed as it probably isn't the shipping name (sadly) and replaces last minute introduction to KSP 1.0 Career Mode. This is KSP 2.0 and beyond not KSP 1.11 the 2 means they get to toss things that don't work or are holding the games back.

Would be fun if it could snap you back to the moment it went horribly wrong for a replay and tutorial options contextual to that time.

Doesn't it come down to fuel source for the rockets that are super fast? If it takes a month to mine a day of engine run time and your early production is constrained then it'll be still quicker to get there on readily available fuels drifting on a more efficient path.

Wouldn't that make more sense as a starting point. Level 2 then adds the basic runway, level 3 adds a north-south that cuts off part of the grass. best not to upgrade till you have your landings down.

Although by the sound of it Multi-player is about shared activity, shared knowledge but should hopefully be ripe for mods to extend to other styles. To me would have to be game time but why not both (as mods)? Then every time the other player does something in the future you could receive a spy file saying they are getting ready to do .... launching on .... landing by ..... with a high factor of probable success. Or mission control sends you updates to their progress as timelines align.

Isn't this why a game "build for modding" has a few of the base systems being discussed in place? The more you leave things to modders the deeper in to the core game code they need to reach the more breaks with each decent sized release. I mean a game build for modding should have well documented hook to hang the obvious mods on and to rely on so they don't break each time. If not then well in wasn't built for modding it just wasn't build to stop modding (KSP1 is definitely in the later group). I'd be hopeful KSP2 is actually "built for modding" dev diaries sure lead me to think it is, better hooks, better interface with the game state,,.... lots and lots of documentation. So for example - I'd also hope some more basic systems were built in as simple extensible cycles that even the core engine builds on. Ie. Engines (Propellant + Accelerant -> Thrust -> Smoke), Life support (Supplies -> Work + Waste), Kerbals (Skill + Work -> Action), Mining ( Situation + Power -> Mass), Resources (Mass + Power -> Stuff for other cycles), and so on.... Then mods can extend those point without needing to supplant the core mechnic. Also mods can target any point and just deal in that item without risk of tripping over another mod unless it too targets that point at the same time.

Cryo wouldn't be the first fuel the player gets to use would it? The player has a bit of training and is building more sophisticated craft, dealing with more challenges and risking more failure before that get to use it. Also hopefully fingers crossed the system is better all round at dealing with help the player use what they already know. Like sub-assemblies gets a solid upgrade so once I get it right I come back and just re-use and tweak, tweak and reuse again and again. Also starting a game more experienced players can have the option to start higher up the curve. So that leaves 2 options:- A) let them fail and learn ie The Kerbal Way. B) design an abstraction that is simplified (also oddly the Kerbal Way) In B Fuel selection might be by Tanks having a select-able or tweak-able variation that takes care of the issues noted and that becomes part of the expression of the tank. So Cryo would have a built in battery with green light, tanks in zero G might carry monoprop Ulrich motors that auto fire when asked for fuel. These sort of layers give the game liveliness and lead to the player discovering stuff. When they discover it then they can design it in to the craft themselves and risk being in A group but get a system weight saving or more fuel. Using a simple tank variation and unifying the battery and fuel settling under their own command. Knowing they might miss a burn window if they don't allow for it. The UI could be really simple in that tank fullness indicator might change from solid bar to a spots floating in the bar. Again this could just be something to lead the player to discovery not a punishment. That sets the game up for Expansion or Mods to go anywhere up to full nuts realistic with cameras in tanks and engines that never fire again if they don't take care of business before a burn. To me the how point of extra layers is to allow the player to get higher knowledge on a flatter curve.

To me it's not the fuels themselves but the splitting performance between engine and fuel that is the important thing. Adding an extra option for fuel selection frees Engines selection to be just about situation bell shape and such. This breaks down the rocket design learning curve into more logically steps. Then builds on those steps without reversion to be more efficient. Basic rocket control with solids -> staging adds first liquid fuels -> getting suborbital adds bell shape selected -> then fuel selection gets payload value -> turbopumps brings in landing on other bodies -> on wards and upwards. Adding something like the seadragon pressure feed engine with a sea launch and reuseablity by producing own fuel from seawater introduces resource collections on-world before taking it off-world. and so on and so on.... Fun challenges that open up options that can be returned to to suit a particular moment in the players growth to me is the gameplay advantage. Plus it leads to more logic the player has to use to divide parts up in the browser. Instead of just one big group of things that go boom they could be divided into situation or features, filtered by fuels they can use.... So as I unlock engines I understand how to use them because they are next to the other vacuum engines or a sea level engine or in between hey that might be an upperstage sub-orbital engine. By having it all lumped into the engine specs the game currently feels arbitrary at times confusing and a little arcane at others. A logic to overlay and sort that out would be choice. Add the bonus that is game does add these things as targetable extractions of the larger problem as mod interfaces. Mods then only need to tweak one part of the whole without having to first create a replacement to the whole. Would say the same with Life support, the complexity doesn't just add to the challenge but in many ways breaks it up in to smaller steps that could be bypassed with experience but lead the inexperience further in to the game.

Not sure about this I'd say what the Dev have said in many and numerous places supports the idea that KSP is an game that challenges people to problem solve with cool rockets and certainly they are problem based on dV but to me this is the killer line from the dev note in which they say they are minimising colony management note not eliminating it. "We all know that Kerbals just need cool suits, snacks, and something fun to crash." Cool Suits and Snacks to me both say life support with environmental pressures (or lack of) but a simple and clean. Not micromanaged just making sure Kerbals have what they need to self manage. (which then gives a solid base for mods to extend without reinventing the wheel each time). KSP2 can't just be the same solve this dV problem game play it needs more depth, constraint, release and flexibility or in short FUN! Exactly how do they get 10 years of development out of the game (a stated aim) without expanding the scope for challenges?

I think that time just after making history that I set out to make an Apollo inspired craft. In about an hour from that point I'd built it, first launch, stuck the landing and redocked and returned. That just never works for me normally, usually these things take many attempts, many hours of game time. Mission time was much longer, but my finest single hour in game.

I'd add it might be an interesting thing for the games if these skills were owned by the Kerbals who were part of the mission not player or craft so you had to keep them alive and get them to share with other Kerbals by taking them along. Makes Also Kerbals strike me as kind of people who'll try even if they know it won't work so put an orbit trained Kerbal in craft with 5000 dv but a twr of 0.25 and see what happens. More advanced Kerbals might warn you that they don't think it'll work but they'd still try.

Seems to me it needs to be forest of trees with loose tendril connections. So each "craft" stays distinct and can dock or break away without the jolt of merging into a single tree like KSP 1. Especially with Orbit and Base construction of other craft, exotics fuels and docks for fuelling looking like part of the game. A single tree seems a bad state of affairs.

Have to agree the system could happily be more complex than it is currently especially if that opens up design challenges. we are talking what 6 to 10 fuel types up from 4. Adding 3 where there was only one is going to help players ramp up so don’t hit a wall of exotic fuel mechanics at some point in the game. I’d assume these would make resource collection more interesting to boot. Edit to add - if KSP had a mode like this with different colours for fuel types it would add to the fun. https://futurism.com/amazing-vid-rockets-transparent?fbclid=IwAR1s5eaI5WFTTDzKHhRUXoypiMf4wEpQBHD9QK4W6GFoTfylXmVS7Y6s8Vs

Given it's about bragging rights not anything more then ignoring your game is at your peril anyway. I'm sure it could be designed without needing a server, might need an authentication app like one of the common ones but so many people have them anyway. Sounds like a Steam or store feature to give some users Jeb like status more than something you do for standalone personal satisfaction.

Exactly You'd have to encode the save files so the key to decode them is lost to time and back ups are useless.

I’ve personally never considered maxing the tech tree to be the aim of the game even in career mode. It more just a way of slowly introducing parts and making you explore there usefulness.

Sandbox, most powerful engine, minimal fuel tank, command chair, Jeb. Throttle up, space bar. Then start a career mod game.

Maybe lost in Translation.

I read that with hope as well. especially in the context of flying missions to make colonies self sufficient. How can they be self sufficient without something to run out of. This whole dev note fills me with hope for the game.

That would be a a more egregious false marketing than KSP1 calling itself a Tycoon game.

Why just for Museum? Could be part of game physic LOD system. Carefully supported by engineers in a museum hall is not any different than drifting in space without thrust or even constant thrust.

Admittedly we are working off highly edited comments in videos that are trying not to literally give the game away but it sounds like they created a Lua interface in to the engine code very early in development to do prototyping of the games systems. Given that I'd suspect there is lots of already well documented points for mods to interface right in the very core of the game because part of the team are basically in house modders (I suspect many of them very well know around here). Could be complete wrong on many accounts.