Jump to content
NQ-Nyzaltar

DevBlog: A single-shard continuous universe: one world, no boundaries.

Recommended Posts

(Posted Friday 26th of September 2014 on the DevBlog)

 

virtual_world-small.jpg

 

Dual Universe is what we call a single-shard continuous universe. What does it mean? Basically, it means that there is only one world, one reality, shared between every player, and where people are free to move and gather as they see fit. It is what you would naturally expect from a persistent virtual world if you could forget about all the technical challenges that usually come in the way to implement such an idea (which are all very good reasons as to why you haven't seen it in a game yet). To better understand where we stand, and what we have in mind (and currently in testing) to solve the underlying issues, let's have first a look at the more usual ways MMOs are dealing with virtual worlds' sharding.

The core issue that every MMO game is facing is to handle the problem of having 'n' players moving around and seeing each other. In the most basic implementation, this leads to n position/orientation updates several times per second, each of which has to be broadcast to n other players watching each other. This is a total of n*n updates, and it grows very fast with even small values of n, like 100 or 1000. The result is a saturation of bandwidth, CPU and globally a practical limit around a few thousands individual players.

The simplest solution used by most MMOs is to limit the number of concurrent players to a hard ceiling. When the number of concurrent players exceeds this limit, they are either queued or another copy of the virtual reality is created where new players are redirected. This is called multi-sharding, and it has many variants. The simplest one divides the world into zones and players are free to move from one zone to the other. When a zone is full, a new instance of this zone is created, and inter-instance visibility is not possible. Players are never living in the same place at the same time. Examples of games following this pattern are D&D Online, LOTR, StarTrek Online or Neverwinter. World of Warcraft has an evolved version of this model : you have a global zone for everyone (a "continent"), and the instance duplication model is limited to selected areas called "dungeons". Players enter these dungeons in limited batches and new versions of the dungeons are constantly spawned for new entrants. Each dungeon is attributed a set of servers that can handle many 5-players, 10-players or 25-players groups.

A more sophisticated approach is illustrated with Eve Online, where there is only one reality, shared by all players, but divided into small zones centered on solar systems. Each zone has a max number of players allowed in it (with a queue when there is an overload), but no instance is ever created. There are no parallel worlds around, and all players can experience the same reality, influence each other and basically do things that matter because it affects everyone. This is a huge difference in terms of gameplay compared to WoW-like traditional models, a shift from the “theme park” model to the “sandbox” model. One example of interaction that applies to all participants across the cluster is market exchanges. No matter in what zone you are, if you have enough skills to do so, you can see other people's market orders and interact with them. While being a single shard universe, Eve is however not a continuous shard: each zone, or solar system, is limited to a few thousands players capable to physically interact with each other.

This simplified model would not be possible in Dual Universe, because we have very large planets, that will (hopefully!) host hundreds of thousands of players, and you cannot segment the planet into arbitrary zones. Think about a very large capital city, you could have a lot of people packed into a relatively small area, impossible to predict in advance. A planet therefore must be split into different servers, because the n*n limit is still there, but you cannot simply physically cluster these servers according to geographical boundaries (like solar systems in Eve).

The approach we have developed is based on the idea of subdividing zones according to their population density, in a recursive way. If only 5 people are roaming the surface of a remote lonely planet, it will most likely be handled by one single server. Come thousands of visitors spread on the surface and the initial area will automatically divide itself. Player clients are dynamically reallocated to the new servers in charge of their area. This process can repeat itself up to areas as small as 8 meters large. The interaction between different areas is handled with a complex cluster-wide synchronization mechanism, and an actor-based model that we might talk about in another post.

The other crucial part of this algorithm is that we have designed a method that is efficient to guarantee that the further a player is from another one, the less frequent the updates of position will be between them. When two players are close to each other, they will be updated very frequently and see each other with a great level of fluidity. However, when players are far away, there will be some delay in movement (because interpolation needs several updates to proceed), but they will still see each other in a visually convincing way.

The prototype is working, but we need to make much more testing of the current implementation to have hard results to show in terms of the max number of concurrent players. So far, it's looking pretty good, and should allow us to provide a continuous, single-shard universe, where you are totally free to move around without instances or zone limits. If you have a few hundreds of thousands of friends, don't hesitate to invite them to join our future beta testing! ;)

JC Baillie,
Project Lead

Share this post


Link to post
Share on other sites
Darirol:

(Posted Tuesday 15th of November 2014 on the DevBlog)

 

Doesn't that mean that for every “server split” your synchronization mechanism requires more and more cpu?

Doesn't this put a limit again on how many people you can handle?

 

Novaquark Team:

(Posted Tuesday 3rd of December 2014 on the DevBlog)

 

Yes and no, because the number of splits is limited (logarithmicaly) by the number of players available to generate the splits.

