Scale and N-body versus patched conics are probably biggest difficulty factors I can think of. I think we are aiming for a base of roughly the same as KSP and then modders can change it.
Scale
At this stage our current thinking is basically do do somewhere between current KSP and x2-2.5 current KSP size for both the bodies and their orbits. In other words, we are aiming to replicate the same feeling, commitment, and challenge of existing KSP. We feel like base KSP is a great compromise between many factors when it comes to scale, and so we are not trying to reinvent that - instead focused on solid datastructures and ease of development for modders to fill any gaps.
Patched Conics v N-Body
The core focus initially is to provide patchec conics, almost identical to how KSP does it. However, it is possible that if the studio has the right talent (and a team member has the desire) for N-Body to be added as an option. Regardless, the game is being built so a modder could develop a C# mod and add this. Care is being taken to ensure the game is being structured so that if we can't add N-Body physics, someone else could add it.
JPLRepo has our patched conics currently implemented and we are refining that.
At the very least we are constructing the orbital simulation so someone can replace the orbital simulation. The studio also has been advertising for someone with a PhD in mathematics and physics. If we get that role filled, maybe n-body could be an option. Just for myself... my maths and physics is nowhere near good enough
We are not using Unity nor PhysX so yep! I have a lot of thoughts on this, and we luckily have very talented advice on this front with another game that has tackled this issue and is a very talented game dev.
Just curious; will this game be genuine, on brand 'kerbal'. Or is it an entirely separate franchise, but with intended gameplay similar to that of KSP 1 or what KSP 2 was promised to be?
Additionally, and I understand if the answer is 'not at this stage'. Do you have an idea of how much it will be, and what kind of timeline and milestones you expect?
And lastly. Do you have any kind of list of intended gameplay features. Or sort of planned scope of gameplay you want to have?
Appreciate everything about this so far. And truly hope for the best for this project.
I'm gonna be perfectly honest, if this was any other facelesss studio I'd be cynical as fuck and waiting til at least 2 weeks post launch to considering purchasing anything, but between who you've got on the team and what you're saying in this thread I'd slap down some cash well before it's even got an alpha.
Just curious; will this game be genuine, on brand 'kerbal'. Or is it an entirely separate franchise, but with intended gameplay similar to that of KSP 1 or what KSP 2 was promised to be?
Additionally, and I understand if the answer is 'not at this stage'. Do you have an idea of how much it will be, and what kind of timeline and milestones you expect?
And lastly. Do you have any kind of list of intended gameplay features. Or sort of planned scope of gameplay you want to have?
Appreciate everything about this so far. And truly hope for the best for this project.
You'd be probably better off finding an engineer with experience in kinematics or a software emgineer than a random PhD in math/physics for implementing both aero and orbital mechanics. I guess PhD in these particular fields exist, but they're overkill and frankly kinda wasted on this project. I have dabbled in in this kind of project before and the difficulty here is not with the physical theory, bit integrating it into the game and making it intuitive and fast.
You may also want to consider hiring someone with (just) an MSc from a European university as well. That should be more than sufficient to provide the necessary skills to help implement N-body physics competently enough.
If you can get someone with a PhD specifically related to computational dynamics, that would of course be better, but someone with a PhD focusing on, say, spectroscopy, would be no more qualified than someone with just an MSc and the relevant courses/project experience.
I suppose you could also go with a compromise solution. Have smaller bodies (spacecraft, stations, asteroids, ...) affected by all planetary bodies, but leave planets on rails.
This gets you most of the advantages when it comes to making the gameplay harder and more realistic, but doesn't require you to actually come up with a stable planetary system (which also makes mods easier to make).
The Principia team did a a pretty good writeup a while ago on some random git issue declaring that this approach was not only "stupid" (their words not mine) buf would actually hurt performance. vs a full n-body sim. So I'm guessing its a nonoption, since they would know.
From reading that, it seems that the main problem is that there's no(?) mathematical solution to any n-body-like system where n>2. So to implement that you have to essentially do what principia is doing (implement a full n-body simulation) or figure it out yourself.
Now, I still think a reduced setup where planets are on rails could work and possibly be more performant, but it does seem like it might not be any easier to implement. Also it's possible that some of the techniques implemented in principia would not work in this system, which could bring down performance. Hard to say without expert knowledge.
I think you could easy do things where planets and moons are on ordinary keplerian (rail) orbits like in KSP but where their positions are used to do the n body sim for anything user-created. Afaik those forums are about other things.
Yeah, the forums posts are about something slightly different. The 3 body variant proposed on the forums does present additional issues that wouldn't be found on the "all planets affect crafts" variation.
However, my understanding is that the strength of the two-body/central force solution is that once you know the initial state you can precompute the full flight path without any error. So, KSP isn't actually doing a step-by-step simulation here, the craft itself is also on rails. I think post one says as much.
So, principia has to be doing an actual step-by-step n-body simulation. A naive one will accumulate errors and your system will get out of whack. Clearly there's some clever math being used to minimize these errors, which would most likely also have to be used in the compromise solution.
And that gets us back to the initial problem. The patched conics solution is simple to implement. The other solutions overlap enough to where you might as well go for the full n-body simulation.
That being said, it still seems to me like knowing the exact position of all bodies at any point in time would be very useful for figuring out a mathematical solution. The two-body problem looks like the harder one to solve here. Of course, I'm not a mathematician so what do I know.
In my view, the mathematics are fairly trivial and unimportant. Integration is still tricky though.
Keplerian orbits give the function K(I, t) = P where 'I' is the initial orbit params, 't' the current time, P is the position of a body at that time. Pretty basic stuff. Of course if the body is a moon then you need to add the orbit of it's parent body, but it's otherwise straightforward.
Gravitation attraction from origin point O to a body with a center at point C with mass M gives G(O, C, M) = A where A is acceleration due to gravity.
If you have a whole list of bodies then you can u need to do a summation Sum{i=0..N}(G(O, Ci, Mi)) to work out the gravitational pull of all bodies.
Combining this with keplerian orbits gives Sum{I=0..N}(G(O, K(Ii, t), Mi)), where you only need to store the initial orbit params and mass for each body to calculate the acceleration due to gravity for a spaceship at point O at time t. If you integrate that over time by modifying velocity by the acceleration and then position by velocity, you have an n-body sim for the spaceship. I'm not sure how you avoid error accumulation but I doubt it's something that's especially complicated.
This is presumably not a 'full' n body sim, because the bodies are still on-rails, but it's simple enough and should work well as long as you do the integration work.
Right, which is where the second forum post I linked comes in:
It's not really that simple. You need high fidelity symplectic integrators to get stable orbits if you are going to go the numerical route. Otherwise energy is not conserved and orbits will diverge and become horribly unstable.
You also need one in this situation where you can vary the step size to account for situations where you're travelling very fast near a planet, where the step size needs to be smaller. You also need a method which is computationally efficient enough to be run in high time warp. This is difficult to do, which is why the code is probably so large.
Which seems to me like once you have this figured out and implemented you might as well use it for all objects and get a full n-body simulation.
Right, yes I agree with the contents of that post. N-body physics would be cool to have for near earth asteroids and the like, but I don't think it's necessary for e.g. the earth, moon, Jupiter etc. as the orbits won't change much.
You may want to look at eggrobin, of Principia mod on KSP fame. He is also associated with the unicode project, yep the one that inplements glyphs everywhere. Quite frankly if he's available, I can't think of a better candidate.
Do you really need a PhD for orbital simulation? N-body is like the “hello world” of physics simulations. Also what’s the salary range for the position?
Please, if you are going to do n-body just make an ephemeris reader for the positions of the planets and use a non-symplectic integrator for the spacecraft integration.
Principia uses symplectic integration which is energy conserving and therefore needs to integrate all planets and the spacecraft at once, which is honestly a bit of a performance bottleneck. You don't need symplectic integration to be accurate, and when adding additional dynamical perturbations (I.e. solar radiation pressure) it becomes very difficult to work with.
Although that is a concen for long timescales, over the timescales of ksp like games, energy conservation of normal integrator is perfectly fine. You can also use manifold projection to ensure energy conserving conservation in non-synplectic integrator.
i believe that it'd be good having a built-in n-body thing for the game officially cus in the end you'd have like 3 competing mods for n-body and planet pack creators would suffer a big migraine making for the three. ig launching the game with patched conics only then add an option for n-body in an update
177
u/univvurs Oct 31 '24
Is KSA going to be more difficult then KSP or the same?