next »

[pspeed]

Those of you who follow Mythruna on Facebook, Twitter, or G+ undoubtedly have already heard a bit about this, but I met a networking milestone last night... finally.

I was able to test full networked physics in a loop-back mode.  All of the major components are now in place and it's a matter of cleaning up and fleshing out the additional features a bit.  Overall, if the protocol doesn't have bugs it's a much tighter networking scheme than I'd even originally imagined.

The next step is to add some fake "connection quality" settings and a simple UI to control them.  This will allow me to test the protocol under conditions like higher latency, 50% packet loss, etc... and vary these settings while the app runs.  That will be the final test of the protocol.  I know it works right when no messages are lost so now I need to test it with lost messages.  It's designed to handle this but the proof is in the pudding, as they say.

To sort of understand what all of this means, I will try to walk through what happens when the physics engine moves an object.

1) Physics engine loops through all objects and adjusts velocity, rotation, position, etc. based on the current state of the objects.  New objects that are contacted are "woken up" and objects that have been still for some period of time are "put to sleep".  The physics engine only considers objects that are awake.

2) The physics engine then notifies the zone manager about all of the objects that have moved or been removed (put to sleep).

3) The zone manager figures out which zones the objects are overlapping and then delivers updates to those zones.

4) Zones collect these updates into a buffer and at the end of a "frame" moves them into a buffered history that holds some number of iterations.  The physics engine operates at a high rate, like 60 frames per second but state is only sent 20 times a second or so.  That's why these two things (the state generation and the state collection) are decoupled.

5) A separate "collector" thread, goes through all of the zones and empties their history... which generally includes three frames of "movement".  This history is then delivered to the zone listeners.

Zone listeners in this case represent the player.  Each player may be watching a different set of zones, usually the zone they are in and the immediately surrounding zones (9 zones total).  The collector thread delivers the 3-frame history of physics state to each player's listener if they are watching that zone.  (Note: remember that an object can be in multiple zones at once if it overlaps.)

6) These player-level zone listeners pack up the state for each object, disambiguating multiple zones... so if they get multiple updates for the same object from different zones then it picks one.

7) These listeners also keep track of which network messages that it knows the client has already received.  It does this so that it can avoid sending redundant information.  If the position, rotation, parent, etc. hasn't changed for some object then a very minimal data block is sent.  Still, the biggest general data block is about 14 bytes per object.  Smallest is about 3 bytes.

8 ) All data blocks for a frame are packed into a message, and may be split across multiple messages if the frame exceeds the configured MTU.  If multiple frames will fit in the same message then they are packed together.

[7 and 8 are the hardest part of the whole protocol and represent a solid two weeks of my life, I think.]

9) In the prototype, I package these data blocks up into an actual read-to-go network message but instead of sending it over the network, I pass it off to code that is pretending to be a network connection.

10) A network message handler gets the message and unpacks it.  This handler represents the real "client".

11) The client sends an ACK message back to the "Server" saying it received the message.

12) The current object delta-baseline is updated to reflect the messages that the server knows that the client has received (ACK-ACK).  Every message from the server to the client includes a list of the ACKs that it's gotten from the client.  In other words, it's sort of acknowledging the acknowledges.  It's mind-warping but necessary.  The client needs to know which baseline they agree on.

13) The deltas from the message are applied to the current objects on the client as part of a sliding window history buffer.

14) The code that handles the visuals has been looping at FPS this whole time interpolating object position between the last known value and the next known value... and now it has new values to interpolate between.

Someday maybe I will make a diagram.

The prototype started out by just strapping the object position directly to the physics engine.  The next tiny milestone was decoupling the frame timings as described in step 14.  Then I implemented zone management and everything looped through that, basically adding a zone listener that talked directly to the buffers mentioned in step 14.  (basically step 5 talked directly to step 14)

...and the most recent huge milestone, of actually looping through the network layer is a pretty big deal as that added all of the other steps.

Sending the messages over an actual network connection is only a formality at this point.  The only thing it will add to the test is unreliability... and I will be testing that in the prototype first.

Running a single process to test is much easier than launching a server, waiting for it to load, and then launching a client... every time I want to test.  Also, I can more readily test specific scenarios as I find issues.

[FutureB]

That sounds great paul :] so will this also change how objects move when we drag them? im just wondering because of the issues i have with moving objects and lag hehe

[Michael]

Paul, you do so much, and we (I) appreciate the hard work you put into it. But for some java beginners, (me) and ones interested, your favor, why not stream yourself coding? there is a website called twitch.tv that does streaming, but i believe you need to get a software yourself to allow streaming.

[pspeed]

That sounds great paul :] so will this also change how objects move when we drag them? im just wondering because of the issues i have with moving objects and lag hehe

It will change.  It may or may not improve lag since it still requires a round trip... but it will be a round trip through UDP instead of TCP.  In theory it could be faster.

I still haven't worked out player dragging an object yet, though.  That's not strictly a networking problem but a physics engine problem so I haven't tackled it yet.

[pspeed]

Paul, you do so much, and we (I) appreciate the hard work you put into it. But for some java beginners, (me) and ones interested, your favor, why not stream yourself coding? there is a website called twitch.tv that does streaming, but i believe you need to get a software yourself to allow streaming.

No.  I cannot predict when I will be productive and coding tends to alternate between note taking and change, run, change, run, change.

When I'm designing, nothing is happening... or certainly nothing that I'd want people to see.   When I'm really going then I'm flipping between files and windows too fast to see what's going on without narration.  And narrating would destroy productivity.

Bottom line: It would slow me down and I already don't have enough time.

[Michael]

I didn't say to narrate.

I would just love to watch you work.
Also: twitch provides it's own software, some free for the broadcast stream.

[pspeed]

I didn't say to narrate.

I would just love to watch you work.
Also: twitch provides it's own software, some free for the broadcast stream.

This is what my desktop looks like:


When I'm actually working, I flip back and forth between tabs and windows so fast it's probably impossible to follow.

At any rate, I don't want people watching over my shoulder.

[G1ZMO]

I can't profess to understanding this Paul but it sounds like a lot of mind bending work, well done

[Michael]

Paul do it

Smartiklez - i need to see an example, but I wouldn't be able to steal code if i wanted xD

[Moonkey]

This still went slightly off topic.

[pspeed]

This still went slightly off topic.

Yeah, but I'm not going to name names.

[BigredRm]

Paul do it

Smartiklez - i need to see an example, but I wouldn't be able to steal code if i wanted xD

*facepalm

[FutureB]

unnatural life just so you know.... twitch.tv is terrible and https://join.me/ is 100% better, iv watched a few people drawing stuff and thats cool watching them draw things and watching how they do it but that is alot diffident to coding so i get why you wouldn't want someone watching and sending messages asking what your doing and slowing your work rate down

[belgariad87]

glad to hear there is progress being made before the holidays, paul. good luck testing!

[Michael]

unnatural life just so you know.... twitch.tv is terrible and https://join.me/ is 100% better, iv watched a few people drawing stuff and thats cool watching them draw things and watching how they do it but that is alot diffident to coding so i get why you wouldn't want someone watching and sending messages asking what your doing and slowing your work rate down

Wow, you just spoiled my hopes