Jump to content

No Construct vs. Construct at Launch a Good Thing


Spartan_raidrhater

Recommended Posts

Well, from what I have learned this is new tech that they have been working on for years before they even started working on the game itself. I doubt any of us would know too much about it except what they tell us at this point. I have faith. They don't seem like liars to me, so until they prove that they actually are, I will choose to believe it is possible. Somebody is going to figure it out some time, so why not these guys?

Exactly the technology they developed they call "dynamic area splitting". There is a video showcasing the tech.

 

And once more I'm going to link the wikipedia entry for JC the creative developer for people who are unfamiliar with him. https://en.m.wikipedia.org/wiki/Jean-Christophe_Baillie

As you can see he is a well known scientist. With quite a few accomplishments to his name.

 

JC said that the mmo genre needs to be disrupted. And he developed the tech to do just that. I'm very confident that his claims will work out. At least on the tech side.

 

As for CvC not being in at launch, if NQ is able to deliver on the free expansions as they envision, I'm sure DU will grow over time. Like it should be. Like it used to be and that is a good thing.

Link to comment
Share on other sites

Exactly the technology they developed they call "dynamic area splitting". There is a video showcasing the tech.

 

And once more I'm going to link the wikipedia entry for JC the creative developer for people who are unfamiliar with him. https://en.m.wikipedia.org/wiki/Jean-Christophe_Baillie

As you can see he is a well known scientist. With quite a few accomplishments to his name.

 

JC said that the mmo genre needs to be disrupted. And he developed the tech to do just that. I'm very confident that his claims will work out. At least on the tech side.

 

As for CvC not being in at launch, if NQ is able to deliver on the free expansions as they envision, I'm sure DU will grow over time. Like it should be. Like it used to be and that is a good thing.

By no means guys am I opposed to being proven wrong....I actually would prefer that I was.  I have just heard all of these claims for way to long...maybe I am a bit pessimistic.  

 

There is no doubt that if JC pulls this off it will be revolutionary in terms of gaming.  It will be MAJOR...maybe as big of an advancement as VR is going to be.  I'm actually kind of giddy now thinking about the ramifications of him pulling this off for the gaming industry.  

 

Best of luck JC!  

Link to comment
Share on other sites

Well, from what I have learned this is new tech that they have been working on for years before they even started working on the game itself.  I doubt any of us would know too much about it except what they tell us at this point.  I have faith.  They don't seem like liars to me, so until they prove that they actually are, I will choose to believe it is possible.  Somebody is going to figure it out some time, so why not these guys?

https://www.dualthegame.com/technology#cssc

 

"This involves what we call "Dynamic Space Splitting", server nodes are assigned to regions that are more densely populated, and these change the frequency of updates of remote entities to maintain a fluid experience for nearby entities."

 

As a database software engineer, this is what I'm getting from this:

 

When there's sufficient density, players will have a "primary" node assigned to them for rapid updates for them and anyone near them, so if you have 20,000 people in a city, everyone in that city will be on a single rapidly updating database instance.  That data will be replicated to all other nodes, but those updates will be less frequent than the "focus" instance for a given cluster of players.

 

Say that the fleet of 2,000 players on instance ABC123 is jumping into a system where the players are focused on instance XYZ789.  As they pass through the jump point (or their FTL drive brings them into proximity) their client machines will start sending updates to instance XZY789.  The last thing ABC123 hears from them is that they have moved out of that cluster.  

 

After that, ABC123 will still hear about the players in the fleet, but they'll hear about it every 5 minutes as a job replicates all updated data from all nodes on the continuous shard to all other nodes as opposed to updates from the focused clients which happen every 10 milliseconds or so.

 

Presumably there will be a designated failover node for any given node on a different physical server, so one of the non-focus instances is getting updates perhaps every few seconds rather than every 5 minutes.  If the focus node fails, the clients get a blank screen for a few seconds as they reset to the failover server and pick up where they left off.

 

It's a guess but I think it's a fairly educated one.

Link to comment
Share on other sites

Man now I wish I had the 10,000 dollars so I could meet him and have the 1 hr call and stuff with him.  I wanna pick his brain on this.  Has anyone seen any industry papers on this Dynamic Area splitting?  I tried searching and couldn't find anything...but I only searched for a few mins too.  

Link to comment
Share on other sites

Man now I wish I had the 10,000 dollars so I could meet him and have the 1 hr call and stuff with him.  I wanna pick his brain on this.  Has anyone seen any industry papers on this Dynamic Area splitting?  I tried searching and couldn't find anything...but I only searched for a few mins too.  

It's proprietary.  If they can get it working in DU they'll probably make more money from licensing that than they will from the game.

Link to comment
Share on other sites

Consider the w,x,y,z coordinate of each person (w being the quaternion variable for rotation), you would only be able to provide the location of something like 15 clients PER TICK when using a 508 byte packet (the largest IPv4 packet that is guaranteed not to be fragmented).

 

Accounting for 1000 players would require 66 ticks to successfully be transmitted.  And this wouldn't account for dropped packets.  That means that each player position would be updated ONCE a second at 60 ticks/sec.

 

This doesn't account for anything other than positioning packets.  Any other type of packet will add to overhead.

 

To optimize this, JC has already indicated that players closer to you will be tranmitted more frequently, while those far away could update more slowely.  Possibly once every 2-3 seconds.

 