All in all, this cost remains approximately linear (well, in our model at least!)

Share this post


Link to post
Share on other sites

This feature is what is most appealing about the dual universe design to me.. all in one world... not "instances" as in some RPGs. Great stuff.

Share this post


Link to post
Share on other sites

In my opinion, the single shard concept is the best as it will bring a sense of belonging to the entire community playing the game.

 

Think of it as planet Earth and human history.

 

As this world becomes alive, the events and stories that will eventually unfold will bring this sense of permanence which makes the virtual worlds sometimes so close to real life.

Share this post


Link to post
Share on other sites

(Posted Friday 26th of September 2014 on the DevBlog)

The other crucial part of this algorithm is that we have designed a method that is efficient to guarantee that the further a player is from another one, the less frequent the updates of position will be between them. When two players are close to each other, they will be updated very frequently and see each other with a great level of fluidity. However, when players are far away, there will be some delay in movement (because interpolation needs several updates to proceed), but they will still see each other in a visually convincing way.

 

 

What does this mean for long range snipeing/ bombarding of player bases ect.

 

I read through the whole thing and it all makes perfect sense, but the quote i've linked makes me think that there is going to be an issue with long range attacks/maneuvers.

 

As a player that likes to bombard people and snipe them from a distance and then go and claim my bounty from their cold dea.... from the place they died, this makes me slightly worried when in populated areas that accuracy long range will not really be possible and that it pushes people to fight closer.

 

What if we had a battle station that has a thousand people on board being attacked by long range warships, would we be able to accurately counter attack or would the less populated warships have the advantage due to distance and population ?

Share this post


Link to post
Share on other sites

Communication is a key part of community, but I don't believe position and damage states are.

 

I certainly want to be able to chat with my friend 3 systems away, but my client has no need to know my buddies coordinates or state of health.

 

At some point there needs to be a horizon, where position and damage state packets aren't sent at all.

 

Updates based upon proximity to the player makes a lot of sense. 

 

Sniping DOES bring up a question.  Consider this scenario:

 

A sniper is sitting on the edge of a large furball.  He wouldn't be able to see everyone in the furball, but he can pick out a handful of enemies to target.  He fires and destroys the target.

 

Now look at the scenario from the targets point of view.  He's in the middle of a HUGE battle, where he sees everyone in the furball.  Due to the size of the battle, his "Radius" is much smaller due to the density of the battle, so he isn't even aware that the sniper has him in his cross hairs.  As he's looking around to make sure nobody is on his six, he's sniped from someone he can't even see.

 

Will this be an issue?  And IS it even an issue, considering the first player is a sniper?

 

How will this effect combat?  Will everyone sit back and snipe?  What are the counter measures?

Share this post


Link to post
Share on other sites

As a player that likes to bombard people and snipe them from a distance and then go and claim my bounty from their cold dea.... from the place they died, this makes me slightly worried when in populated areas that accuracy long range will not really be possible and that it pushes people to fight closer.

 

My guess is, hit detection is performed client side, and checked for validity at the server before transmitting a hit to both the attacker and victim.

 

The client will be able to extrapolate enough information from the updates to estimate a target's course.

 

My guess is that in a large battle, the ships that are closest to you will behave fairly accurately, whereas ships on the outskirts will likely have a rubberbanding issue.

 

However, consider this.  In CoD, a player bouncing around by 10 feet is a problem.  In DU, that cruiser that is 5 kilometers away can bounce 10 feet and not even be noticable.

Share this post


Link to post
Share on other sites

I main concern is the performance that the game will have during these large gatherings. Either it be a local trading hub or battle in space if FPS is very low and choppy, like Eve Online gets and Space Engineers. I'm guessing this is a concern for the developers and at this stage we don't know yet. 

Share this post


Link to post
Share on other sites

I main concern is the performance that the game will have during these large gatherings. Either it be a local trading hub or battle in space if FPS is very low and choppy, like Eve Online gets and Space Engineers. I'm guessing this is a concern for the developers and at this stage we don't know yet. 

 

The approach we have developed is based on the idea of subdividing zones according to their population density, in a recursive way. If only 5 people are roaming the surface of a remote lonely planet, it will most likely be handled by one single server. Come thousands of visitors spread on the surface and the initial area will automatically divide itself. Player clients are dynamically reallocated to the new servers in charge of their area. This process can repeat itself up to areas as small as 8 meters large. The interaction between different areas is handled with a complex cluster-wide synchronization mechanism, and an actor-based model that we might talk about in another post.

 

The other crucial part of this algorithm is that we have designed a method that is efficient to guarantee that the further a player is from another one, the less frequent the updates of position will be between them. When two players are close to each other, they will be updated very frequently and see each other with a great level of fluidity. However, when players are far away, there will be some delay in movement (because interpolation needs several updates to proceed), but they will still see each other in a visually convincing way.

 

 

