Server tech

[drainedman]

I saw the video showing the basic principle but I'd like to see a more convincing test of some real stress being placed on the system.

How about a fly through a planet with 50k simulated network entities?

[Shynras]

Because 50k simulated entities is a lot and it's very expensive since they'd have to rent them. Btw huge battles doesn't mean high density, people will be spread all over a very big zone so you'll likely not even see and load people very far away. 

[Haunty]

I'd guess you're probably going to have to wait until alpha or beta to see something like that, when they build out their server farm.

[Ripper]

As a reminder,

 

Coordinate update frequency changes depending upon the distance from the player.  I'm also betting that it scales to the number of players in the area, and possibly the players internet bandwidth.

 

What this means is the servers can most likely support those 50,000 players.  Even in  a small area, but your client will most likely see a fraction of those players.  Don't get me wrong.  If your org mates are on the other side of the city, you can always meet up with them.  But, NQ will design their Networking solution to provide fast updates of other players that you will most likely interact with, while providing slower updates (even non-existant) updates of players that are too far away to interact with.

 

What I'd like to see is a mechanic that prioritizes coordinates between players in combat.  They're already planning to prioritize on proximity.  I'd take it one step further to include players who have recently damaged you (within the past minute?), or possibly the current player in your crosshairs.  The crosshairs suggestion may be asking too much because its determined client side and then requested of the servers.

[Lord_Void]

Fifty thousand entities is a lot to try and simulate. They would have to rent a lot of servers just to run the clients, plus the sever-side servers. And really it wouldn't put any more load on the server than the one thousand entity test because of the way the server works. If each server node supports 250 players (let's suppose, I don't know the actual numbers) and you have a 1000 players, you need 4 nodes. If you have 50,000 players you need 200 nodes. It doesn't really matter how the people are distributed (together vs spread across the galaxy) so long as there are enough nodes, and the number of nodes can be easily scaled to match demand.

[Anaximander]

Fifty thousand entities is a lot to try and simulate. They would have to rent a lot of servers just to run the clients, plus the sever-side servers. And really it wouldn't put any more load on the server than the one thousand entity test because of the way the server works. If each server node supports 250 players (let's suppose, I don't know the actual numbers) and you have a 1000 players, you need 4 nodes. If you have 50,000 players you need 200 nodes. It doesn't really matter how the people are distributed (together vs spread across the galaxy) so long as there are enough nodes, and the number of nodes can be easily scaled to match demand.

If my knowledge is not outdated, the rate of NPC hosted on the server to player-client served ratio prformance wise is usualy 1:10, meaning for every 1 player the server emualtes, it forfeits serving 10 players that are clients. This is why NPCs never move in most video games. And yes, if anyone doesn not know, NPCs run from tiher own servers in games like WoW or Everquest - or even the Korean Trash MMORGPs who never would have came up with JC's server tech to begin with. 

 

 

To the OP :

 

 

NQ so far has stated they run tests by hosting 1000 simulated players (moving, running ,etccetera), which means that in an actual scenario where there are little to no NPCs on the server, the number of players this number represents, is 10000.

 

Even if NQ ran the bot-clients on potato settings and with minute scripts and manage to cram 100 avatars running off of one server blade, it means they need 500 servers to run 50000 people, but it means that if there are no bots on the servers, they can host 500000 people one 500 servers. And I am going on a bet here, but I will speculate NQ does not project 500000 people for the Alpha of the game..

So to answer to the OP, NQ, so far, does 1000 simulated players. which is 10000 actual player clients test performance wise on the server) tests, cause that's the scope of players for the Alpha - more or less. When they got the Alpha going, even if only 2000 played the game on the sma,e spot, at the same time, it would mean the server tech is solid and stable - with 2000 documented cases of people on the same spot with cloud-tech providing servers to keep up with the need for processing on a cluster, it means NQ can publish a scientific paper on the subject, let alone prove their concept.

 

And since they got 1000 simulated players in one location so far on their videos (check the January one and pause on the screencap of server performeance), it means that even if you had 50000 people, the concept would be the same.

 

You may ask "but that's not making sense, why didn't others not make the server tech?".

 

Why? Simple, you don't have to invent a new server-tech - or more likely, a way for servers to talk to each other and cluster up dynamically - or innovate the genre, when you try to make the next P2W Piece of Shit Korean Trash MMORPG or the next WoW Clone.

 

 

Hope tihs helped OP.

 

Cheers.

[Lord_Void]

NQ so far has stated they run tests by hosting 1000 simulated players (moving, running ,etccetera), which means that in an actual scenario where there are little to no NPCs on the server, the number of players this number represents, is 10000.

 

 

