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.

This is a list of QoL features / plain features / improvements/ whatever at this point, that I'd personally like to see in KSP 2. Be it today or months from now. There is no particular hierarchy. Feel free to add your own! Adding more to this as I read replies because I'm just one person and have limited thinking prowess! That is to say, I wish to add ideas to this list as I read them because I didn't think about it. Not even going to try and keep this ordered by-effect/change. Will try and keep duplicates out If an idea is from another, I will put their name in parathesis and italicized. "Many" will refer to just that; more than one (including myself) Manuveur Node Window / fine controls, just like we had in KSP 1 More minimized Delta-V readout in VAB / flight. There's a lot of unused black space thats not neccessary sometimes. Another toggle for just Delta-V and not fuel tracker is this wish Option to reduce entering / exiting gravity well "pulse" effect. I love this feature, but its quite huge sometimes for me. Mouse Sensitivity options Mouse direction options (inverse, etc) Seperate VAB / Flight Camera Pan options (sensitivity, inverses, etc) "Warp to Day" / "Warp to Night" "Warp to Encounter" (So as to warp to a few seconds before entering or exiting sphere's of influence) Transfer Window Warp Timers Manuveur Node Editing while Paused (unsure if this is a bug, or a feature, to not be able to do this while paused) Rocket Plumes follow the rockets path opposes to statically locked. More specifically related to effect smoke, to have the sight of your smoke trail as you launch "Do Science" button only flashes when there is truly a new science to do (Unsure if this is bug or not) Make Re-entry effect more flashy (I like the current effect , but it feels almost too static and needs more particles or variation.) Thermal bars less out-of-place feeling (Feels duck-taped on. Which I like, but a more visually in-line one later would be a nice thing) Symmetry automatically goes to correct option when trying to apply new parts to something (example, add struts to a quad-symmetry booster automatically sets symmetry to quad.) (Unsure if this is a bug) Scream bloody murder at the player if they forget to put even a single parachute. Do seperatrons seem weaker? Icon Improvement (WiS3) Darkness settings (WiS3) Easier map movement / less clunky (targetting, manuveur node stuff, etc) (WiS3 & Gluckez) VAB camera/movement fixes/improvements/options (Gluckez) Better Exhaust (Jeq) Better Docking / Structure for them (Gluckez) Better plant-dust for wheels, landing, landing gears, etc (Jeq) Exploding parts cause more explosions (difficulty setting maybe) (Jeq) Improved parts manager (inflight + VAB) (WiS3) Robotics (Many) More intituative action group setting Fuel Flow Priority Correcting Delta-V readouts (Many) Entering/Exiting SOI sphere of influence color or effect difference (perhaps a pulsing in as well for entering, pulsing out for exiting) (WiS3) EVA Construction (Gluckez) Snap rotation to world (Jeq) "Ore" equipment (I'd have to imagine this will be a thing in some way for Colonies?) (Gluckez) Waypoints/Map Markers on surface (Steveman0) A mechanic to make precise sub-15meter target landings? (It's kind of a pain to do it perfectly first try. Seems like a thing that would be really nice for Colonies)

On the following thread: I decided to challenge the KSP2 definition from being a de jure et de facto sucessor of KSP¹, or a Fantasy RPG with space fare thematics and spells and powerups disguised as technology. The discussion, unsurprisingly, risked degenerating into an exchange about what's a RPG and what's a Simulator, derailing the host thread. So I decided to transfer the discussion to this one. Original post (edited on the host thread)

I did not really see or hear anything about a KerbNet mechanism which would allow real-time and on-rails scanning of CB surfaces. Also is there any information about telescopes and if the Exploration mode will start with undiscovered celestial bodies in the Kerbol system? Nothing about the buoyancy system? Do we have any clarification if probe exploration before manned has been set as a priority? What else did you expect to be included in the For Science! update and was not announced or mentioned?

I play Kerbal Space Program since rhe beginning of the last year, and I think there are some little details that could make KSP way better, like air an air compressor, wich transforms intake air in oxidiser using some EC (it could be an IRSU feature) and the possibility to (as a cheat in Sandbox mode) add parts and edit the rockets that are already launched; another cool feature could be an air-distributing sistem just like the fuel one. Another thing I think should be changed is that you must set structural pilons for every part singularly, making this a very long process for big rockets. I think those could be small, usefull features and changes to the gameplay.

Imagine visting Duna and seeing solar glare from Kerbol. Or landing on Laythe and seeing a meteor shower. I think that the small things, like auroras on Kerbin and Laythe and small flashes visible from Jool's moons on Jool (meant to represent turbulent lightning storms). I don't even think this really has to be features in the game world; it could even be a change in other aspects. What i'm asking for really is just some small details that add to the realism and immersion of KSP2. Some more examples would be the frequent solar storms on red dwarfs; if there is a red dwarf (We don't really know what System 3 is), then solar storms would be great. Another good thing with gas giants would be the way that wind currents travel on them. Wind currents travel in bands on Jool; this implies that there are belts and zones on Jool, just like on Jupiter. In that case, the zones would be high, cold air, i.e icy and therefore lighter in color. the zones generally move slower than the belts; but their relative speed varies. They also form less storms. Again, the immersion benefit would be absolutely massive if these sort of tiny, but good, changes make it into KSP2.

