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
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 ?