Squad, ideas for the far future. Think dollars.

[Azimech]

At this moment KSP is a wonderful product with excellent capabilities.

However I see possibilities which KSP cannot and shall not provide. For the far future I can see possibilities which could attract a lot of people, increase educational value even further and - not the least important, increase market share.

Who knows, after KSP 1.0 is released and you guys want to look at a new product or maybe an evolution, I propose the following:

1: A revised node system. The current system of single parent nodes is fine if you're stacking tanks, rocket engines and other "simple" stuff. If you want to build something more complex, users often need to use add-ons like Select Root, Editor Extensions or Part Wizard. Even then there are some serious limitations or they take a lot of time to work around.

For people who want to build complex machinery themselves like a landing gear or a gearbox there could be an option to go into the advanced editor mode: parts are placed at a certain coordinate with the option to lock movement of X, Y or Z is the first step. Then, one could choose multiple adjacent parts to form a connection with the new part. Also, removing a single connection from multiple would leave the rest of the construction intact. In real life construction is often done with multiple connections without having to use struts ;-)

2: The inclusion of a fluid dynamics simulation. Today's PC's are probably not yet powerful enough but in 3-5 years time they might be. The inclusion of such a system can provide a lot of wonderful things like designing your own jet engine, rocket engine or car engine. Here's a nice simulation: http://physics.weber.edu/schroeder/fluids/

3: Bearings, both axial and radial, for the creation of moving and/or rotating parts.

4: Standard procedural parts with materials choice. One doesn't create a bell nozzle out of copper or aluminum, and one doesn't create beams out of ceramics. Well, maybe for fun. Furthermore the current standard parts are perfect for gameplay and to provide an experience other can relate to. But procedural parts can have it's limitations as well: tech level limits, part count, mass per part, material choice and/or budget.

There's more but these are the most interesting (and most difficult to implement, I think). Maybe some day a lot of users will team up and build a replica of the Saturn V, with working internal systems. I know there are millions of gearheads, tinkerers and MacGyvers who want to create excellent stuff but can't due to limitations in real life - nagging girlfriend about the car parts in the garage, etc.

Designing stuff is becoming the new industrial revolution, more important than the actual production. 3D printers will provide production and it's increase will be exponential worldwide. What better than to have a system to learn and design and test ideas in a playful environment.

[klappertjes]

I don't see how 1, 3 and 4 would draw new players in. It sounds like these ideas would make the game massively more complex. Regardless if you're for or against that, I think it's generally agreed steeper learning curve = less newbie-friendly.

The impression I get (and in this I may be wrong) is that SQUAD aims to make it easy to understand the most basic concepts of KSP (building a rocket, flight controls & orbit parameters) while not forcing players to do adhere too much to this silly thing called "realism". Hence a smaller solar system, forgiving mechanics, etcetera. Just saying they seem unlikely to listen, my own opinions aside.

As for your specific points:

1: IIRC, there are limitations in the game engine they're using, Unity, that make it hard to do much about the node structure. The struts are a workaround. I agree that they're not often pleasing to the eye and that's a problem, but bear in mind that the parts of real rockets are effectively strutted to hell inside their aerodynamic shell. See 4.

2: I'm not quite sure if you mean a better aerodynamic model (which is really fluid dynamics with lower density, I've been told) or modelling the internal workings of engines. It sounds like you mean the second, and holy mother would that be awesome ... in another game ... if you know what you're doing. You're going to have to teach people the basics of mechanical engineering before they can hope to make anything worth a damn. I would almost certainly play this Kerbal Engineering Department game but it has little to do with space exploration. I think it's fair to say this is quite a bit beyond the scope of KSP.

3: This folds into 2 I guess. If we're designing systems on the smallest level then this would be a must, but should we? I'd love for SQUAD to adopt a Infernal Robotics kind of part set with hinges and rotors, but for the scope of KSP they should be modular parts, IMO.

4: I personally like the challenge of having this finite set of parts and trying to make what I want work with them. Playing with mods does not break this for me. I have more diverse parts but they still won't always do what I want with them exactly. The one procedural part I would like to see is hulls for your rockets. As it is they look like they were stripped of their hull, with struts and all visible. When aerodynamics gets fixed we'll need to do better than that. It's not unreasonable and game-breaking, IMO, to be able to mold a hull around the rocket you've built for looks and drag reduction.

