Surely planets and stations will be orbiting. Why do you think they’ll be stationary?
No, they will be static. It came up in our conversation with Cray, Gene and Stannum on IRC, also there was a quote from IA presented.
As with many other features, it depends on funding. Flavien and I discussed celestial mechanics and “interaction zones”, and my take on it is while doable (1000’s of coding man hours doable), it would not be doable under minimum funding conditions, it would require us to hit the “jackpot” as Flavien put it.
If you remember the ICP battleship following zone: “ICP1 took me 50-100 hours, and that was just for a battleship, and it had many restrictions/specifics to the system”. - Flavien Brebion
While we all want it, like we want many things, it’s a matter of resources, scope & priority.
I thought planets orbiting their star and moons orbiting their planets was already done in the engine?
…And from the blog post:
Orbital velocity mechanics are also supported.
Could you explain what it is that needs to be coded?
Thanks 
What is currently implemented in engine is discrete orbital mechanics of player ship to massive object, like a planet or moon. There are HUD indicators for setting direction and speed, once you reach both of those conditions, you can disable flight assist and your ship will maintain orbit without any further player input.
What is not in-engine is full blown celestial mechanics. Planets orbiting stars, moons orbiting planets, rings orbiting moons/planets, etc. “celestial mechanics make the game 10 times more complex to code” - Flavien
It’s a frame of reference problem/network code issue. To make all that work smoothly for a multiplayer game will take more resources than we’d have available in a minimum funding condition.
Not giving speed limits here, but as an example of the speeds we’re dealing with in terms of netcode, in the current prototype, the conventional thruster speed indicator pegs out at 50 Km/s, and the warp indicator at 300,000 Km/s. The big issue with celestial mechanics is zone transition system which runs perfectly smooth without network stuttering.
I’m sure Flavien can do a better job explaining it.
2 Likes
HOLY-! Earth’s moon in 2 hours. If you gotta have a sublight speed limit, that’s not bad.
It’s not a limit, it’s just where the indicator ends, you can keep accelerating, and there is a text readout now that gives actual speed. The indicator bar is how you set your speed in flight assist mode. I’m probably not explaining it well, but I can’t show a screenshot of that just yet.
1 Like
for battlescape’s intended match based gameplay orbits probably would never get noticed, but i’ve been thinking that a static solar system map thats the same every time would get dull fairly quickly. Might be good to randomize the position of the planets and moons in their orbit on match start, just to add some more variety.
2 Likes
Thanks for clarifying, at least about the state of the engine. I had always assumed celestial bodies orbiting on rails had been in the engine from very early on.
They were at some point, but since the introduction of physics and networking it had to be disabled.
Imagine two ships flying at a perfect constant velocity of 1000 Km/s in one direction. They’re not moving relative to each other, so in terms of newtonian physics, the relative velocity is zero. For this to be consistant “visually”, let’s say you’re one of the ships and the other one’s just in front of you, well, even at 1000 Km/s, the other ship would look perfectly static in front of you. It wouldn’t even move by a pixel.
That’s the solo scenario.
With networking however, things are totally different, due to latency. The server sends the position of the second ship at a fixed rate, let’s say 20 times per second, while the client does position interpolation. But each position packet that is received is affected by variable latency, some packets might get dropped, or received a bit delayed, or a bit in advance. The result of the interpolation is visual stuttering, ie. the ship seems to “wave” around an average position ( which is that pixel-perfect theorical position of the other ship in front of you ). The amplitude of that wave is directly dependant on the absolute speed at which you’re moving. The keyword here is “absolute”, because even though relative to each other the velocity is zero, in terms of networking the absolute speed isn’t, which means that if a packet has 1 millisecond of delay, at 1000 Km/s it means the positional “error” is 1 Km. In this particular case, you can basically expect to see the “other” ship to jump around randomly by distances of up to 1 Km at a rate of 20 times per second.
Now that’s for a speed of 1000 Km/s, now imagine the result at 300,000 Km/s.
TL;DR: networking issues make the mater extremely hard to solve, so we won’t do it until we’re in a comfortable spot funding wise.
3 Likes
I see the difficulty.
Thanks.
[quote=“INovaeFlavien, post:485, topic:227”]
The keyword here is “absolute”, because even though relative to each other the velocity is zero, in terms of networking the absolute speed isn’t, which means that if a packet has 1 millisecond of delay, at 1000 Km/s it means the positional “error” is 1 Km.[/quote]
“Absolute” is definitely the key word there. The warp prototype had planets on rails and had smooth interaction of ships meters apart while racing across a system at up to 0.1AU/s. That’s because it separated the gross absolute velocities from the modest relative velocities.
-
I defined an interaction radius for each object. That radius was the range that the object could physically interact with other objects. I think it was 20 ship radii and 10km for planets.
-
I calculated an arena for each object. That arena was made up of all objects which could interact per point 1 above. If an object was within the interaction radius of another object, they were in the same arena.
-
An object was chosen from the arena as the fixed object. All other objects were considered to move relative to it.
Once that setup was established, I could move the arenas around at ludicrous velocities while still allowing the objects within an arena to move around very precisely relative to each other. As far as a client was concerned, it was just flying around in a stationary frame of reference.
It’s very much the same mindset as performing a view transform that places the camera at the origin.
2 Likes
Just saying it again:
Moving arenas are really really high on what I consider “deal maker” for Battlescape. If you don’t want to risk it, at least consider moving it a little down from the “ultimate funding” requirement.
Also. Wrong thread.
Yeah, I was using a similar mechanism in the old ICP ( the “bubble” system ), and even in the prototype I’ve been experimenting with relative positions / velocities across network instead of absolutes.
It doesn’t change the fact that you have to take that into account in all game systems, so there’s quite a bit of work involved, which is why we aren’t doing it right now - it’s totally out of scope for the prototype.
There are all sorts of other issues which I haven’t talked about ( some are 3D-engine related, like performance of updating an octree when everything moves at dozens of Km/s ), but trust me on that, solving these issues isn’t just a matter of a dozen hours of coding, otherwise I would already have done it.
I posted in reaction to the “extremely hard to solve” comment. It’s not hard to solve - apparently you’ve already done it once before - but it’s certainly time-consuming to retrofit lots of code that wasn’t designed with that sort of a system in mind. Perhaps I took “hard to solve” the wrong way.
Since we are on topic @INovaeFlavien, could you elaborate a bit on your conclusion that you can support hundreds vs hundreds of ships in a battle and Keith’s recent hint that you can even achieve thousand ships in a single battle shooting at each other?
I mean, just a theoretical summary of how is this going to be possible, for instance are the hundreds of ships going to be within shooting distance, or are you planning some separation systems, are there some in house technical tricks you have?
@critic: it’s all theorical and we haven’t really reached a conclusion on the exact limit. I don’t think it’s even right to speak of an exact limit, because there are tons of scenarios possible. Keith most probably said that in context of the entire solar system, where hundreds ( up to thousands ? ) of players would be spread, and obviously not all be on screen / range at once. In that case there could be multiple battles, each featuring between dozens to hundreds of players in proximity.
We don’t even have server specs yet, so there’s no way we can give you an exact number on the amount of players we can support. But our goal is hundreds, yeah.
3 Likes
ED newsletter is out, more planetary landings pics and a HUD are featured, next game update is on the 6th, CQC.
http://us2.campaign-archive2.com/?u=dcbf6b86b4b0c7d1c21b73b1e&id=1e67894391
1 Like