Networking - Making Battlescapes Move

Battlescape
1

I know this is a big technical engineering problem. But I just had an idea for one way to solve the problem of reliable connectivity when it comes to fast moving ships. And it involves relative positioning of course. I want to share this here.

Problem: When moving at very high speeds in an absolute coordinate space, small network connection issues can result in lost or to few positional information that can result in ships being displayed hundreds of kilometres from where they should be. Flying in tandem is very hard and unpleasant because of that. The faster the movement relative to the absolute frame, the more all the ship positions start to “wiggle”.

Relative to absolute:
My idea for a solution to this, and I’m sure someone else had this idea before me, is to use nodes instead of having ships use the absolute coordinate space, only allow nodes to use the absolute coordinate space. All other entities, like ships, stations, asteroids, planets only use coordinates relative to those nodes.

Movement:
When it comes to movement. Entities inside a node would have vectors relative to the node. A vector addition is then run every cycle, incorporating the movement of all entities in a given node (fancy multiplies can be used to determine the amount of influence entities can have on the resulting vector). This vector is then added to the movement vector of the whole node. This addition and not assignment of the resulting “member vector” to the vector of the node means that the node itself would mimic the movement behaviour of its members (e.g: Newtonian), because as soon as the node is accelerated due to the entities acceleration inside of it, it cancels out the relative vector of the node to the entities inside of it.
After one cycle the node would have adapted (updated) itself to what was going on inside of it and could reflect that by moving all the entities inside of it.

Transitions:
Nodes need to allow for entities to enter as well as exit. What is important to note is that no entity should exist without a node unless it will not ever move relative to the absolute space (e.g the Star, if the’s only one). If an entity leaves a nodes hard border and there isn’t another node close by, it will create a new node.
My idea for that, to allow the most smooth experience in those node changes, is to allow an entity to be in two nodes simultaneously by using a “fuzzy/smooth border” as well as a hard border and using an interpolation fading from 0-100% influence depending where the ship is inside the “fuzzy” border.

Size Change:
Nodes also need to change size to allow for more space if more entities enter. This can be done a number of ways that change gameplay more then performance. So testing would be in order for that.

How does that help?
What this doesn’t solve is the missing information. We can’t create information out of nowhere. There are ways to guess, those have been used often and are proven and still can be used below/on top of that. What this does is minimize the impact of that problem. If the problem isn’t that problematic if the ships move slow relative to the absolute coordinate frame, why not create a coordinate frame so that the ship will move slow relative to that? This does that. It allows for flying close to each other fast without connectivity problems making ships “blink” out of sight.

  • This does help if you fly close to an orbiting station.
  • This helps if you fly in a fleet.
  • This doesn’t help if you fly alone.

Example:

  • You approach a planet fast and want to suicide burn in the last second. You connection cuts out and you crash. With this system this still happens as the node can’t register your break manoeuvre if it isn’t reaching the server.
  • You approach a planet fast in a fleet and want to suicide burn in the last second. You connection cuts out. Everyone else decelerates tough. You only drift a little from the fleet and don’t crash.

This does connect ships to each other and makes them influence each other. This the main purpose, but a side effect.

I don’t know if this would be too costly, computing resource wise, but I just wanted to share this.

2 Likes
2

Wouldn’t it make sense for the nodes to effectively represent, or be defined by, spheres of influence? So the star is the central node, the planets are nodes relative to the star, and the moons are nodes relative to their associated planet, and so on.

Forgive my ignorance, maybe I got lost in reading the post, but how exactly does this node system address networking issues? It sounds more like a way for the game to determine where to render each object.

3

Flavien has previously implemented such a system and he gives a bit of detail in this forum post:

1 Like
4

I think he means that instead of having the servers say object A is in position (X1, Y1, Z1) and so on, the servers say node A is in position (X, Y, Z), object A is in position (X+X2, Y+Y2, Z+Z2), object B is in position (X+X3, Y+Y3, Z+Z3) and so on. That way the nodes are already moving in a way the client can predict more easily (for example, every object in the node should feel more or less the same gravity acceleration meaning the client and server can calculate gravity acceleration for the node instead of for each client) and the relative positions given can also have much more accuracy, also making them easier to predict. The fact that only your node needs to be constantly updated, while other nodes don’t need to be updated as often also means the bandwidth needed per player is decreased.

Of course, that is making some assumptions about what the problem is and how the networking part of the game is handled. We don’t know what the I-Novae team have tried and what the real problems they need to overcome to implement something like this are.

5

It is. The trick is in the fact that it ensures that objects are rendered such that two ships that are flying along at 1,000km/s across a system at a distance of 100m look like they’re flying along at that speed while keeping that spacing.

The problem comes from internet lag. Consider two ships trying the above maneuver. Each of the player’s computers is updating the player’s ship location locally. So each player sees his own ship absolutely in real time. It’s perfect. But it takes perhaps 100ms for each player’s ship location to be sent to the other player through the server. If we assume a reliable connection and uniform lag, when the two ships are supposed to be sitting side by side while moving at 1,000km/s, they’ll actually each see the other guy 1,000km*100ms behind. That’s 100km of error. With variable lag, each player will see the other’s ship bouncing all over the place. They certainly won’t be side by side where they belong.

