Search the Community
Showing results for tags 'ksp3'.
-
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.
- 24 replies
-
- 1
-
- development suggestions
- ksp3
-
(and 2 more)
Tagged with: