starcaptain

1) would fit into a preface for an executive summary for anyone who was wondering what they might be getting themselves into by looking at the Kerbal IP. 2) I don't know anything about engines so I'd leave the point empty beyond what i mentioned: think about it carefully. I'll see about merging these thoughts with the OP post later.

I'm going to just make the note say "select game engine, strongly reconsider Unity". On 1) I'm not going to defend or explain why this was a problem in KSP2, the most we can do is outlay means by which it can be avoided for the future. On 2) see the reply above. On 3) I'll pin that as "relatively easy to customize GUI in Vehicle Editor, Part-Action Window and In-Flight interface." Maneuver Planning is a whole ball of wax probably deserving its own note of some kind. On 4) I think your defense of KSP2 and expectations on this end is probably the best that KSP2 can hope for, for the foreseeable future. The best case scenario I can imagine is that T2 gives Intercept the chop, then hands off rolling out more content and bugfixes as you've just mentioned for the next half decade or something. On 5) I think if there was a KSP3, "mod support" would mean part and ground-interaction infrastructure in the engine so that modders could do a lot of the work for these kinds of things even if it never gets rolled out as an official release. That, I think, is a better plan than making it a 'necessary to ship' feature of the core game. The approach for colonies and resource networks should be somethi, ng that can be approached (at least to some degree) either officially or by modders; not pinning hopes all in one direction.

We can all still imagine what a great successor to Kerbal Space Program would look like. Take-Two has now spent ~7 years and ~40 million dollars learning how not to make a sequel to a green space frog explody simulator. I still fully believe in not only Nate Simpson's ambitions; unification with all the hopes of the average KSP-enjoyer; and a publisher can get the Minecraft-competitor franchise of cute lil' minions that teach kids STEM and sell spinoff products. Everyone could be happy. It's still possible. What we need is not exactly a lessons-learned document. More like, a comprehensive list of the features that are wanted in sequel, cross-examined by which ones are most important gameplay-wise and engine-mechanics-wise. I agree with, for example, in ShadowZone's assessment that KSP2 had too much visual polish and not enough work under the hood, or Scott Manley's expectation that the engine would make it easy to customize planets (and this feature was regrettably not approached.) Since I and no-one I know has 50 million dollars lying around, the best thing I think we can do is make such a document for a future developer, publisher, or whoever. The deliverable of such a discussion would be an easy-to-read paper, a game design document, that compiles: Things most enjoyed in KSP games as a whole, which are critical to the core gameplay loop Features most desired to be changed Features semi-solved by mods (that is, things that should should be knitted into the engine so its ambivalent if modders or devs make the end effect) Features already solved in the KSP1 engine (or knowhow from KSP1 that should be grafted in the future) Features requiring ground-up design We can hope and envision that a new developer would do a better job of KSP3; or we could actually pound the pavement and just do their homework for them. At least for me, writing something like that would give a sense of catharsis, after a decade of anticipation being let down by such trivial and pedantic circumstances as those which did-in KSP2. Kerbal Space Program core gameplay loop Build-Test-Fly Easy-to-use vehicle editors for spacecraft, aircraft, groundcraft Analysis tools, such as center of lift Gravity simulation(?) UI should be very well built and understandable. Take notes from what KSP1 and KSP2 did well and poorly. Communications & Deep space network Science collection and technology unlocking Crew resource management Extravehicular Activity in orbit and on planet surfaces Planting flags and grabbing samples Navigation nodes GUI, ease and stability and functionality of maneuvering for at least 5 nodes, maybe n-many One or maybe two major mechanic additions, but leave the path open to either official development or modders; such as Colonies Resource Networks and ISRU Variety of planets that each have a unique complication related to astrodynamics (gravity, atmospheric composition, size, etc) which makes navigation to each into something of a puzzle to be solved. Engaging in this design practice should still encourage a variety of approaches, not bottleneck players from the ability access a given planet unless they have X-gimmick part in their vehicle. Players should be rewarded by each place they visit with unique surface details and things to see or do. KSP2 started on the right track with this; though it doesn't always need to be alien precursors or bones. Desired changes--meaning the backend should make Mods possible, but not required for the developers to build themselves: Planetary editability Including real-world scale interplanetary distances and planetary sizes Including axial tilt Parts library ease of editing Aerodynamics systems Space center and building editability Ploppable buildings and launchpads relatively easy to customize GUI in Vehicle Editor, Part-Action Window and In-Flight interface. Weather Don't bother with precursor lore, ARGs or a complex backstory for the in-game universe. Strongly consider gameplay impact and difficulty for crew perishables, life support, and maximum mission duration per weight for crewed flights. Gameplay features that should be lifted from KSP1 (don't reinvent the wheel, improve the existing) Orbital transfer calculations Planetary and personal scale, position and speed systems Interactions with the ground, surface friction and wheels. Aerodynamics systems, including facing side occlusion Buoyancy systems Heat and radiation systems Robotics modules Gameplay features that need rebuild from the ground-up (they need integration and considerations from day-1) Strongly reconsider game engine, not necessarily Unity [several posters suggested] Multi-language support and localization Handicap UI design and controls customization Emphasis on variety of control input methods and device support Multiplayer, including maximum number of players in a world Interstellar travel and communication Timewarp with continuous acceleration Brachistochrone trajectories capable in maneuver nodes Support for including multiple star systems Relativistic effects not required(?) Optimization of vehicle editing and flight performance so that big vessels do not cause lag Things hat should be excluded or be avoided. They are not value-added development. Do not re-release KSP with a graphical update. Ignoring veteran players or community input. Do not add too much handholding. Part of the draw of KSP1 is its steeper learning curve, which encourages exploring and diversity of method, rather than railroading all players onto the same experience and leading them to think the game is shallower than it is. Chill out on the tech trees. Many players never even use them and go down the Sandbox route from the start. Buildings do not need physics simulation other than "destructed by high impact force". Can easily be assumed to be rigid and sufficiently strong for the world where they are.

