Search the Community

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.

Obviously members of the development team have said before they don't enjoy life support, and that's perfectly understandable, a lot of people don't enjoy the prospect of needing to deal with such extra constraints in a game that's already very heavy on resource management, but there's also a large potion of the community (Myself included) who enjoy the additional challenge offered by imposing life support requirements quite a lot, simultaneously of course forcing life support requirements on the side of the community that doesn't enjoy it would be tremendously bad in a large multitude of ways (As the development team has highlighted before). My suggestion is to take a sort of "best of both worlds" approach; adding simple single resource non-fatal life support mechanic and making it only enable with Hard mode, with the option to make it fatal not being enabled until Rocket Scientist difficulty. It being behind Hard mode means that newer players just starting the game won't immediately default to having life support requirements enabled, which prevents it from interfering with the game's initial learning curve while also giving users who wish for the extra challenge the option to enable it, furthermore making it non-fatal allows for it to factor into gameplay without being a significant source of frustration for players, at least until they feel ready to subject themselves to that experience with the Rocket Scientist difficulty. You may be asking; "But Mr. DibzNr, if the life support is non-fatal then what's the point of it?" That'd be an interesting problem, the original Snacks mod for KSP1 simply made Kerbals fall unconscious and thus lose vessel control when they ran out of food, I don't think the player's first experience managing life support resources should be so punishing through; instead my idea is that you could impose a number of smaller penalties like, for instance, tying it into the G-Force mechanics such that Kerbal's G-Force tolerances get scaled back the hungrier they are, you could also take a Minecraft approach and make it so that they can't sprint on EVA if they're out of food, incentivising the player to keep their Kerbals fed without imposing too tremendous of a penalty for failing to do so. Simplifying it all down to a singular resource (Instead of many interconnected resources) also helps to keep things simple overall, and also lets you implement a singular bold "Are my Kerbals suffering" bar that could go right alongside the other "Are my Kerbals suffering" bar, which aids in UI readability, and could also integrate well into colony mechanics. Much like most KSP1 life support mods, the rate at which Kerbals consume food could also be determined by a slider in the difficulty, with it being laxed on Hard difficulty to not make things too overwhelming overall, and then stepped up for the Rocket Scientist difficulty.