I think they said that they were running simulated client connections rather than server side NPCs, so to the server itself they were indistinguishable from regular clients. 

[Anaximander]

I think they said that they were running simulated client connections rather than server side NPCs, so to the server itself they were indistinguishable from regular clients. 

Hmm, I think they did say "We got a simulated server enviroment with 1000 simualted players runnign round ,that the team can log in to test different changes in real time"

I mean, I may have read hat wrong. 

 

P.S. : The january Dev Diary I think it's where it was.

 

P.S. 2 :  I knew I was not crazy. On the January update, they did say they simualte the game with hundreds of players, but are increasing the nubmer mroe and more until Alpha.

 

 

https://youtu.be/iUTyiMjjf7w?list=PLA_lhIAGheMGtAygniJs25JDsWgxbfk6V&t=108

[drainedman]

50k bots, all persistent, flying around and taking pot shots at nearby bots. 

Since the claim is being made that the servers can scale up then they should demonstrate this.

10 or so servers should be able to easily accommodate this computation wise.

 

If Ultimate Epic Battle simulator can do 100k+ bots on one machine then computation is no problem 

 

Age of Ascent can do 50k+ network players (supposedly).

[Lord_Void]

Hmm, I think they did say "We got a simulated server enviroment with 1000 simualted players runnign round ,that the team can log in to test different changes in real time"

I mean, I may have read hat wrong. 

 

P.S. : The january Dev Diary I think it's where it was.

 

P.S. 2 :  I knew I was not crazy. On the January update, they did say they simualte the game with hundreds of players, but are increasing the nubmer mroe and more until Alpha.

 

 

https://youtu.be/iUTyiMjjf7w?list=PLA_lhIAGheMGtAygniJs25JDsWgxbfk6V&t=108

 

Hmm, I guess I stand corrected. Although that is for the test server. I was thinking more about the tech demo from earlier. 

 

50k bots, all persistent, flying around and taking pot shots at nearby bots. 

Since the claim is being made that the servers can scale up then they should demonstrate this.

10 or so servers should be able to easily accommodate this computation wise.

 

If Ultimate Epic Battle simulator can do 100k+ bots on one machine then computation is no problem 

 

Age of Ascent can do 50k+ network players (supposedly).

 

I see where you are coming from, but those are two different types of bots. In UEBS, each unit is very simple and most of their actions are handled by a single update routine. This means that it is very easy to have a lot of them with very little processing power. With the DU bots each bot has its own logic and update routines, plus the server has to pipe all of the world and graphics data to each one, plus check for world updates and such. It takes a lot more power for each bot to be run.

 

Now, none of this is to say that the severs can't do 50k players (they most certainly can), all this means is that setting up a test of that magnitude at this time would be a waste of resources and wouldn't prove anything we didn't already know. 

[Anaximander]

50k bots, all persistent, flying around and taking pot shots at nearby bots. 

Since the claim is being made that the servers can scale up then they should demonstrate this.

10 or so servers should be able to easily accommodate this computation wise.

 

If Ultimate Epic Battle simulator can do 100k+ bots on one machine then computation is no problem 

 

Age of Ascent can do 50k+ network players (supposedly).

Age of Ascent has the same logic on scalable, on-demand Cloud-Servers. Problem is, Age of Ascent is a browser-based game. Not quite the same bear to tackle like Dual Universe.

 

As Void pointed, RTS bots run on a "clock". When something runs on a predetermined set of actions and it's not unpredictable (unlike people), the processor on a computer can easily run many of them at once - to the computer, the actions are not unpredictable, it just has a certain line of data to prase, nothing more nothing less, you as te player, just sit back and watch a domino fall. It's why particle effects, like rain, gotten more complex over the years, as programmers had more CPU strength to simulate how a rain-drop would befhave, just in far more ways the processor could predict - with the power of math.

 

However, REAL PEOPLE, are unpredictable, the server can't wait till it has a predetermiend pattern to parse on a clock, as that would turn DU into a turn-based game by default. NQ has to simulate that unpredictability of people. They can't run a 50000 predictable bots test, caues that does nada to provide data on how REAL people would stress the servers.

 

But at least you know about Age of Ascent. Not many people have heard of that little gem.

[drainedman]

Age of Ascent has the same logic on scalable, on-demand Cloud-Servers. Problem is, Age of Ascent is a browser-based game. Not quite the same bear to tackle like Dual Universe.

 

As Void pointed, RTS bots run on a "clock". When something runs on a predetermined set of actions and it's not unpredictable (unlike people), the processor on a computer can easily run many of them at once - to the computer, the actions are not unpredictable, it just has a certain line of data to prase, nothing more nothing less, you as te player, just sit back and watch a domino fall. It's why particle effects, like rain, gotten more complex over the years, as programmers had more CPU strength to simulate how a rain-drop would befhave, just in far more ways the processor could predict - with the power of math.

 