A recommendation for people looking for more difficulty in the game, add the potential for parts failure as an option. Engine failures, control surfaces sticking, gimbal lock, partial damage states for parts overstressed by aerodynamic or gravitational forces. Maybe for each of those add a way to mitigate the potential for these problems too, balanced against extra weight for reinforcement or reduced speed for an aircraft. Several mods out there already based on realism and equipment limitations.

Kopernicus Continued Planetary System Modifier is a mod that provides for the graceful introduction of new celestial bodies to Kerbal Space Program. This is where we test new things and learn how break the universe with gusto. Disclaimer This is R-T-B's "Bleeding Edge" branch of Kopernicus, intended to support the latest features, KSP editions, and also the latest bugs. Please keep in mind this branch may be more buggy than Prestja's stable Kopernicus branch, but it also supports more KSP versions and has more features implemented for testing reasons. Many features that make it into mainline Kopernicus are born, tested, and trialed by fire here. These features do get tested, briefly, and they generally work, but still, bugs can be slip by and be real, so it is important to BACK UP YOUR SAVEGAMES! It should be noted I am a member of the current Kopernicus Maintenance effort and this is an official Kopernicus-Continued subproject. Features: Presently, over the base Kopernicus Stable branch, this branch also features. 1.) Big plans, including support for non zero altitude lakes (not currently in the present builds), performance optimization experiments, and maybe even comets. Who knows in what order? 2.) Probably bugs. Backup your save. FAQ: 1.) When will this leave development? A.) It won't. The whole idea is this is the eternal testing ground. It stays here forever and ever and ever... 2.) What does this mod do? A.) On it's own, nothing. It's generally a dependency or modders tool. 3.) Can I has a CKAN version? A.) Sure, just opt in to our private beta CKAN repo. This will grant you auto updates from the beta tree and get you all this stuff straight from CKAN! Do the following technique to start this: From your main CKAN window, go to "Settings." "CKAN Settings." Click "New" under "Metadata Repositories" Add our CKAN repo in the resulting text box. It's the one called "Kopernicus_BE" No more FAQ for now, ask me something frequently and I may add it to stop you... Downloads Kopernicus "Bleeding Edge" Unified Downloads(the base mod) KittopiaTech "Bleeding Edge" Unified Downloads (this is basically a GUI for Kopernicus pack developers, hit CTRL-P in mapview, most don't need it) Please ensure you grab the right version for your KSP version! 1.8 needs the legacy release, anything newer, 1.9+ Credit. Credit must be given to other current Kopernicus Maintainers @prestja, as well as previous authors @Thomas P. , @Sigma88 and many others for their incredible work in building an elegant solution for bringing new worlds to KSP. Source Code Source code can be found on the GitHub repository. License Kopernicus is licensed under the GNU Lesser General Public License

Have you ever build silly features for your vessels? Put your ideas here! Typical examples include a swiming pool in a Laythe hotel, a maze, etc. I'll start: a table in my Lander. Seats 6 Kerbals with hot chocolate.

Basically, I have a lot of multi-role machines in orbit or on the ground. I've gone pretty far with this "multirole" stuff to be honest. Even as far as to build an amphibious scientific research vehicle (no lab, I didn't think to incorporate one) with vehicle recovery ability (robot arm with Klaw). After finishing my amphibious science machine, I started to wonder if I was feature creeping my designs. https://en.wikipedia.org/wiki/Feature_creep (Yeah, Wikipedia. It's just for a simple definition.) I mean, less can definitely be more, but Swiss Army Knives sell well for a good reason too. Minimalism isn't an excuse to be lazy; it's a reason to be efficient, sure. But in a game like KSP, can you really feature creep with scientific modules so small and portable? Are you really that bad off trying to cover all the bases? Especially when one of the important parts of progressing in this game is scientific research. Honestly, so far, I haven't experienced much trouble with this beyond price tags. That's even manageable if you can inadvertently create something that can do many of your contracts with little modification. Do you ever get the sense you may be trying to mash too much into a design? When do you realize you've gone too far? Asteroid harvesters on space stations? ISRU on rovers?

