Welcome Guest [Log In] [Register]
Welcome to the Chrome Conflict Developer Forum! ~Admin DJ

Check the active topics here! And the staff list here! ~Alex

You can join us on our Discord server here! ~Spiral

New or Lost? Click here!

Welcome to The Steel Sentinels 2 Development Forum. We hope you enjoy your visit.


You're currently viewing our forum as a guest. This means you are limited to certain areas of the board and there are some features you can't use. If you join our community, you'll be able to access member-only sections, and use many member-only features such as posting replies, sending personal messages, and voting in polls. Registration is simple, fast, and completely free.


Join our community!

Username:   Password:
Add Reply
Working Out The Network Protocol
Topic Started: 9th October 2016 - 02:44 AM (91 Views)
Idratex
Member Avatar
Idratex
The protocol
The model is as follows: the server is authoritative, the client (local copy running on your machine) will mainly function as a view of what the server thinks and as an interface to it.

The server simulates the world at the server tickrate; this involves updating positions of objects, updating sentinels' states (health, weapon reload status, ...), etc(??). You could in theory just set up a world and have it in motion and it would run like clockwork, but then it would not be interactive. So the server receives some sort of inputs from the clients and updates them on what's happening, over the Internet, with all of the wonderful problems that brings...

Let's talk about a single client for the moment, for simplicity. To a first approximation, the client wants a sort of video stream of world snapshots from the server. However, this need not be 60fps. Because our chief concern is physics, it would be fine for a much lower framerate i.e. 20fps, which the client can linearly interpolate between. Meaning that, for example, if the shell was here at the last snapshot, and over there at the next, then right now we'll assume it moved in a straight line between the two points, at constant speed. This might sound crude but it's actually imperceptible (or so I hear, since this is my first time in this area :P) as long as the snapshot rate is high enough and objects aren't moving super fast along non-straight lines; rockets at lightspeed with large curved arcs might look quirky, but I'm not going to worry about that. And this is just for the display on the client; the server tickrate could be higher as necessary to ensure an accurate simulation.

So let's call this 20fps-ish quantity the client tickrate. Ideally, this should be user-adjustable, for bandwidth considerations. I don't see how you could request a higher tickrate than the server, because then you're asking for data it hasn't computed. Conversely: in a way, it should always be possible to request a lower tickrate, because the server is then just skipping frames. Or is it?

Let's say the server tickrate is 40fps and we want 20. That's fine; the server just has to send us every second frame. What if we want 15fps? How many does it skip then? Yep... Perhaps the server will just have to do a first interpolation step, and then pass this to the client as if it were just an ordinary, non-interpolated frame? Which would then be interpolated again by the client? Might not be as bad as it sounds. Maybe there's a better way.

Now, I made the analogy with video frames earlier because that's conceptually what we're dealing with; only in this case, instead of millions of pixels it's (hopefully!) many less positions, orientations, velocities etc. One great thing about video is that most frames are largely similar; characters might move very slightly and maybe the background remains basically the same. So this lets us compress them to save bandwidth. The same can be done for physics simulations; we needn't send the full position, velocity etc of every single object every single frame when:

  • There are objects that are stationary (e.g. the ground terrain, the 'background' if we deal with that as an object)
  • There are objects with a constant speed (e.g. the ship on Lost, plus the enormo-laser beams)
  • There are objects that only move every few seconds, and are stationary otherwise (the ships and rocks in Fleet - although, is this behaviour desired?)
  • Objects are generally expected to move a small distance in a small time step

We can apply various means of compression to this data, but let's not over-engineer. One large initial saving can be gained by using delta compression - that is, only sending that which is different (delta) between one frame and the next. So instead of "at (3.1,4.1), then at (5.9,2.6)" it would be "Initially we're at (3.1,4.1) (full snapshot), then we moved (+2.8,-1.5)". Doesn't seem like much here, but remember that the default assumption is that, if we don't hear about something changing, then it hasn't changed. So automatically, anything stationary will only be present in the very first snapshot (or manually requested "full snapshots" if the client needs it, say they lost connection? more on that stuff later), and will not waste bandwidth during normal gameplay. More generally, anything that appears to have constant position / velocity / whatever at the moment can just be omitted.

Of course, this is only the tip of the iceberg; much can be done in the way of optimising network usage in snapshots. I'm learning much from Gaffer On Games: link