Parts fail if they get too hot. Can they fail if they get too cold?

I too am in support of the "as long as it takes" timeline.

Still picturing that silly monorail mod idea I posited: can requests be made so that are sent or arrive in block-like increments? I know that "rate-based" means basically Flowrate and assuming the resource (say, a fluid, or even electricity or solar energy) is arriving by some kind of direct pipeline (fuel pipe, wire, line-of-sight to a star, etc.) Would it be a manner of programming to build a flowrate so that the resource "is delivered" as, say, a tank of fuel that's 5000L all at once (because the tanker arrived at the depot) instead of 50L/min ? Or is the core of the system made so that the only way fuel can be transferred is between containers with the flowrate? Meaning if I want to run a fuel delivery railroad, I still gotta discreetly transfer fuel from the depot tank to each railroad car.

Will clouds get shoved out of the way when our flaming piles of garbage that used to be rockets careen through the clouds? Praudl-glauert singularities? Double-rainbows?

I think the light source method is the most likely method that they'll do, but I suspect that it won't be something updated every frame. Unlike thermal radiation, I don't think it's going to have impacts that will hurt your spaceship as fast as reentry heating could. But I can imagine the following: You're physical-timewarping your vessel from star A to star B, and the radiation meter starts building up on some parts, over the course of weeks or months instead of seconds. It looks exactly the same as the thermal indicator, but a different color. If it "overheats", the part fails. As for crew exposure, I imagine it'd be a place where crew health bars makes sense.

You do realise that Ovin will win the vast majority of the time, right? It's like picking a fight with a wall.

understandable, have a good day sir

Inevitable

Friend of mine is sus that the blendshapes don't conform to real world maths. He sent these citations from Rocket Propulsion Elements by George P. Sutton. As usual, I expect my (or my friend's) pedantry can be solved by mods but nonetheless I'm delighted to see the game's progress nevertheless.