Now let’s say that we use @Lomsor’s node technique. The two ships are in the same node because they’re so close to each other. The node is moving at 1,000km/s, but the ships themselves are each considered to be stationary relative to the node (a speed of 0km/s). Lag introduces 0km/s*100ms or 0m of error. They are absolutely rock steady relative to each other. If they start flying around relative to each other, then they might build up 100m/s of velocity relative to the node. With a 100ms delay, that’s only 10m of error per update. That’s standard internet game jitter, and can be smoothed out using interpolation techniques.

The node that they’re in is being updated by the server to each client and, relative to everything else in the game world, it jumps around by 1,000km/s*100ms. That’s still 100km of error, but the two guys in the node are chained to it, so as it hops around they don’t see the effect. Their most important reference point is the other ship. Other ships far away will be in other nodes, and the two player node will be bouncing around by 100km per update. But the other ships are so far away that the 100km of error won’t generate more than a pixel or two of jitter and it’s all good.

Now go back through all that and try to have two ships flying along at 100,000km/s. Or 10,000,000km/s. So long as they stay near each other, the node technique allows them to fly together at any speed. WIthout it, the error just gets larger and larger.

1 Like
6

Yeah forgot about that. I added a paragraph for that:

Edit: JB posted a good explanation just before me. Thanks. :thumbsup:

Thanks @Crayfish for linking that post. I know all of this is complex and I don’t want to trivialize or disrespect, just want to discuss it:

Maybe if it’s designed as a single optional module that could be switched on and off instead of a intrinsic part of the positioning and movement system, it could be less troublesome. That way it would be as much distanced from the rest of the game systems as possible.

All (relevant) absolute Positions and Vectors
:arrow_down_small:
Node System Translator/Adjuster/Corrector
:arrow_down_small:
New absolute Positions and Vectors

What it does after all is modify the positions to work better with big jumps in a network environment. Influencing the movement of entities that are close to each other. Bypass it in off-line mode or if something broke, during development, when testing new features, static objects etc… Maybe even make it a server config.
There is little reason to bring relative positioning into the rest of the game code. Having it modify the absolute values could be much cleaner and problematic behind the scenes magic.

I got something like this in mind (just a mock up of course):
For every entity …

  1. Check if it is assigned to a node, check if it’s inside a node, assign that node, else new node

For every node …

  1. Check if node is empty, remove
  2. Check if node is inside another node, merge nodes (transfer entities/delete node)
  3. Re-Centre/Move node in centre of entities <- this is probably not going to work like this

For every entity (or entity in node) …

  1. Calculate relative position to node
  2. Compare relative position to last saved version(s)
  3. Modify/Influence absolute position by using above comparison
  4. Save new position relative to the node.
  5. Add Vector to node Vector (fancy multipliers go here)

For every entity (or entity in node) …

  1. Modify/Influence absolute entity vector by using the node vector

Output new absolute position and vector. The code handling the actual movement doesn’t need to change.

When doing the “fuzzy” border thing, there would be more steps needed of course.

I already see loads of fallacies in the above mockup, I think Flavien and JB have done much more efficient,nice and feature rich implementations of that tough.

Now I confused myself.

Doing it that way tough looses the further possibilities this system could bring. Like rendering far away nodes on the HUD instead of single entities. Instead of “Battleships 1,2,3 / Figheter 30-50” you could just display “Fleet 5” as the node system already calculated them being in close proximity.

7

@Lomsor, note that the warp prototype implements all this stuff (including the node merge and split stuff). I can only assume that Flavien is hesitant to dive into this because he has so much existing code. Retrofitting fundamental assumptions is always a mess (e.g. 32-bit to 64-bit). I found that if I had such a system as a starting assumption, everything else worked just fine. Direct interaction (e.g. combat) operated at the relative coordinate level. Indirect interaction (e.g. sensors) operated at the absolute coordinate level.

The node stuff shouldn’t ever bubble up to the player level. It’s just an implementation detail. Calling a node “Fleet 5” would be inappropriate because what a player considers to be a fleet may not have anything to do with the contents of a node. So don’t implement node naming. Just give the players enough information to intuitively understand what’s going on. If they have a display of ships that is static enough to let them label a group of ships, then let them do that regardless of how they’re organized at the node level.

1 Like
8

Maybe implementing a heartbeat could work. Furthermore, I would try to go for some high QoS tech like part of VoIP (RTP).

9

My question is this, why is nobody doing 100-200 people FPS battles (battle as in able to see and shoot each other) if this is possible and a few guys on the forum can come up with a somewhat trivial solution?

Moving the Battlescape is an additional issue, it will add additional overhead from the static solution.

10

This doesn’t solve 100-200 people battles. There would be at least a network timing diagram in there if it were. :stuck_out_tongue:
It solves the problem of higher error at higher speed which isn’t a problem with networking in itself but with the nature of using coordinates to update a position.

I’m looking forward to see I-Novae do what they promised. They porbably will not tell us how they did it. But it will be cool.

Why didn’t someone else do it yet. Probably because it isn’t that easy, yes. Or because: “People want small FPS” … jada jada. … Maybe it would have been just too crowded and only the I-Novae engine would allow for enough space. (Probably not)

1 Like
11

Many things add overhead. It’s a question of bang for the buck. After all, there’s been a bit of overhead for procedural planets - but we want those, so we accept the overhead. I, for one, very much want to see running fights and fleet operations…

The prototype doesn’t appear to integrate warp movement into the combat system so we have no idea where they plan on going in that area. I recall a couple gameplay videos where somebody had an opportunity to interact with another player, but the other player was in warp so they just ignored them.

1 Like