So, what needs to be done is to create a stream of packets.  This stream would look at queues of information and transmit that information according to priority, by filling that 508byte packet with as much information as possible. 

 

So you would have queues setup something like this:

 

Critical -> Transmitted immediately

HighPriority -> After Critical

PositioningClose -> Filling in the remainder of the 508 bytes after HighPriority

PositioningMedium -> Every 5 ticks or some other algorithm

PositioningFar -> every 10 ticks or some other algorithm

LowPriority -> every 60 ticks or some other algorithm

 

Say there are 60 players in PositioningClose, and no Critical or HighPriority "chunks of information". Packets 1, 2, 3, & 4 would be required for all positions to be updated.  If there were no other players, everyone would update approximately 15 times a second.

 

But once you add more players and start adding critical events, that positioning would be updated much less frequently.  That's where "Client Side Prediction" comes in.

 

If this were a shooter, there's no way, that many positions could be updated quick enough to provide a smooth an acurate transition.  But since this is tabbed targeting, it's not a problem.

 

Remember,  the bottleneck is not usually the server side.  It's the clients bandwidth.  Does the client have to acknowledge each packet?  Probably not.  If positioning data is incorrect, or not received it will receive a newly updated packet shortly.  The client just continues to use "client side prediction" to account for the lost packet.  And the server infrastucture "shouldn't" be the problem if it's designed properly.

 

As you can see... The server guy has his work cut out for him.  He could risk larger packets, at the risk of fragmentation.  Or he could use some other solution.  But at the moment, even the high end FPS shooters are only transmitting at 60 ticks/sec. :D

 

(btw.  This analysis is based off of gafferongames.com)

Link to comment
Share on other sites

Man now I wish I had the 10,000 dollars so I could meet him and have the 1 hr call and stuff with him.  I wanna pick his brain on this.  Has anyone seen any industry papers on this Dynamic Area splitting?  I tried searching and couldn't find anything...but I only searched for a few mins too.  

 

Yes, it is very exciting, isn't it? That's why I supported this game.  If they try and fail, so be it.  But I'd rather support the people who are trying to push the boundaries of what can be done instead of the guys who are doing the same-ole, same-ole.  This game fits that bill and I am very excited about what I have learned so far.   Is it a risk?  Sure.  But this team just might be the one that pulls of something new after so many years of the mundane.  I'm keeping my fingers crossed until release :) 

Link to comment
Share on other sites

Oh,

 

And at a certain point, there's NO NEED to transmit player positioning that is "too far away."  I don't care what JC said in the interview.  I have no need of knowing the player positioning of someone in another star system.  You can't see them, and cant interact with them.  Other than text chat or other non critical events, which could still be sent.

 

Unless theres a reason the player needs to know about every online player's positioning (highly doubtful), then it's just a tremendous waste of bandwidth.

 

I am almost certain the server guy will have a cutoff point in order to maximize bandwidth.

Link to comment
Share on other sites

Oh,

 

And at a certain point, there's NO NEED to transmit player positioning that is "too far away."  I don't care what JC said in the interview.  I have no need of knowing the player positioning of someone in another star system.  You can't see them, and cant interact with them.  Other than text chat or other non critical events, which could still be sent.

 

Unless theres a reason the player needs to know about every online player's positioning (highly doubtful), then it's just a tremendous waste of bandwidth.

 

I am almost certain the server guy will have a cutoff point in order to maximize bandwidth.

I agree....but at this point this is essentially the same as instancing.  I am 100% okay with instancing ...anything to improve my frames.  But if I can have 10000 people all at once with good frames and no instancing I obviously prefer this.

Link to comment
Share on other sites

I agree....but at this point this is essentially the same as instancing. I am 100% okay with instancing ...anything to improve my frames. But if I can have 10000 people all at once with good frames and no instancing I obviously prefer this.

No it's not....and not even essentially or similar. Cause in an instanced world you wouldn't be able to fly to players who are 50parsec away....WITHOUT LOADING SCREEN

Link to comment
Share on other sites

At a certain point "Client Side Prediction" will become ineffective.

 

For those that aren't aware,  client side prediction uses a mathematical formula to account for lost packets, and also predict the future position of all players.  It relies upon previous packets to determine their velocity and direction.  And can usually be acurate for a few seconds.  You will see the effects of client side prediciton, when you see "rubber banding". The client predicts the location of the player, and when a new update arrives from a player with a bad connection, their avatar "rubber bands" to the newly updated location.

 

You can think of it like a Hurricane tracking Map.

 

matthew-track.jpg

 

 

 

 

Consider JC's suggestion that players farther away update less frequently.  At some point (10, 20, 30 seconds out) the client side prediction has no chance of providing an acurate prediction.  At that point, there's no need to burden the client OR take up bandwidth with those remote player locations.  At a certain point the data is so old, it will be dropped by the client.

 

Saying this is instancing isn't quite correct.

 

There's no need to recieve data for every shot fired by every player logged into the game.  Just the data from the players that are in your area of influence.  I don't care that PlayerB shot PlayerC, when they're two stargates away from my location. The same goes for their positioning.

 

If all players are able to communicate across the galaxy (or the limitation of their Comms element), then even if you don't know their exact w,x,y,z positioning, you're still on the same "Instance".

 

Once I fly close enough to the other player that client side prediction works, then it makes sense to start transmitting their position to my session.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...