Battlescape Solar System & You: A Tale of Orbital Mechanics

Battlescape
1

Longish post warning.

Alright so I debated necroing an older thread that conveniently reminded me the last post was from me 990 days ago. It was slightly tangential to the topic(Realism in Battlescape) and I wanted a more focused discussion on orbital mechanics, specifically the planetary motions about the unnamed(afaik) star.

This is a pretty specific question for @InovaeFlavien regarding how the physics simulation calculates planetary orbits and motion and how its applied. I debated pming you privately but I felt why not open it for discussion because for me it’s an interesting topic.

It is my understanding that at the heart of the physics sim is an n-body simulation that calculates absolute distances and applies the force to each individual object. In addition to this, I remember being told that the planets will not orbit around the star due to compounding errors in their positions and velocities which is a valid concern. If this is still the case(Assuming that you will not simply glue them to conic sections and still have them orbit in which case the rest of this post is purely academic) I would like to propose an alternative to still allow a true n-body simulation that would accumulate less error per time step. There is a case to be made by trying to keep the physics sim nbody for any future developments(TQFE, etc) and it just makes my physics bones happy. I also just learned about it in class tonight so I’m really excited about it.

I’m going to start from the beginning for those who don’t write sims or have any knowledge about physics sims. I’m not sure what coord system the physics sim uses, but both cartesian and spherical coords will have large values of both radius and velocities at any given moment. This is the mentioned issue, and given a certain time step(say .001(1 millisecond)) you could still have significant error doing math on a velocity of say 22.2 km/s or 22200 m/s. This is not an unreasonable number for velocity and I’ve chosen this one because if we wanted an Earth like planet at 1 AU from a sunlike star, this is the orbital velocity. 100 miliseconds could give errors of 100 m/s per calculation so it’s necessary to have smaller time steps so we don’t lose accuracy. So there is a fundamental upperbound on the largest timestep without losing significant accuracy in the simulation which requires computational cycles and more importantly performance from the server.

What I’m proposing is a way that would still let us integrate along discrete time steps but with a larger time step, so that we can get the same accuracy with better performance or alternatively, more accuracy with the same amount of performance. This is where I’m unsure of the exact gains that could be made because I’m not really a CS person and I don’t know what’s typical or how much this may improve it and why I wanted a discussion.

Basically we can integrate along the 6 orbital parameters that describe any orbit, but because their relative changes are much smaller we don’t need as small as a time step.

Crash Course in orbital mech. An object in any orbit can be described by it’s semi major axis(a), it’s eccentricity(e), inclination(i), argument of periapsis(little omega), right ascension of the ascending node(big omega), and the Mean Anomaly(M). It’s possible to calculate the rate of change of each of these parameters due to a small perturbation(other bodies) and then describe the position and changes of position of an object in that manner. The relative changes of each of these will small because all of these are relatively static for anything in a stable orbit. So to repeat myself for the nth time it could be possible to have more accuracy within the nbody sim for planetary bodies with the same amount of performance is currently required by describing the orbits/positions of the bodies differently.

Of course, the devil is always in the details and this all depends on the fidelity of the inputs provided to the rate of change of the orbital parameters. At an initial glance it seems like it’s feasible and I’d be interested in writing a simulation in matlab this weekend if someone more familiar with performance could help me write test profiles for it that could help give a definitive answer.

As always, if you have any questions about this let me know and I’d be happy to try and find an answer and feedback is welcome. As for one of my own, @InovaeFlavien or @INovaeKeith, do you think this is something that could be explored for something in the future? I know you guys are already swamped with other stuff to do related with actually shipping the product and this is a side project for unnecessary flavour but it would be really tasty flavour that helps set the infinity universe apart.

5 Likes
2

I’m fairly sure that Flavien confirmed the celestial bodies in I:B at release would be static. I’ll try to find a quote.

1 Like
3

They also said bodies wouldn’t even rotate :cry:

I’d be very happy to see any discussion about adding this post release.

4