However, REAL PEOPLE, are unpredictable, the server can't wait till it has a predetermiend pattern to parse on a clock, as that would turn DU into a turn-based game by default. NQ has to simulate that unpredictability of people. They can't run a 50000 predictable bots test, caues that does nada to provide data on how REAL people would stress the servers.

 

But at least you know about Age of Ascent. Not many people have heard of that little gem.

 What im saying is 50k bots running simple logic isnt that much you don't need 100s of servers. 

 

You could do some stress tests with the bots doing certain patterns, e.g. 1000 of the 50k bots suddenly and quickly swarming and swamping one location 300 meters radius. And then they all start firing shots at each other. Then they disperse and go to another location. Thats generally the problem in these games is upscaling the processing on demand for highly compact areas and then wide spread areas, maintaining real time responsiveness.

 

As far as Age of Ascent goes...actually I know of a lot of server "technologies" that make this promise. Dual Universe idea is nothing new. I know of a dozen with similar(ish) approaches. So far nothing has actually worked yet.

[drainedman]

FYI this "tech" is pretty similar 

was supposed to be used in Warhammer.

(Actually these guys were pretty arrogant coming from finance background slagging of us "dumb" game network developers, now who looks silly?).

 

https://improbable.io/ also, doesn't work (I have tried it). They brag about scaling to 1000s of servers and yet have the most pathetic demos.

 

I have more examples than this even.

 

Thats not to say that scaling with lots of servers can't be done, it actually has been done a lot in research and with GPUs, but these ideas just doesn't play nice in real world conditions - partly cause people do such random things. 

 

Thats why I'd like to see a little more exploration and explanation into showing the server tech and what its limitations will be.

[Anaximander]

FYI this "tech" is pretty similar 

was supposed to be used in Warhammer.

(Actually these guys were pretty arrogant coming from finance background slagging of us "dumb" game network developers, now who looks silly?).

 

https://improbable.io/ also, doesn't work (I have tried it). They brag about scaling to 1000s of servers and yet have the most pathetic demos.

 

I have more examples than this even.

 

Thats not to say that scaling with lots of servers can't be done, it actually has been done a lot in research and with GPUs, but these ideas just doesn't play nice in real world conditions - partly cause people do such random things. 

 

Thats why I'd like to see a little more exploration and explanation into showing the server tech and what its limitations will be.

Now you are talking.

 

Well, yeah, the very problem with Warhammer and all those games (including Age of Ascent) is that they try to simulate projectile entities, that is the main drawback in performance.  DU opts for a combat with active lock-on, a cross between tab-targeting and action based combat - see TERA Online for a frame of referrence on the cobmat if yo uare unfamiliar. That alone can make the server-side handling much more managable - despite people argueing on its merit as a combat system, it's the best of both world, it can be less strainous on the server by a wide margin and it can be involving, instead of "fire and forget" Tab-target.

 

Thing is, you have to take into account for DU, that it's not a combat oriented game. It's a sandbox game, with BUILDING. Devs have to strain test what would happen on a server if players were to start pumping out edits on a planet all around the clock like crazy.  That's way more harder to emulate in a player-like routine for a simulated player running from the machine itself. And still, when Alpha hits the Devs will probably increase / decrease the rate of how fast a palyer can deploy a voxel-shape or mine, or w/e, in order to calbirate the servers for the task at hand. Combat is still a thing, but llike building it's server-editing at large. Them simulating building takes care of two birds with one stone.

 

And still, that's where tha Alpha comes in. If you seen their tech demo on the server-side of things, they DO explain how it works and show you whart happens on the server-side and in-game. The DevBlogs on it, are even more in detail.

 

I'm with you, I'd like to see a 50000 people stress test, but the devs need to BUILD the tech to that point. They never claimed magic out of their asses. NovaQuark even delayed the game's Alpha, so they would not release a half-assed Alpha, let alone a game and most important, it's an Alpha Test they release, not the actual-not-actual Early Access pece of shit ttlte #2321567843534 on Steam. They NEED to stress test the server with a few people in Alpha, then move to Beta then Open-Beta.

 

If you wonder why NQ would be so "careful" with thier developement and methodical, I suggest you look up on the man behind the Dual Universe project. You'll understand why. JC Baillie is not your run of the mill "indie developer with their head stuck up thier ass and a pride rivalling a million cardinals". He's modest so far about the game, he's not Sean Murray.

[Ripper]

Agree with Twerk on the combat model. Server side hit detection is a resource hog. DU's combat model is closer to "tabbed targeting" that you'd see in an MMORPG. "Active lock on" or I prefer to call it "Reticle Targeting" selects your target only while its in your crosshairs, and then damage is applied like an RPG lightning bolt or fireball.