As for choosing materials, the way I see it, it would make building things a lot more frustrating and error prone for people that don't know you shouldn't make nozzles from copper for example (I didn't know that, but I'll take your word for it). They'll try to and their rocket won't fly worth a damn, and they won't know why because how could they, and get frustrated. The way to remedy that I guess is to give them a crash course in engine nozzle design and the characteristics of different materials. Then they'll have to figure out what this means for nozzles before they can even think of getting anything off the ground. Designing machinery from scratch could be fun, but I don't see it fitting KSP. Right now the game goes "look, here's a nozzle that works and provides this amount of trust and is this efficient. The boys in the lab tested that already. Trust us on this one", and that's fine by me for the purposes of going to space.

Taking a slight left on your original ideas towards off-topic lane, wouldn't it be totally awesome if this was indeed another game and the paarts conceived there could be ported into KSP for the profit of kerbalkind

EDIT: and I just re-read and saw you are proposing "a new product". It's still not clear to me if you mean KSP 2: Moar Boosters (), or an entirely different game, like I proposed? Your points seem focused on integrating it in KSP, so the first.

Edited May 21, 2014 by klappertjes

[Azimech]

No, not at all integrated in KSP, the limitations are obvious. I wouldn't mind, either KSP 2 or a different game. And who knows how Unity will evolve in the future?

Edited May 21, 2014 by Azimech

[Red Iron Crown]

KSP 2: Moar Boosters

Off topic, but if there is any justice that's what the KSP sequel will be called.

On topic:

With #4, I have mixed feelings about procedural parts. It is definitely satisfying for experienced players to get exactly the part they want, and procedurals definitely help reduce part counts. That said, they also make the game more complex for a new player, who is likely to just be slapping a few parts together and seeing how it goes. It also, IMO, takes a bit away from the "Lego-like" modular construction of KSP. For those reasons, procedural parts fall into the "better left as a mod" category of suggestions for me.

[cantab]

My thoughts:

An overhaul of the construction system would be good for a sequel, but probably too much effort for too little gain for v 1.0. Perhaps a good interim measure would be some sort of "solid" strut. Either placed like the current struts, or perhaps it attaches like a stack or radial part and is automatically extended until it hits another part which it then connects to.

Simulating the internal behaviour of the engine is way beyond what KSP should be I feel. Such a program would be a game unto itself given the challenges of just getting one working.

Hinges and bearings should definitely be in stock. They ought to be simple enough to code and they'll really open up possibilities. Cargo bays, spinning space stations, tipjet-powered rotors, etc.

Procedural parts might be good for KSP 2, they'd give it a fresh feel and a cleaner interface. That said I'm not sure I'd want everything to be infinitely tweakable. It would probably make sense for engines to be "off-the-shelf" items, while fuel tanks would be highly flexible.

[Azimech]

Off topic, but if there is any justice that's what the KSP sequel will be called.

On topic:

With #4, I have mixed feelings about procedural parts. It is definitely satisfying for experienced players to get exactly the part they want, and procedurals definitely help reduce part counts. That said, they also make the game more complex for a new player, who is likely to just be slapping a few parts together and seeing how it goes. It also, IMO, takes a bit away from the "Lego-like" modular construction of KSP. For those reasons, procedural parts fall into the "better left as a mod" category of suggestions for me.

I agree with that to a point. There should be an "advanced player or something like that" feature for people who like it and standard for those who don't.

[LaytheAerospace]

#1 and #2 are pretty much impossible. Well, #1 is possible, but don't hold your breath.

The way the ship works right now is it's a tree. What you're asking for is an undirected graph. These are two VERY different data structures, and anything they've written to work with tree based rockets would have to be literally thrown away to handle a graph based rocket. Tree based rockets also let you make a lot of assumptions (like staging a decoupler will never cause a part above it to be staged, while all the parts below it will always be staged). This is not true of graphs.

Proper fluid dynamics simulations require enormous amounts of power. Most people game on barely adequate hardware already. There's also the huge cost of developing the simulation software, since off the shelf products aren't going to integrate well with a video game that has its own ideas about what the computers hardware should be used for.