Hi all, since 1.1 pre-release I am playing a new career game and I have (unluckily...) sent a bunch of tourists out to a Mun/Minmus sightseeing trip w/o any chute to re enter Kerbin atmosphere. My fault of course, then I suddenly realized I could not bring them home safely if not by strapping some chutes to the craft - an auxiliary chuted&clawed skycrane seems like the only feasible option in stock. If tourists could be allowed to go EVA just for switching vessel or to man a command chair that could bring at hand a few more "quality playtime" opportunities. They obviously should not be allowed to collect samples or reports and to gather and move samples from pod A to pod B. Just sayin'.

Here are my tips on how to keep the core spirit of KSP intact while giving it some more features that enhance the immersion and wow factor of the game: Give the player an avatar Kerbal. This avatar is the director of the KSP and you can name him whatever you want. The campaign should start off with a car pulling up to the center with your kerbal inside, and you are given a tour of the center with Von Kerman. The previous director had an "accident" with one of the rockets and you were recruited to replace them ASAP. As a result, new safety features need to be put into place to prevent any more "accidents" from happening and to improve and inspire the rest of the kerbal race for space exploration. Your first job is to allocate budge for R & D and launches. Gathering science should NO LONGER be the only way to unlock new parts, but it can be used for a boost to funding and engineers. Parts require 2 things, money and engineers. And as oppsed to being able to unlock and use a part as soon as you can afford them, the parts should be researched that requires TIME. The more advanced the part, the more time it requires to research (and thus more funds). Science gathered from missions can be used to attract and hire newer engineering teams that can make the process go by faster and cheaper. SCIENCE SHOULD NOT BE A CURRENCY TO UNLOCK PARTS. I thought this was a silly idea since it was implemented. For example: Lets say you gather science from Mun on an EVA and return it to Kerbin. The science you gather is complied into your space programs science reputation pool, which in turn unlocks better engineers who want to work for you. At the beginning of the game only the craziest and dumbest engineers are part of your program staff but as you get more scientifically reputable smarter engineers start applying to work for your program. ANY engineering team can start research on a part in ANY part of the tech tree BUT it would take more or less time depending on the skill of the team doing the research. YOU SHOULD ONLY HAVE a limited number of teams, each with specific skill and knowledge level that impact how quick it takes to research and develop new tech. ONCE the part is built, you need to TEST IT at least a couple of times to certify it is usable for rocket craft. We as the player DON'T have to actually test the part BUT we can watch the test if we wanted to in the testing facility. Each part that we test has a chance to fail depending on the engineering teams safety record. If the part was a rocket engine, it needs to survive ignition, burn for x amount of time, gimbals in all axis (if it has gimbal ability) and survive shut down. IF a parts fails, it costs money and requires re-testing. In order to test a part we need a new testing facility. We should also be able to upgrade this facility, further improving the safety stats for each part we test. Once the parts passes testing, it is green lit for use on our rockets in the VAB. Engineering teams should have the following characteristics: - stupidity - safety - efficiency/speed - SALARY (per unit time) Our space program should have finite engineering teams with their own salaries, and finite slots to research parts. Engineering slots depends on our level of science facility. Tech tree needs to be overhauled. No more progression. It should be cut up into Engines, Structural, Tanks, Utilities etc. You can research ANY part you want at ANY time. The problem is that the more advanced the part, the longer it will take. Your program becomes a BALANCING ACT of funds spent on R & D, salaries for engineers and launches. If you start your program with crappy teams and start research on the KS-25 engine, all you're gonna do is spend a lot of money and TIME on one engine part. Your goal should be to develop simpler parts that allow rocket launches to gather MORE science to attract BETTER teams to research better parts FASTER, SAFER and THUS CHEAPER. Continued....