At large gatherings with a high population density, more server computing power is going to be allocated to that region than say, an empty planet like Tattooine, so it should all balance out without much choppiness or slowdowns.

Share this post


Link to post
Share on other sites

The approach we have developed is based on the idea of subdividing zones according to their population density, in a recursive way. If only 5 people are roaming the surface of a remote lonely planet, it will most likely be handled by one single server. Come thousands of visitors spread on the surface and the initial area will automatically divide itself. Player clients are dynamically reallocated to the new servers in charge of their area. This process can repeat itself up to areas as small as 8 meters large. The interaction between different areas is handled with a complex cluster-wide synchronization mechanism, and an actor-based model that we might talk about in another post.

 

The other crucial part of this algorithm is that we have designed a method that is efficient to guarantee that the further a player is from another one, the less frequent the updates of position will be between them. When two players are close to each other, they will be updated very frequently and see each other with a great level of fluidity. However, when players are far away, there will be some delay in movement (because interpolation needs several updates to proceed), but they will still see each other in a visually convincing way.

 

 

At large gatherings with a high population density, more server computing power is going to be allocated to that region than say, an empty planet like Tattooine, so it should all balance out without much choppiness or slowdowns.

I read and understand the concept, in practice would be the test. Performance issues are always the point of Wow this game is awesome or damnit I'm getting 2FPS with all of these players around, kinda thing. I'm sure it all looks good on paper but it's reality I'm looking at. The main point here is saying it works and it actually working is two different things and it's one of my main concerns and I'm sure the community's as well.

Share this post


Link to post
Share on other sites

I don't believe that person to person combat has been heavily discussed.

 

In some probing of Nyzaltar, some time ago, he proclaimed the game will feature targeting mechanics over fps style. So at the very least you wont be expected to dodge bullets with reaction times.

 

What can be said of it then. I think they will prioritize data between players that are engaged in combat, nearby combatants second, nearby non combatants third, far away combatants fourth, environmental fauna and building fifth, miscellaneous character movement sixth, ships and other far away renders last.

If they have a highly specified manager it should feel smooth enough. after all how many people will you be in combat with at any given time.

 

I assume they could slow time a bit, or even if you were in some kind of massive 500 V 500 battle, with a proper scale and or screen effects, they might be able to make it seem like adrenaline, you only focus on the people your attacking or being attacked by inside of a radius which is just slightly larger than the farthest reaching weapon, and using the list from before, updates from each tier are dilated and de-prioritized from lowest priority to highest.

With a focus on maintaining player locations, their skill queue, and chat. while actions outside of your immediate sphere are slown, and very far away ignored.

 

Hopefully the effect would be that at the very least the immediate people you are in combat with maintains an acceptable level of playability.

 

I cant say for sure, but planetside 2 feels like the server is about to blow when 600 players are fighting on any given continent, or a 200v200v200 fight i know they use population limiters now, per faction once they achieve over 150 or more players if i remember correctly.

 

edit: a similar theory could be applied to space / ship combat with spheres of relevant information, but also possibly by tonnage, if you are aboard say a cruiser, then it will prioritize player's aboard the ship 1 (i.e you or anyone thats boarding the ship), ships inside a small sphere around you 2 ( to prevent collisions and warn of boarders), ships with similar tonnage 3, ships with large weapons capable of the most alpha damage against you 4, and then all smaller ships 5.

Share this post


Link to post
Share on other sites

 

If they have a highly specified manager it should feel smooth enough. after all how many people will you be in combat with at any given time.

 

erm... Everyone? I like to be the little go between defiling the masses, so i'll probably make lots and lots of enemies..

 

But, yeah, your post has some interesting ideas and gives some insight to how things might work, I hope you are correct about the prioritizing players 'in combat' before players out of combat, then my worries about distance might not be to bad, if i can get into combat with someone then any distance shouldn't be a problem if we're the update priority..

Share this post


Link to post
Share on other sites

In some probing of Nyzaltar, some time ago, he proclaimed the game will feature targeting mechanics over fps style. So at the very least you wont be expected to dodge bullets with reaction times.

 

 

This explains a LOT. 

 

From the previous "sniper" scenario, with hit detection I hadn't considered the following:

 

Long range targets may rubberband, due to the network mechanics.  Hit detection would need to be verified by the server, which is required for protection from cheating.  When two players are at close range, the server would need to have a stringent hit detection, and when they are at much longer ranges, the server requirements would need to "loosen up" to allow for rubberbanding.  It's certainly doable, but much more complicated.

 

The problem of hit detection is resolved with targeting.

Share this post


Link to post
Share on other sites

 