If you ever tried to make some particular planes you have probably noticed that there is always the "shape" problem, in this new version we saw modular wings come in and so I thought about a very cool idea: an in-game part editor. I thought about a very particular editor design. ---------------------------------------------------- PART EDITOR 1- upper bar should contain the following buttons: in the left [back to KSC, section editor], in the centre [undo, redo, round corner, add attachment point, display], in the right [save, load] 2- middle part should contain the part itself with all tbe features to change (you can change the displayed things with the input/output gestion). 3- in the bottom part there should be things like symmetry and properties Eventually to add a section to a part you just have to select a side or a section of the part and then press "edit section" or "extrude" ‐--------------------------------------------------------- SECTION EDITOR The section editor makes it so that you can use already existing sections or create new ones to modify your part (for example you can create a section with two Mk1 attaches (for engines) under and a Mk2 tail over (for tail control) to make a fighter two-propeller fighter jet. Sadly I didn't have time to make an image of how I think the section editor should work, but it should be some kind of simple 2D cad with lines that can be divided in parts (starting from a rectangle or a circle). Eventually I think there could also be some "procedural options" to make a part totally procedural ------------------------------------------------------------ CONCLUSIONS I don't know if this post will ever be seen by KSP developers, but if they do, pls consider that I though of this idea, but this is a not-refined concept, I only made a possible version of how I think it could work, feel free to tell me whatever you want about this concept. Thanks for reading

I'm trying to get informations about KSP 2, and I think that there are a few things that should be changed. For example I think that, since you KSP developers are adding colors and themes, the GUI should follow the vessel's theme, becoming custom and different for everyone, another thing about color is that the R.A.P.I.E.R.S engine is colored by both sides, but the Mk2 double engine mount is colored only in the upper side, and it makes everything lose a bit of his environment, so I think that some sort of auto-color changer should solve it, making a transition or something like it, wich makes it a bit more dynamic. Another interesting colour addition can be an advanced color option, wich enables the possibility to choose every color singularly, for exaple, you could color the bottom of a spaceplane black and the upper side white and blue, for an old-style aircraft. Talking about technical additions, I think that there are a bunch of useful additions and changes: for example you could make it that, when you save something, it adds a "version" of it, the one you just made, so that, if you regret your choise, you can get back to the better version. A last addition I think that could be very realistic and make everything better is to male it so you can control your probe from a spaceplane or a base, and it could be even better if there were different command levels, like: -Mk1 command pod or cockpit-> no drone control -Mk1 probe controller-> only action groups -Mk2 cockpit or size 2 command pod-> thrust and action groups -Mk2 or size 2 probe controller-> thrust, action groups and single part control -Mk3 cockpit or size 3 command pod-> thrust, action groups, single part control and SAS -Mk3 or size 3 probe controller-> thrust, action groups, single part control and SAS -Land base drone controller-> full control They could connect to the standard probes and function with extra crew, that controls rhe probe another if there is no connection between Kerbin and the vessel. I also think an important addition for spaceplane or airplane builders would be the possibility to regulate the landing gears from the VAB or even in-flight, so that it isn't necessary to make some strange things anymore. Eventually I think that it would be very interesting to make the new water launch site finally useful with some water parts for boats and submarines and physic corrections like control surfaces not affecting the vessel while in water and intakes functioning underwater.

Hey, SQUAD! I'd like to suggest a few features and alot of things. I would like to see a button to add custom planets. I'd also like to add more parts (see below for list). I'm gonna leave you guys for the designs (IM BAD AT MODELING). Thanks! I really hope you add these. Engines: Kerbality Robotics Inc. - LV - 9870 Engine "Puffman" - LV - 9871 Engine "Locklight" - RS 10 Command Capsule Az Kerbospace Engineering - JTV - 78 - 9 Jet Engine "Ocelot" - JTV - 27 - 0 Jet Engine "Omen" - Omega 20 Spaceplane Cockpit Ovelap Corp - Joolicard 4 Antenna - Joolicard 4 Antenna - X - K-Factor 9 Command Pod Lowne Aerospace Engineering (Ships) (Credits to Matt Lowne and Lowne Aerospace, a KSP Player and KSP aerospace company) - Argus (Comes in Argus, Argus 2) - Odyssey - Phantom (Comes in Duna Phantom, Minmus Phantom, Mun Phantom, Laythe Phantom, and Mun Phantom II) - Dune (Comes in Dune 1, Dune 2, and Dune 3) - Archangel (Comes in Archangel, Archangel 2) - Artemis - Acacius 2 - Engadine

Hello, devs. Do you have a plan to add a different types of weather on a planets with atmosphere (like rains or sandstorm)? And will kerbals need a protection of solar and space radiation for interplanetary flight, and can they get older or even...dead by radiation, dehydration, from old age etc? Will you add a food plants and toilets? Do you going to add an inclination of planet's axis? And another question, you said that you do not add concept of randomly broked parts in a flight, but what else can do the game more challenging? I think that it is important part of any mission, when you need to develop a maximum reliable system that can live many years of flight, parts that repaired by engineer can have a differnt more messy structure and it's very interesting looks and also realistic ( remember how many problems people have with a space stations in a real life because space station it is not a 2-hours flight to the Moon, it is a system that stay in orbit for years). Just think about it... P.S. Sorry if you see many mistakes, I'm from Ukraine =)

Hello there, I was wondering if it would be possible to implement cubemap support for planets into an update at some point. I really would love to see this, since the DDS format (a texture format used by most if not all unity games) has a max resolution of just 16k. This works fine if your planets are kerbin sized, but when you have bigger planets it can look somewhat stretched. With cubemaps in theory you could have textures up to 64k in resolution in addition to having no stretching at the poles. this would allow for much greater quality and clarity in the textures of larger planets. Thanks so much for your time. Here's an example of what I mean. For anyone who may not know, cubemaps allow for this kind of clarity. but currently this is done by a mod called RVE64K for RSS using a workaround, so it doesn't load properly when not in orbit or in the map view.

What about parts made specifically to do oceanic explorations for places like laythe, eve and kerbin allowing for even more fun and discoveries and for example it would answer the question of what stabilizes the atmosphere for laythe, allow us to find (more) little easter eggs, just imagine it you could have parts that allow submersion, little propellers designed for underwater propulsion, parts designed to put up with the express purpose of surviving the immense pressures, going from little adorable probe submarines to massive underwater research stations capable of holding dozens of kerbols. I would do it myself but I can't as i don't 1 have the skill and 2 wan't it to be something that only people who mod can experience. Now i understand that this would be a massive task and a huge annoyance with everything you all would have going on (what with making KSP 2) but a bonus could be a trial allowing you to judge public/user response and seeing if its worth putting into KSP 2.

Aside from bug fixes, there's really only one thing I'd like to see changed in the stock game (if only because I can't afford a computer with enough horsepower to run major mods, and including them into the game would make it unplayable on my computers). I'd like to see a more realistically ordered tech tree progression (wings and jets before rocket parts, RCS before reaction wheels, etc.) (yes, I know, there are mutliple mods for that), with the ability to research single parts. That is to say, if I need a retractable landing gear, but don't have the 90 science on tap to research that entire node, for, say, 20 or 30 science, I could unlock just the retractable gear. That is all.