[Azimech]

#1 and #2 are pretty much impossible. Well, #1 is possible, but don't hold your breath.

The way the ship works right now is it's a tree. What you're asking for is an undirected graph. These are two VERY different data structures, and anything they've written to work with tree based rockets would have to be literally thrown away to handle a graph based rocket. Tree based rockets also let you make a lot of assumptions (like staging a decoupler will never cause a part above it to be staged, while all the parts below it will always be staged). This is not true of graphs.

Not entirely true. While it would make craft files a lot bigger and less easy to read for the user, human logic always finds a path to make these things work in an orderly fashion. Just by doing it and learning. Small steps. Like the early transistor radio's were analog and people were exploring the possibilities of the transistor, to the first circuits capable of computing stuff. And again, this is not for KSP but a future product. Don't expect any fundamental changes in KSP anymore, users are very vocal. Just the economy, missions, multiplayer ... some clouds, cities and a few moons and planets. That's probably it.

Proper fluid dynamics simulations require enormous amounts of power. Most people game on barely adequate hardware already. There's also the huge cost of developing the simulation software, since off the shelf products aren't going to integrate well with a video game that has its own ideas about what the computers hardware should be used for.

Start simplified. Like the current placeholder aerodynamics and then comes a genius like Ferram4 ... with fluid dynamics it's the same. You don't need everything in place at first. Look at the link to that demo I placed in the OP. Yes, the current pc's aren't ready for the job. That's why I wrote in the FAR future ;-)

By the way, cross-platform software is being developed since the 1970's so don't worry about simulation software not being compatible. If there's a market, it will be compatible.

If Squad won't build this future product, a different company/house will. It's just a matter of time.

[LaytheAerospace]

Not entirely true. While it would make craft files a lot bigger and less easy to read for the user, human logic always finds a path to make these things work in an orderly fashion. Just by doing it and learning. Small steps. Like the early transistor radio's were analog and people were exploring the possibilities of the transistor, to the first circuits capable of computing stuff.

I'm not saying it's not possible. They could build an array based ship if they wanted. I'm just saying they're already pretty strongly committed to the tree based approach, and probably for good reason. Seems you agree with that on principle, though.

Start simplified. Like the current placeholder aerodynamics and then comes a genius like Ferram4 ... with fluid dynamics it's the same. You don't need everything in place at first. Look at the link to that demo I placed in the OP. Yes, the current pc's aren't ready for the job. That's why I wrote in the FAR future ;-)

By the way, cross-platform software is being developed since the 1970's so don't worry about simulation software not being compatible. If there's a market, it will be compatible.

Compatibility isn't as simple as you seem to think. I'm a software engineer (bachelor's degree and everything), and have professional experience porting Linux software to Windows. Cross platform software may have been around for a while, but that doesn't change the basic economics of software engineering. You're not going to invest the time and money into developing for a platform that doesn't have enough customers to justify the cost.

Highly specialized software like simulation software is rarely multi-platform (I don't want to say 'never' but I'd bet that's the case). Essentially all HPC clusters run Linux or some proprietary OS, so there's no additional market to capture by making it multiplatform. It also needs to be as fast as possible, which often means OS or hardware specific optimizations. This software is often built on contract, anyway, and the contractors aren't going to pay you to build a version for an OS they aren't using.

Fluid dynamics is also a lot harder than you seem to think (apologies if you meant several decades out when you said "FAR future"). The stock aerodynamics and Ferram are just approximations. Ferram is the better of the two approximations, but it's not because they found some revolutionary trick to simulating fluid dynamics, it's because it uses the correct equation (stock aerodynamics don't scale lift correctly, which is part of why you nose down at high speeds in stock). It also does some nifty stuff with part by part drag (using a raycast, I assume), but again, it's not actually simulating anything, just approximating.

Fluid dynamics is actually one of the hardest problems in computing, and brings the fastest supercomputers in the world to their knees. Doesn't help that it gets harder the faster the simulated flow is moving, both in terms of the necessitated step size, and in the complexity of the calculations being done in each step. Several supercomputing records have been broken by machines designed to simulate fluid dynamics and turbulence.

Really, something like Ferram is all you need in a game. I just wish we didn't have to resort to an addon to make lift scale correctly with velocity.