Packet loss
One bad thing about the Internet (specifically, the Internet Protocol IP) is that it makes few guarantees; it is a Best Effort service that will do its best to get your data across the network - but due to congestion, corruption or sorcery, packets can sometimes just not be delivered.

In the case of packet corruption, the packet does arrive at the destination but ended up being altered in transit (or at least, we can't guarantee that it wasn't altered! You need to be paranoid), so we must discard it. However, there is another possibility: sometimes the packet just won't arrive in the first place; no matter how long you wait, it'll never arrive, because the network ate it ;)

The way you deal with this situation is with the concept of timeout. Essentially, you pick an amount of time to wait, decreeing that any packet that does not arrive by then shall be considered missing, assumed dead. In the case where you definitely need the data, you would somehow indicate to the other end that they should try sending it again. This could be via another packet - a Negative Acknowledgement or NACK - which can, in turn, get lost or corrupted! or by sending 'acknowledge' packets (ACKs) for data that you received correctly. With ACKs, you rely on the other end to realise, via their timeout, that you didn't ACK their data. Selection of an appropriate timeout period is important and can be estimated based on factors. (which ones? blah.)

However, sometimes it really doesn't matter that the packet didn't arrive; this is the case in video streaming or Skype conversations for example. The issue is, the packet probably made up only part of the image you're displaying - and, even if you do eventually receive the packet long after timeout, it's pretty useless considering the movie clip is now 0.5 seconds past the point where the packet would have lived.

This situation is similar for our client; there's no point in receiving the packet for 20ms ago ... unless we haven't yet displayed the world as it was 20ms ago!

Let's say we just display each frame as soon as we get it, roughly 20 times per second. That gives us jarring choppy animation. We mustn't assume all players have high-speed internet capable of supporting 60fps of snapshots, and maybe the server doesn't even simulate at that tickrate. So we compromise - we linearly interpolate, as mentioned before, between two snapshots each time we want to display.

However, this means that at any given moment, the display will lag slightly behind the network i.e. we receive the first snapshot, can't do anything with it, then we get the next for +50ms, NOW we can begin displaying. We linearly interpolate between both snapshots - and by the time we reach that +50ms snapshot, hopefully snapshot +100ms has arrived. But even so, we'll still be displaying between +50ms and +100ms even though +100ms is the most recent snapshot! Fortunately for such time intervals this delay isn't too much of a problem ... in other games you even have server-side lag compensation etc ... but there is already delay in SS so let's just live with it :D (maybe they found it too much of a pain to lag compensate, so they made lag part of the official lore?? :P)

--MORE TO COME, INCLUDING ACTUAL PROTOCOL DETAILS--
Offline Profile Quote Post Goto Top
 
Definitely Not Spiral
Member Avatar
Professional Faggot (US Navy Sailor)
This is the system that jagex uses(50 is the number that they use); I know that there is a thread out there with discussion on the concept.

:2cents:
Offline Profile Quote Post Goto Top
 
Blackout
Member Avatar
Community Organizer
This all goes over my head. I'll just stick to Star Wars and bothering Myrm.

I sincerely appreciate these posts though, Idra. Keep it up!
Offline Profile Quote Post Goto Top
 
Idratex
Member Avatar
Idratex
Spiral: do you mean 50 physics snapshots per second, and is this client or server? If there is already a discussion of this then that would obviously be really helpful. Do you mean on these boards, or Funorb?

Also, I should clarify that I say "working out the protocol" to mean "developing the details of the protocol for CC" rather than "studying / reverse-engineering the protocol that SS actually used", although the latter task could help too.
Offline Profile Quote Post Goto Top
 
Definitely Not Spiral
Member Avatar
Professional Faggot (US Navy Sailor)
Idratex
9th October 2016 - 04:07 PM
1. client or server?

2. If there is already a discussion of this then that would obviously be really helpful. Do you mean on these boards, or Funorb?
1. Both

2. It's on the forum, I tried using the search tool, but it was down when i tried. I know pringles had something to do with it though
Offline Profile Quote Post Goto Top
 
Pringles Man
Member Avatar
The Chief Designer of the Ilolan Republic

Posted Image
Offline Profile Quote Post Goto Top
 
Kosmos
No Avatar
Very lazy, such slow, wow.
Plz no implement TCP in UDP.
Offline Profile Quote Post Goto Top
 
1 user reading this topic (1 Guest and 0 Anonymous)
DealsFor.me - The best sales, coupons, and discounts for you
« Previous Topic · Programmers' Hub · Next Topic »
Add Reply