The video I saw on twitter looks like the thrust plume also works as a local light source, at least against the engine. However, it seemed to my eye that the lighting was very harsh and overblown. It was also emitting light through the thrusterbell, which means self-occluding shadows were not enabled, which is understandable from a debugging point. I am curious though: will things like the shock diamonds have HDRI lighting? Or is that beyond the scope of KSP2v1.0/a question for the modders? (Also, practicality doth protest to using rocket engines as area lamps around your colony.)

Here's hoping mods can also change the UI. Oh, jolly good. Can't wait to fly my ship using controllers that read out in: * Digital * Roller dials * Analogue needle mach gauge * 7-seg liquid crystal displays * Split flaps * Nixie tubes * Conway's Game of Life sims * Japanese synchro-walking * Skyrim handwritten notes * etc

Do you think that Unity could support hot-swapping the host? Picture this: you and x friends keep a server continuously online by always having overlapping sessions at some point.

I am imagining KSP2 will have multiplayer up like, maybe 8, much in the same sort of manner as Terraria, like K^2 said. Colliding vessels while in space is one of those things that's destructive but also takes effort, like making a coordinated demolition in Garry's Mod. So i don't think that's a route of problems. And the editors aren't multi in of themselves, so players can't ruin each other's building task...

We all have high hopes for the multiplayer features of KSP2 but it occurred to me: not everyone likes to play nice. Seeing as we have little to go on for how multiplayer works, it's hard to imagine what kinds of griefing or abuses may appear. But i raise this as a topic of concern, because the online culture of a multiplayer video game is greater than the sum of the many different parts that make it up: *General player attitudes within the game *Groups, cliques and common play styles *Attitudes of the developers towards the online culture *Tools made by the developers for ensuring safe, uncorrupted play These and other things will have great impact on how and when trolling might occur, and how amusing/annoying/destructive/toxic it may be. I want KSP2 to succeed, and the main thing i can do in that dimension is wanting to be a supportive, friendly, and polite player. But I don't know how core these sorts of thoughts are for the developers.

I'm curious: What if two players set up their velocity so that their orbits are very close to one another, but with inclinations nearly exactly 180° apart, so that their relative velocities are basically 2x orbital speed; I imagine the continuous collision check is happening every frame where their trajectories are similar. Wouldn't this have an impact on performance, even if the players were in opposing positions on their orbits where collisions wouldn't happen (yet)?

We're all very happy that Nate Simpson is the creative director for KSP2. Kerbonauts would want nothing less than a genuine fan beating the drum to turn a sequel into a passionate continuation of the original. But I'm curious if there's any infusion of the game with elements or design choices informed by his previous experience. This isn't his first rodeo, he's been a director before. I'm wondering what sort of things in his career are making him confident that this sort of gameplay decision or that sort of UX element are solid choices. Or is answering that kind of thing just implicit from the direction we're seeing in all the teasers? Maybe I'm just not satisfied with seeing his resume on LinkedIn. I'd like to talk about his previous games a bit.

If it's anything like earth was, it'd be a thick nitrogen/CO2 atmosphere in which oxygen-breathing bacteria have yet to evolve.

I thought you meant Chthonian planets.

Pointy mountains. I'm okay with varied terrain or even boring hills and stuff, but I always found it pretty egregious how the terrain system worked that the slope might change radically with harsh sharp angles on mountains, and driving around them was like trying to drive a shopping cart on the side of a building designed by Frank Gehry.

I still wonder if going through asteroid belts is a death zone unless your relative velocity is low.

"Thermal" and i think "Radiation" are both going to be things that appear in the engineering dialogue in the vehicle editor. If you watch closely you can notice them in some of the more recent teaser videos, beside existing highlighters (CoM, CoLift, ect.) I imagine they behave a bit like volumetric light, with different parts having different "transparency"/absorption amounts.

A lot of KSP1 is already in KSP2 so some degree of homage may be redundant. "2 is already supposed to be a modernized reconstruction of the same core experience, and we've already heard confirmed that everything you can do in the original will be present as well. Seeing some callbacks to the game's development history would be nice as long as its fun to seek out.