Darirol:
(Posted Tuesday 15th of November 2014 on the DevBlog)
 
Doesn't that mean that for every “server split” your synchronization mechanism requires more and more cpu?
Doesn't this put a limit again on how many people you can handle?
 
Novaquark Team:
(Posted Tuesday 3rd of December 2014 on the DevBlog)
 
Yes and no, because the number of splits is limited (logarithmicaly) by the number of players available to generate the splits.
All in all, this cost remains approximately linear (well, in our model at least!)

 

 

Just watch your playerbase at some point deliberately crashing your entire server structure by most of them condensing into a single space. Believe me on this one, you might think it would be impossible to organize but Eve Online had NPC structures that were not "indestructible" per se, but they could just as well be considered so because of their insanely inflated defensive stats. One of those was broken by a large group of players in protest. 4chan is also very well known for trolling as much as possible. You would probably want with your instances a limitation of people that can enter and use invisible walls until the server structure is ready and/or to avoid to much condensing.

Share this post


Link to post
Share on other sites

I know as a 13 year Eve Online veteran as well as someone that has sunk over 2500 hours into space engineers, this title has attracted my interest since I caught it at E3. I look forward to watching it progress, and participating in early alpha and beta when they become available. 

 

Meanwhile keep up the good work - and keep us all up to date on whats going on.

Share this post


Link to post
Share on other sites

what if... player collision was turned on so that only a certain number of players can physically fit in an area...  As more players exist around a player the radius around them which allows player movement updates could contract... and at it's smallest at maximum occupancy... there's still a lot of players displayed.  Hopefully so many and physically spaced out enough so you can't see past them to where characters who's movement isn't updated would be.

 

Naturally there would need to be a method to prevent blocking access simply by people standing there...  In FFXI they did it by having you get hung up on another character but if you continues pushing... you'd pass through.  A similar system could be used to allow passage through crowded areas.

Share this post


Link to post
Share on other sites

Having hundreds of thousands of people on one planet, it's difficult to imagine the scale in a game, I think we will need a load of social hubs for 'bank sitting' and trading in general, if there aren't enough it could be like trying to meet up with people at a concert.

 

A few Mos Eisleys.

Share this post


Link to post
Share on other sites

It should be more of a hard "push" when players are standing too close rather than proper collisions but you should still be able to push through a crowd if you needed to get out.

That's why I carry my Crowd-Plower tool with me at all times.

 

 

It's a 12-Gage.

Share this post


Link to post
Share on other sites

What does this mean for long range snipeing/ bombarding of player bases ect.

 

I read through the whole thing and it all makes perfect sense, but the quote i've linked makes me think that there is going to be an issue with long range attacks/maneuvers.

 

As a player that likes to bombard people and snipe them from a distance and then go and claim my bounty from their cold dea.... from the place they died, this makes me slightly worried when in populated areas that accuracy long range will not really be possible and that it pushes people to fight closer.

 

What if we had a battle station that has a thousand people on board being attacked by long range warships, would we be able to accurately counter attack or would the less populated warships have the advantage due to distance and population ?

I can't see this being a huge problem in a tab targeting system. All NQ needs too do is send an immediate real time up date both ways when you're looking at some one through a binocular or sniper-scope or the space ship equivalent. It gives you a 1 to 1 fast link but only if you remain in the snipers sight picture. Most games do this anyway.

Getting sniped from an invisible sniper on the far off hill is the whole point of sniping. It's the real world point of being a sniper. If you are exposed to probable sniper positions you are dead! That was one of the things drilled into me in army boot camp.

Dig a trench with your nanoformer fast or die fast!

 

If you are in a brawl with 10 guys on the ground and 10 snipers show up now the server has 20 people half of them close half of the far but it is still only 20 people interacting, a number most systems can handle. NQ and DU is making the actors or players the focus of the servers architecture. The world is not divided spatially into zones but logically into players and interactions with the world geometry layered in under them. 

 

If you are in a brawl with 10 guys on the ground and 10 snipers show lag will be very short term problem. Someones going to die fast any way. 

This also means that if someone in your trench is watching the hill with binoculars (or a battlefield para-scope if he's smart) he can counter the snipers with a mortar barrage. Rock, paper, scissors. 

 

In many games the guy looking though the binocular, para-scope, sniper scope, etc suffers tunnel vision, a real world problem, NQ can simulate this easily too by just slowing down a tiny bit all the other update flows. Some games cut them off altogether. Stabbing the sniper in the back with a knife is a real world thing. This is why few snipers actually work alone. They have someone watching their back. In some cases the entire commando team is just there to cover the snipers back, spot targets for him, carry his lunch and spare ammo. All for that one critical shot. 

 

(PS I almost failed boot camp. lol.)

Share this post


Link to post
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

×