[Haunty]

 

As far as Age of Ascent goes...actually I know of a lot of server "technologies" that make this promise. Dual Universe idea is nothing new. I know of a dozen with similar(ish) approaches. So far nothing has actually worked yet.

 

Do you know of any other technologies that use the Actor Model in a cloud server farm? I'm interested in finding out more about them.

[Shynras]

50k bots are not different from 50k players, from a testing perspective. If you use the advantages that bots give, like doing the same action or moving in stardardized patterns, the test is not realistic (and that's the goal, to predict a realistic scenario).

 

Other than that, the ones they use are not bots but simulated clients: a bot doesn't need to get updated on other player position and actions, while a simulated client does. If there are 1k clients, each of them receives data from the other 999. If there are 50k, each of them receives data from 49999 other clients. Data transferred consumes bandwith, aka money. Then add the fact, that probably you can't rent all those servers for just a few hours (because the provider doesn't allow that), but for weeks if not months, so in the long term it would be quite expensive.

[Ripper]

Just for clarification:

 

All data to the client is validated and sent FROM the server. No peer-to-peer communications.

 

Also, your client wont have positional data for ALL 50,000 players. Only, players where theres a remote possibility of interacting with.

 

Google and Amazon allow you to rent servers by the minute.

[Anaximander]

Just for clarification:

 

All data to the client is validated and sent FROM the server. No peer-to-peer communications.

 

Also, your client wont have positional data for ALL 50,000 players. Only, players where theres a remote possibility of interacting with.

 

Google and Amazon allow you to rent servers by the minute.

Which is why NQ has stated they negotiate with AWS over the server renting.

[drainedman]

50k bots are not different from 50k players, from a testing perspective. If you use the advantages that bots give, like doing the same action or moving in stardardized patterns, the test is not realistic (and that's the goal, to predict a realistic scenario).

 

Other than that, the ones they use are not bots but simulated clients: a bot doesn't need to get updated on other player position and actions, while a simulated client does. If there are 1k clients, each of them receives data from the other 999. If there are 50k, each of them receives data from 49999 other clients. Data transferred consumes bandwith, aka money. Then add the fact, that probably you can't rent all those servers for just a few hours (because the provider doesn't allow that), but for weeks if not months, so in the long term it would be quite expensive.

 

Yes this is how n-body simulation is usually done with CUDA. Its a cheat but close enough as influence on bodies with other bodies very far away tends to zero.

 

The relationship is linear not quadratic e.g. 50k x n number of neighbours not 50k x 50k. 

[drainedman]

Do you know of any other technologies that use the Actor Model in a cloud server farm? I'm interested in finding out more about them. 

[drainedman]

Do you know of any other technologies that use the Actor Model in a cloud server farm? I'm interested in finding out more about them.

 

The terminology of "actor model"  or "cloud" doesn't really matter. That's smoke and mirrors/hype train stuff.

 

Often when people mention "actor model" with MMO I get suspicious as they tend to come from a background where they don't understand why service model, actors and Erlang don't work. Beware. Databases are comparatively slow and not suitable for games (re the ones mentioned above post).

 

At the end of the day the problem boils down to how to encode a highly dynamic n-body simulation with certain parameters (e.g. every body have lasers and can shot 10kms away). Very well explored using super computers. Super computers usually have a very large bus which allows for great amounts of RAM. So lots of information can be shared very quickly. In theory.

 

As far as real tech goes, most is deprecated (e.g. Shinra for no good reason). However there is still some.

 

http://www.cloudgine.com/ I am told actually works, sort of.

 

Here is one with a similar approach : http://bigworldtech.com/en/technology/bigworld-server/

There was a very solid associated article explaining limitations (can't find), and how to beware of all too common snake oil salesmen.

 

This of course is underpinned by earlier tech that was used in 1990s. Second life etc. It works but with limitations mainly adapting to load is not dynamic enough to be "fun".

 

Theres a bit of academic projects out there if you really dig around (project darkstar, and plenty more).

[ChatterFreeze]

I can wait to see the ram trolls. 

[Anaximander]

I can wait to see the ram trolls. 

I don' t understand what you mean. I downloaded my RAM from HBO's streaming service. I'd suggest people to go for the Extra VRAM package, as it's a steal at 33.99 $, but do not download the extra MHz on the clocks, it's a waste of money.

[devu]

http://bigworldtech.com/en/technology/bigworld-server/

 

Weird.. someone is building top-notch MMO server to introduce efficiency and picks Python? That made me lough . But the good news is if their solution works you can expect it be much faster when C++ comes to play.