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
Well what can we say.
They accepted the challenge.
Or playing all or nothing.
Whether you like it or not.
Inovae is going to have to play their “game” now.
I feel somewhat guilty too.
I always said they have not shown anything yet.
So they have nothing.
Well …they shown now.
Not much so far… but damn, they picked worst time possible.
I don’t think this is coincidence.
1 Like
What do you mean? This changes nothing.
They always said they were going to do planetary landing.
If anything, it may actually be the I:B kickstarter that will hinder Elite. They are offering an expansion at the price of a full game with only airless moons, I:B will be offering a full game at the price of an expansion without limits by planet types.
Even with them being pretty different otherwise, there will be this comparison.
3 Likes
That is, if we dont get to always play the same system with the same planets :I
I mean wasn’t there said to be differences in the variety of planets based on funding, or is my mind playing a trick on me?
the second
I didn’t follow this game a lot but I wonder : “how they could have add planetary landing on their game “on a second time” ?” I mean, as a programmer, I’m really perplex … is it real planetary landing without any loadings ?
From the little bit of E:D that I played, using supercruise to fly to rings & stuff, there were instances, not fully (technically) seamless. I suspect the new orbital flight mode is another instance mechanism.
“Seamlessness” as a feature is subjective to the player I think. As long as it feels seamless to the players playing the game, that’s what is important. I think E:D does a good job of this.
2 Likes
not true.
the planetary landing is already seamless but you take hours to reach the surface due to the low speed.
They simply haven’t activated the LOD for planets
No govny. That does not really count, if that counts then X2: The Threat (2003) also counts as seamless landing with its “Danger, entering atmosphere” warning. Though in some cases the warning is given after passing the first layer of a planet. But X2 had floating point issues as I show in this video:
Of course it counts…the main point with the Elite video above is that the textures (and subdivisions of the surface) kept on generating more and more detail as you approached the planet even back in Alpha. I tested this out many many times myself back then before they added the “barrier” before release. If it was just a simple static texture then it would have been just a blurry mess that close to the surface, but instead more detail was generated in realtime as you approached.
The data for generating the surfaces has been there since day one. It’s just that the heightmap data has only been represented as normal maps to begin and with rather low LOD quality since noone was suppose to go down there at that time anyway…Horizons will obviously change this since now they have had time to work on that detail.
Oh…and in regards to the ring systems they are also “seamless” (whatever that means in context of games). The difference between what is seen in Elite and the rings Inovae have shown is density. The Elite rings are much more densely packed with asteroids (due to gameplay reasons) and this makes it very inefficient to load all of these in while still moving across the ring in supercruise speed (30 km/s minimum). Loading that many 3D models in and out that fast would be a huge hit on performance. That is why the only show the actual 3D assets when you enter “normal space”. You can however drop out into normal space at any given point and still move in towards a give area (RES, rings, stations, conflict zones)…it will take some time but eventually you will arrive and the things will be where they should be. You will even connect with people in that area this way.
1 Like