After reading that post, it seems to me that your basic assumption that the reason our solar system bodies will be static is because it’s a physics problem. It isn’t. It’s primarily a networking issue, then a performance issue ( updating the scene-graph every single frame because of dynamic bodies ) and of course restraining scope.

The plan for Battlescape is that when the server is booting a new match / game round, it randomizes the planets / moons locations along their orbital paths. It also needs to do a balance check to verify the setup is fair for every team, otherwise it needs to generate a new one.

11 Likes
5

Woohoo, I’m very glad this is the plan! Keeps rounds just fresh enough each time without having to do anything too complex!

3 Likes
6

The same planets/moons or totally new planets/moons?

7

Depends on how many planets / moons we put into the game and how many are needed in the round. We’ll probably adjust the solar system size at the beginning of the round based on the number of players. If there aren’t enough players, a “small” round will only last an hour or two with a handful of planets / moons, which could then get randomized from the entire available pool. If there are hundreds of players, the solar system will be bigger and the entire pool might get used.

8 Likes
8

But what about players joining a match in progress?
A match might start small but player numbers could snowball once people start joining.

2 Likes
9

If it starts small, it’ll end quickly and the new round will be expanded, so I don’t consider this to be a big issue. The opposite might be more annoying ( a match that starts with a lot of players, gets deserted, could last hours and hours with little action ). Might need to add detection cases and end up the match more quickly.

3 Likes
10

Some kind of sudden death scenario (a la Worms) would be a fun way of killing off a game quickly if it’s too big or small!

1 Like
11

That’s unfortunate but exactly what I wanted to confirm before I dove headfirst into figuring out the math behind it. Thanks. I haven’t had to deal with updating graphics or networking issues so I hadn’t considered that the bottleneck might lay elsewhere - I just remembered it being about a performance issue. Such an obnoxious thread title for an idea to go no where lol.

Thanks for the response and it’s good to know that at least the system will randomized. One of the thing that Irks me in planetside is that you can fight for days on a continent from one spawn…and then you fight for the same place from another spawn and nothing has really changed.

2 Likes
12

Space Ocean slowly rising to drown the entire star system would certainly give a unique cachet to I:B

3 Likes
13

Definitely agree that there are more important things to focus on for release.

How bad would it be to enable realistic planetary rotation somewhere down the line? Although the planets/moons won’t necessarily orbit, the bodies would at least appear more alive if they rotated in place.

14

The current dev build already has a variable that allows the planet to rotate, but as flavien was saying, it’s the compounded networking issues that make doing it non-trivial.

15

I understand that there are variables which are best to be left alone, disabled. I’m just hopeful that with better hardware, better servers, and more refined net-code that it gets unlocked after release. It’s not a concern when the game isn’t released.

1 Like
16

As far as client-side goes, I’ve messed with the variable and it doesn’t really break the game itself even when putting the rotation speed up to stupidly high levels (the level of detail just stays permanently low). The bases themselves are static in space at the moment and don’t move with the planet. It really all comes down to network synchronization.

1 Like
17

Maybe stations should orbit? That would have less of an impact on networking and more relevance to the timeframe of a single match. It also depends whether stations will be destructible or simply capturable. It would be fun to deorbit a station, but I understand if that’s totally beyond the initial scope of the game. What certainly will happen though is capitals ships being deorbited. Will they even fly in an atmosphere?

1 Like
18

I really really would like moving battlescapes and a deorbiting station would be great.

Generally Objects in Orbit move faster than Object on an rotating Planet…

19

Yes, but all the bases on a planet plus the planet geometry rotating and revolving would have a much greater impact than a few orbiting objects, even if the planet is moving slower. You would have to redraw many more triangles every frame.

20

Tris are redrawn every frame regardless of whether they are moving or not. Graphics is not the issue here.

If I understand correctly, having stations orbit would be more feasible than having the planets rotate.
This is because they are leaves* on the scene-graph whereas planet surfaces have child nodes - Either ships in atmosphere or in contact with surface.

* except for when ships are in hangars, but perhaps if stations were orbiting too (ships already do), the ships wouldn’t have to become children of the station - they would just orbit along with the station they happen to be inside of.

1 Like