Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Sandepande
Aug 19, 2018

chadbear posted:

The Quanta simulation now lives in a closed system on a server farm upstate

Oh, I bet all those economies and NPCs and faction politics and operas on Mars it gets to simulate are a blast.

Adbot
ADBOT LOVES YOU

Fil5000
Jun 23, 2003

HOLD ON GUYS I'M POSTING ABOUT INTERNET ROBOTS
Is server meshing just servers talking to each other?

FishMcCool
Apr 9, 2021

lolcats are still funny
Fallen Rib
Tony Z has uploaded himself to the quanta, so for now he lives in a closed system, but once server meshing is in, he'll be able to give tech talks live from Pyro.

trucutru
Jul 9, 2003

by Fluffdaddy

Fil5000 posted:

Is server meshing just servers talking to each other?

It's servers able to collaborate to share the server load. The idea is that if there are too many players in Orgrimmar and the server cannot handle it you just run an extra server and transfer some of that load to it.

FishMcCool
Apr 9, 2021

lolcats are still funny
Fallen Rib
Server Meshing is what happened when Crobear realised server load wasn't actually solved simply by asking AWS to run more servers.

So since Amazon is unable to do it, CIG is inventing a technology never done before and will revolutionise cloud computing when they release. Google, Amazon and Microsoft will then be fighting each other to be the first to license the new tech. Just like they will be licensing high precision numbers, ternary bits, river tech and hotdogs.

Rotten Red Rod
Mar 5, 2002

I'm by no means a computer expert, but wouldn't servers talking to each other also increase server load since, you know, that's data too?

Fil5000
Jun 23, 2003

HOLD ON GUYS I'M POSTING ABOUT INTERNET ROBOTS

trucutru posted:

It's servers able to collaborate to share the server load. The idea is that if there are too many players in Orgrimmar and the server cannot handle it you just run an extra server and transfer some of that load to it.

FishMcCool posted:

Server Meshing is what happened when Crobear realised server load wasn't actually solved simply by asking AWS to run more servers.

So since Amazon is unable to do it, CIG is inventing a technology never done before and will revolutionise cloud computing when they release. Google, Amazon and Microsoft will then be fighting each other to be the first to license the new tech. Just like they will be licensing high precision numbers, ternary bits, river tech and hotdogs.

Rotten Red Rod posted:

I'm by no means a computer expert, but wouldn't servers talking to each other also increase server load since, you know, that's data too?

So it's load balancing but for N servers instead of for a fixed number?

Tippis
Mar 21, 2008

It's yet another day in the wasteland.

Fil5000 posted:

So it's load balancing but for N servers instead of for a fixed number?

Worse. It's assumed load balancing based on the CRobber wish that 50 clients + 50 clients = 51 clients. Rather than, you know, 100 (+ overhead).

TheDeadlyShoe
Feb 14, 2014

In the citcon demo for server meshing what happened was a guy showed that items in the database could move on the fly from being assigned from server 1 to server 2 (wow!!!!!) and they could spin down servers that weren't 'in view' then spin them back up. Also being able to shut down the servers and reboot without disconnecting clients, with the servers loading up from the database. That at least is in theory progress from the status quo.

Why is this dubious? Well, they kicked a ball across the room, moving it from server 1 to server 2, showing that the ball moving servers in the database, and noting that server 2 was now 'authoritative'. Wait, you might ask. Isn't player 1 still connected to server 1? How do they get updates on the ball? Good fuckin question! Either server 1 has to continue simulating the ball, occasionally asking server 2 what the 'true state' of the ball is, or player 1 has to connect to both server 1 and server 2 at the same time. Doesn't that sound like it might get a bit hosed and or very expensive? It sure does!

Nancy
Nov 23, 2005



Young Orc
I've been out of the loop on SC but I really enjoyed the trailer for SQ42, especially the part where they talk about how advanced the enemy AI is over two enemies slowly sidestepping back & forth out of cover right in front of the player. Also excited for the hyper advanced new physics technology reimplemented from Half-Life 2.

I wonder if the multi-minute "dictating an email" scenes are going to be skippable or not.

TheDeadlyShoe
Feb 14, 2014

Nancy posted:

I wonder if the multi-minute "dictating an email" scenes are going to be skippable or not.

Look, it worked for freespace

Torquemada
Oct 21, 2010

Drei Gläser
Knowing nothing about computers, I can imagine micro scenarios where parts of this bullshit make sense, but my brain revolts when I try to translate it to a larger scale.

Scenario one: Ted is in a pirate bar on Pyrex or whatever, and the meeting he's at turns out to be a trap. Fortunately, his buddy Bill is in geosynchronous orbit in an Idris. Ted runs out of the bar yelling on comms for help, and Bill drops a kinetic energy weapon on it, killing all the bad guys. Ted gets in his snub fighter, docks with the Idris, and Bill and Ted fly off into the sunset.

My extremely limited understanding is that the Idris and the bar are two separate entities in this case? A bar has a ton of npcs (and a Turing-capable bartender) and a billion bits of physicalised poo poo like clothes, glasses, food plates, windows, lights, pipes, bottles and whatnot. Likewise an Idris is full of physicalised crap as well as a bunch of npcs.

It makes sense to my brain that these two things be kept apart, because Ted doesn't need the Idris information in the bar, and Bill doesn't need very much of the bar information apart from its location.

As soon as you add more people, say a big space battle or large scale gunfight, the complexity of the information climbs exponentially, since every thing needs to interact with every other thing. I can't see how roping stuff off into separated areas has any effect on the total amount of information that needs to be processed? I obviously don't understand game development.

Thoatse
Feb 29, 2016

Lol said the scorpion, lmao
https://i.imgur.com/UlqNrjz.mp4

Fil5000
Jun 23, 2003

HOLD ON GUYS I'M POSTING ABOUT INTERNET ROBOTS

Tippis posted:

Worse. It's assumed load balancing based on the CRobber wish that 50 clients + 50 clients = 51 clients. Rather than, you know, 100 (+ overhead).



Thank you for this, I now understand why this would be revolutionary and why it is currently not actually happening (nor is it likely to).

Torquemada posted:

Knowing nothing about computers, I can imagine micro scenarios where parts of this bullshit make sense, but my brain revolts when I try to translate it to a larger scale.

Scenario one: Ted is in a pirate bar on Pyrex or whatever, and the meeting he's at turns out to be a trap. Fortunately, his buddy Bill is in geosynchronous orbit in an Idris. Ted runs out of the bar yelling on comms for help, and Bill drops a kinetic energy weapon on it, killing all the bad guys. Ted gets in his snub fighter, docks with the Idris, and Bill and Ted fly off into the sunset.

My extremely limited understanding is that the Idris and the bar are two separate entities in this case? A bar has a ton of npcs (and a Turing-capable bartender) and a billion bits of physicalised poo poo like clothes, glasses, food plates, windows, lights, pipes, bottles and whatnot. Likewise an Idris is full of physicalised crap as well as a bunch of npcs.

It makes sense to my brain that these two things be kept apart, because Ted doesn't need the Idris information in the bar, and Bill doesn't need very much of the bar information apart from its location.

As soon as you add more people, say a big space battle or large scale gunfight, the complexity of the information climbs exponentially, since every thing needs to interact with every other thing. I can't see how roping stuff off into separated areas has any effect on the total amount of information that needs to be processed? I obviously don't understand game development.

I guess the idea is you can do all the computing in seperate spaces and then just communicate the results to the other linked spaces. Like, you don't need to know what set of physics variables combined to make spaceship A change location by x y and z, you just need to know that's where it is now. Except you kind of DO need to know how it got there so it doesn't just teleport around on another player's screen, so you need to then build some extrapolation into the client as well I guess. Maybe? I dunno, I have always understood networking stuff to be some of the most complicated poo poo you can do with computers and tried to avoid it.

Tippis
Mar 21, 2008

It's yet another day in the wasteland.

The scenario as envisioned by CI¬G and the citizens is this:

You have a grandiose space battle with 5 Idrises, each with 50 people on board. Obviously, a single server can't handle all 250 players + 5 super-customised ships at once, so let's mesh'em-up! One server each for the idrises, only dealing with 50 people — easy peasy — and one server dealing with the space combat — also easy.

This conceptually (and even practically) works.

…except…

…then you start extrapolating what this means for the players involved, and the reasons why you even bother with the exercise to begin with.
The pilots must see the combat they're engaging in. They must therefore be present in the space combat server as well, in parallel, and anything that happens to them in one place must happen to them in the other. Conversely, the ships themselves must obviously be present in their respective shards as well as in the space combat, so that when they take hits, this is reflected inside the ship so people can run around and extinguish fires and change fuses and use repair guns and so on

And this holds true for gunners shooting into that battle, and anyone looking out the window — and why would you even bother if you can't even look out the window as see the space battle? So suddenly, the situation has shifted: 5 servers dealing with 50 players + 5 super-customised idrises each; 1 server dealing with the same super-customised idrises plus, oh let's say, 50 pilots, gunners, windowlickers, all of which needs to be duplicated (or sextuplicated) everywhere instantly, in real-time. We started out with 250 players and 5 ships not fitting into one server; we now have 300 players and 30 ships that need to be juggled by 6 servers… unless we actually want to see those other players, and not just the ships, when we look out of the window. After all, we're supposed to be able to fire from one meshed server across another and hit a player into a third. So all those players at the windows need to present in all servers. So… 5× 50+50 player + 5 ships for the internals; 5 ships + 50 players for the space combat; a total of 550 player and 30 ship instances to juggle.

But wait! Wasn't the appeal that you could seamlessly move from one ship to another and do boarding action with inevitable consequences? And that server meshing was supposed to make that possible? Well…

Two crews decide to board eachother, and everyone jumps out into the space combat. It must now deal with 5 ships, 30 crew still in their ships, 100 people floating in space shooting at each other, and of course, those 30 crew looking out at that mess must now get the information about those players. The situation is that each ship server has to deal with: 5 ships (2 of which are just floating, admittedly), 50 crew onboard, 100 crew outside the window. 750 player instances and 30 ship instances in total over 6 six servers, most of which are just copies of each other and need to be synced everywhere. We can't spin down the empty ships because the whole point is that they're about to be boarded any second now…

To effect the dream outcome of using server meshing to overcome the limits of a single server, we are rapidly approaching a scenario where we have 6 servers, each of which has to deal with the very situation we deemed impossible and which required the meshing to happen to begin with. We've increased the workload by 500% to arrive at the same place where we started, with nothing gained (other than at the Amazon billing department).


The only way for server meshing to work is to remove the very scenario it is meant to enable: sorry, you are not allowed to exit the ship or even look out the window — instance is full. Pool is closed. Keep repair-gunning that fuse box.

Tippis fucked around with this message at 16:52 on Oct 26, 2023

Blue On Blue
Nov 14, 2012

my understanding is that meshing will just mean you will see what you already see in the game at high pop , except all the time

you'll leave a room and the 'world' will be melting in front of you, or you'll step into a black hole and fall through into another dimension

all because your connection hiccupped a bit, the server is overloaded, nothing is streaming fast enough, and the back end can't keep up with what the player is trying to do

Popete
Oct 6, 2009

This will make sure you don't suggest to the KDz
That he should grow greens instead of crushing on MCs

Grimey Drawer
How did Dual Universe implement their version of server meshing and make it work? I've never played it but it sounds like they weer able to get some pretty large player counts together at the same time. I assume it is tracking a lot less information than Star Citizen wants too.

Trilobite
Aug 15, 2001

Fil5000 posted:

I dunno, I have always understood networking stuff to be some of the most complicated poo poo you can do with computers and tried to avoid it.

I guess that's the genius of a Legendary Game Developer like Crobbers: he knows that networking is actually easy, you simply fire any so-called "expert" who tells you what you're proposing is impossible, and yell at whoever's left to just GET IT DONE. Maybe wave your hands around at them if you think they need a hint about how it should work.

Tippis
Mar 21, 2008

It's yet another day in the wasteland.

Popete posted:

How did Dual Universe implement their version of server meshing and make it work? I've never played it but it sounds like they weer able to get some pretty large player counts together at the same time. I assume it is tracking a lot less information than Star Citizen wants too.

By intelligently and massively cutting down on what needs to be transferred from one instance to the next and not duplicating stuff all over the place. Oh, and having controllably sized chunks.

TheDeadlyShoe
Feb 14, 2014

Popete posted:

How did Dual Universe implement their version of server meshing and make it work? I've never played it but it sounds like they weer able to get some pretty large player counts together at the same time. I assume it is tracking a lot less information than Star Citizen wants too.

DU, like most MMOs, used a very low tick rate and didn't operate like an FPS. Star Citizen is trying to have responsive FPS gameplay at MMO scale which why it keeps making GBS threads the bed. Many tricks that MMOs use - like long delays on player inputs to give servers and netcode time to look smooth - don't work nearly as well for the sort of game SC wants to be.


The only game I know of that remotely achieves the sort of thing Star Citizen is going for is Starbase, which ate dirt for other reasons. Even so, it had no NPCs whatsoever and still tended to choke with too many players in one area.

trucutru
Jul 9, 2003

by Fluffdaddy

Fil5000 posted:

So it's load balancing but for N servers instead of for a fixed number?

It's dynamic adaptative load balancing for N servers in 3D space with an extra coordination layer. In other words: scalability hell.

trucutru
Jul 9, 2003

by Fluffdaddy

TheDeadlyShoe posted:


Why is this dubious? Well, they kicked a ball across the room, moving it from server 1 to server 2, showing that the ball moving servers in the database, and noting that server 2 was now 'authoritative'. Wait, you might ask. Isn't player 1 still connected to server 1? How do they get updates on the ball? Good fuckin question! Either server 1 has to continue simulating the ball, occasionally asking server 2 what the 'true state' of the ball is, or player 1 has to connect to both server 1 and server 2 at the same time. Doesn't that sound like it might get a bit hosed and or very expensive? It sure does!

This is fairly basic Area of Interest stuff: Each server has an Interest Manager (IM) that, among other things, keeps track of objects (by keeping a proxy) that are up to a certain distance away from its borders. It's not particularly complicated, and there was plenty of research about this for games in the 2010s but the results are always the same: too much extra complexity for too little benefit, it's much better to design/optimize your game so that you don't need meshed servers to handle it.

Shazback
Jan 26, 2013
in truth though server meshing is peak SC: it's never been clearly explained so you can dream it's anything you want it to be, and when the disappointment of reality shows, it's "tier 0", or only partially implemented because another tech is missing, or it works well in the secret Dev build, or you're a FUDster and it was always intended to be a minor thing in the grand scheme

Cutedge
Mar 13, 2006

How can we lose so much more than we had before

Tippis posted:

The scenario as envisioned by CI¬G and the citizens is this:

You have a grandiose space battle with 5 Idrises, each with 50 people on board. Obviously, a single server can't handle all 250 players + 5 super-customised ships at once, so let's mesh'em-up! One server each for the idrises, only dealing with 50 people — easy peasy — and one server dealing with the space combat — also easy.

This conceptually (and even practically) works.

…except…

…then you start extrapolating what this means for the players involved, and the reasons why you even bother with the exercise to begin with.
The pilots must see the combat they're engaging in. They must therefore be present in the space combat server as well, in parallel, and anything that happens to them in one place must happen to them in the other. Conversely, the ships themselves must obviously be present in their respective shards as well as in the space combat, so that when they take hits, this is reflected inside the ship so people can run around and extinguish fires and change fuses and use repair guns and so on

And this holds true for gunners shooting into that battle, and anyone looking out the window — and why would you even bother if you can't even look out the window as see the space battle? So suddenly, the situation has shifted: 5 servers dealing with 50 players + 5 super-customised idrises each; 1 server dealing with the same super-customised idrises plus, oh let's say, 50 pilots, gunners, windowlickers, all of which needs to be duplicated (or sextuplicated) everywhere instantly, in real-time. We started out with 250 players and 5 ships not fitting into one server; we now have 300 players and 30 ships that need to be juggled by 6 servers… unless we actually want to see those other players, and not just the ships, when we look out of the window. After all, we're supposed to be able to fire from one meshed server across another and hit a player into a third. So all those players at the windows need to present in all servers. So… 5× 50+50 player + 5 ships for the internals; 5 ships + 50 players for the space combat; a total of 550 player and 30 ship instances to juggle.

But wait! Wasn't the appeal that you could seamlessly move from one ship to another and do boarding action with inevitable consequences? And that server meshing was supposed to make that possible? Well…

Two crews decide to board eachother, and everyone jumps out into the space combat. It must now deal with 5 ships, 30 crew still in their ships, 100 people floating in space shooting at each other, and of course, those 30 crew looking out at that mess must now get the information about those players. The situation is that each ship server has to deal with: 5 ships (2 of which are just floating, admittedly), 50 crew onboard, 100 crew outside the window. 750 player instances and 30 ship instances in total over 6 six servers, most of which are just copies of each other and need to be synced everywhere. We can't spin down the empty ships because the whole point is that they're about to be boarded any second now…

To effect the dream outcome of using server meshing to overcome the limits of a single server, we are rapidly approaching a scenario where we have 6 servers, each of which has to deal with the very situation we deemed impossible and which required the meshing to happen to begin with. We've increased the workload by 500% to arrive at the same place where we started, with nothing gained (other than at the Amazon billing department).


The only way for server meshing to work is to remove the very scenario it is meant to enable: sorry, you are not allowed to exit the ship or even look out the window — instance is full. Pool is closed. Keep repair-gunning that fuse box.

But what about how every ballistic weapon has to fully simulate pushing the bullets into the chamber and do a physics simulation for the gunpowder going off, which server does that?

Also how is the server going to keep track of all the spent casings that fall to ground (or float around in space, whatever) because I plan to use a holocutter to careful carve little sayings into each one. That's fully tracked right?

Shazback posted:

in truth though server meshing is peak SC: it's never been clearly explained so you can dream it's anything you want it to be, and when the disappointment of reality shows, it's "tier 0", or only partially implemented because another tech is missing, or it works well in the secret Dev build, or you're a FUDster and it was always intended to be a minor thing in the grand scheme

Everyone knows that Server Meshing (tm) didn't work because their graph database provider lied to them, you drat refundian.

Jonny Shiloh
Mar 7, 2019
You 'orrible little man

FishMcCool posted:

Tony Z has uploaded himself to the quanta, so for now he lives in a closed system, but once server meshing is in, he'll be able to give tech talks live from Pyro.



He's finally zzzzzz'ed himself into the metaverse.

Blue On Blue
Nov 14, 2012

im sorry

Tippis
Mar 21, 2008

It's yet another day in the wasteland.


Let's be honest, you're really not. :colbert:

JugbandDude
Jul 19, 2016

Remember when you were young, you shone like the sun

Shine on you crazy diamond!
I find it funny that all of these features and engine improvements will be ready in the next 12 months, but in the same ppt presentation they were showing plenty of concept art for those features. A bunch of that stuff looked like it was put together one month before the conference.

Conveniently, 12 months give them another citcon to kick the can down the road again

Combat and gameplay were so janky overall, character animations were glitchy and amateurish. Overall it ranged from looking like dogshit to merely ok.

The immersion animations and bobbing head are still pointless and make me queasy quickly.

Finally, a small gripe from me: why does every ballistic weapon have tracer bullets in the magazine? I’m not a military person, but it feels very inefficient. If you want a light show, just make everything fire pew pew lasers

There’s nothing about this whole demo that makes me want to play either game

Sankis
Mar 8, 2004

But I remember the fella who told me. Big lad. Arms as thick as oak trees, a stunning collection of scars, nice eye patch. A REAL therapist he was. Er wait. Maybe it was rapist?


JugbandDude posted:

I find it funny that all of these features and engine improvements will be ready in the next 12 months, but in the same ppt presentation they were showing plenty of concept art for those features. A bunch of that stuff looked like it was put together one month before the conference.

Conveniently, 12 months give them another citcon to kick the can down the road again

Combat and gameplay were so janky overall, character animations were glitchy and amateurish. Overall it ranged from looking like dogshit to merely ok.

The immersion animations and bobbing head are still pointless and make me queasy quickly.

Finally, a small gripe from me: why does every ballistic weapon have tracer bullets in the magazine? I’m not a military person, but it feels very inefficient. If you want a light show, just make everything fire pew pew lasers

There’s nothing about this whole demo that makes me want to play either game

you don't get it. the npcs chose tracer rounds simply because they're so smart that they know they're being observed, thanks to the bartender 3.0 tech

The Oldest Man
Jul 28, 2003

trucutru posted:

This is fairly basic Area of Interest stuff: Each server has an Interest Manager (IM) that, among other things, keeps track of objects (by keeping a proxy) that are up to a certain distance away from its borders. It's not particularly complicated, and there was plenty of research about this for games in the 2010s but the results are always the same: too much extra complexity for too little benefit, it's much better to design/optimize your game so that you don't need meshed servers to handle it.

This kind of thing can work pretty good if you draw boxes around the gameplay so that there are lines across which you only need limited info like players can look out the window of their ship1 and see/shoot at ship 2, but not the players on ship2 and vice versa. Explosions happening inside ship1 are generated based on some cheap algorithm that consumes some simplified events happening in the [ship1 + ship2] space combat instance (like ship1 took a point of damage to hull) rather than based on physics sim events getting piped up from ship2 to ship1+ship2 and down from ship1+2 to ship1. A little "cheating" like that makes the pipes in between boxes much cheaper and keeps everything nice and snappy inside each box. You just have to hide the seams between boxes with the gameplay so that players don't notice or care.

These clowns' fundamental proposition is that all of that is BAD CHEATING though so you aren't REALLY doing it RIGHT unless you can throw an empty drink can over your shoulder from the pilot's chair, have it bounce off a wall, fly out an an open airlock, and clock a guy in the head who is doing EVA hull repairs on the other ship to deal physics-based collision damage and the whole thing is simulated with no abstraction of events at any point. At that point, you're basically just fooling yourself that adding more boxes and and more hops between boxes is somehow going to make the whole system performant while it's busy eating its own foot.

Trilobite
Aug 15, 2001

The Oldest Man posted:

These clowns' fundamental proposition is that all of that is BAD CHEATING though so you aren't REALLY doing it RIGHT unless you can throw an empty drink can over your shoulder from the pilot's chair, have it bounce off a wall, fly out an an open airlock, and clock a guy in the head who is doing EVA hull repairs on the other ship to deal physics-based collision damage and the whole thing is simulated with no abstraction of events at any point. At that point, you're basically just fooling yourself that adding more boxes and and more hops between boxes is somehow going to make the whole system performant while it's busy eating its own foot.

I sometimes wonder if they started with "full simulation, no cheating" as a (presumed) goal, or if it's just what they've ended up talking about after realizing that they never made any actual loving decisions about what their game was going to be and what it wasn't going to be.

If you knew you were making a game where you wanted dozens of players manning a big ship and having WW2-style naval battles in space (aka Famous Idea Guy Chris Roberts's Only Idea), you probably would have sat down and thought about what that game needed, what it didn't, and developed the game accordingly. But if you just had "WW2 battleships in SPAAAAAACE" as one scrawled note in the corner of a whiteboard along with "Anodyne Space Stripmalls" and "Star Wars" and "most realistic bootlaces and snoopy caps ever" and "Underwater??? (Avatar?)" and "sandbox" and whatever other trash some thumb-headed fool babbled when you put a camera in front of him, I could see how you might decide that your main talking point should be how accurate your fire simulation or argon levels are going to be, because gently caress it, at least you can bash something that looks like that together and pretend that making it fit into a game is someone else's job.

AlternateAccount
Apr 25, 2005
FYGM

Trilobite posted:

I sometimes wonder if they started with "full simulation, no cheating" as a (presumed) goal, or if it's just what they've ended up talking about after realizing that they never made any actual loving decisions about what their game was going to be and what it wasn't going to be.

"Cheating" it is legitimately a shitload more difficult and requires vastly more intelligence.

Renfield
Feb 29, 2008
Going by the way they do FPS player camera, cheating is a lot easier.

Chris decreed that there wouldn't be separate models for 1st and 3rd person, and the player camera would be in the players' models head.
When they did this, it caused large amounts of head-bob when the model moved which made people nauseous.
The solution was to study how birds hold their heads steady and implement a smoothing algorithm on the bob-ing camera output.

https://www.youtube.com/watch?v=_7GG0y8Jmcs&t=724s

Jack the Lad
Jan 20, 2009

Feed the Pubs

Renfield posted:

Going by the way they do FPS player camera, cheating is a lot easier.

Chris decreed that there wouldn't be separate models for 1st and 3rd person, and the player camera would be in the players' models head.
When they did this, it caused large amounts of head-bob when the model moved which made people nauseous.
The solution was to study how birds hold their heads steady and implement a smoothing algorithm on the bob-ing camera output.

https://www.youtube.com/watch?v=_7GG0y8Jmcs&t=724s

This was actually very smart use of backer funds because the bird research can also be used to make the procedural birds even more realistic.

Colostomy Bag
Jan 11, 2016

:lesnick: C-Bangin' it :lesnick:

Trilobite posted:

I guess that's the genius of a Legendary Game Developer like Crobbers: he knows that networking is actually easy, you simply fire any so-called "expert" who tells you what you're proposing is impossible, and yell at whoever's left to just GET IT DONE. Maybe wave your hands around at them if you think they need a hint about how it should work.

You just layer on the packets.

trucutru
Jul 9, 2003

by Fluffdaddy

The Oldest Man posted:

is somehow going to make the whole system performant while it's busy eating its own foot.

Yeah, it ain't happening.


The Oldest Man posted:

This kind of thing can work pretty good if you draw boxes around the gameplay so that there are lines across which you only need limited info like players can look out the window of their ship1 and see/shoot at ship 2, but not the players on ship2 and vice versa. Explosions happening inside ship1 are generated based on some cheap algorithm that consumes some simplified events happening in the [ship1 + ship2] space combat instance (like ship1 took a point of damage to hull) rather than based on physics sim events getting piped up from ship2 to ship1+ship2 and down from ship1+2 to ship1. A little "cheating" like that makes the pipes in between boxes much cheaper and keeps everything nice and snappy inside each box. You just have to hide the seams between boxes with the gameplay so that players don't notice or care.


You can give different priorities/types to different events and have the Interest Management mechanism throttle their updates depending on a variety of factors but, at the end, the load increase per extra player gets out of hand real fast.

But even if somehow, magically, the servers were able to handle the network load without an issue the coordination overhead required for consistency will totally destroy any hope of using server meshing for a FPS. CIG says that they have an (i believe they call it) object streaming server and it is that, not the servers themselves, what has actual authority over the state of the game objects so hey! I have this ship (which happens to be in another server) in my crosshairs and I decide to shoot at it and they are like "gently caress, nah you dont't". So server 1, server 2 (and maybe server 3, who knows) the players on them that are close enough to see the fireworks, and the streaming server have to send a billion messages between themselves to coordinate who the gently caress hit what while having good enough latency for a FPS dogfight. Good luck!

trucutru fucked around with this message at 13:59 on Oct 27, 2023

Shazback
Jan 26, 2013
youre all going to have so much egg on your face when they layer in the code! microsoft would kill for this tech and people will finally like me and my daughter will stop calling me a sad nerd who got scammed

Pixelate
Jan 6, 2018

"You win by having fun"
So the demo parped a bit...

quote:

There's a 'green authority' pico in the purple server.

https://www.youtube.com/watch?v=6jIaH_0ylCw&t=22s

quote:

* On the red server view a 'green' Pico gets shot into the streamed-out purple server (and falls down into the abyss).
* On the green server view it doesn't move at all.
* Another player then shoots the unmoved green Pico into the wall. On the green server this is fine.
* On the red server it teleports out of the abyss back to its original location so it can get shot into the wall.

https://www.youtube.com/watch?v=3UstOWL_oes

Fidelitious
Apr 17, 2018

MY BIRTH CRY WILL BE THE SOUND OF EVERY WALLET ON THIS PLANET OPENING IN UNISON.

Tippis posted:

The scenario as envisioned by CI¬G and the citizens is this:

You have a grandiose space battle with 5 Idrises, each with 50 people on board. Obviously, a single server can't handle all 250 players + 5 super-customised ships at once, so let's mesh'em-up! One server each for the idrises, only dealing with 50 people — easy peasy — and one server dealing with the space combat — also easy.

This conceptually (and even practically) works.

…except…

…then you start extrapolating what this means for the players involved, and the reasons why you even bother with the exercise to begin with.
The pilots must see the combat they're engaging in. They must therefore be present in the space combat server as well, in parallel, and anything that happens to them in one place must happen to them in the other. Conversely, the ships themselves must obviously be present in their respective shards as well as in the space combat, so that when they take hits, this is reflected inside the ship so people can run around and extinguish fires and change fuses and use repair guns and so on

And this holds true for gunners shooting into that battle, and anyone looking out the window — and why would you even bother if you can't even look out the window as see the space battle? So suddenly, the situation has shifted: 5 servers dealing with 50 players + 5 super-customised idrises each; 1 server dealing with the same super-customised idrises plus, oh let's say, 50 pilots, gunners, windowlickers, all of which needs to be duplicated (or sextuplicated) everywhere instantly, in real-time. We started out with 250 players and 5 ships not fitting into one server; we now have 300 players and 30 ships that need to be juggled by 6 servers… unless we actually want to see those other players, and not just the ships, when we look out of the window. After all, we're supposed to be able to fire from one meshed server across another and hit a player into a third. So all those players at the windows need to present in all servers. So… 5× 50+50 player + 5 ships for the internals; 5 ships + 50 players for the space combat; a total of 550 player and 30 ship instances to juggle.

But wait! Wasn't the appeal that you could seamlessly move from one ship to another and do boarding action with inevitable consequences? And that server meshing was supposed to make that possible? Well…

Two crews decide to board eachother, and everyone jumps out into the space combat. It must now deal with 5 ships, 30 crew still in their ships, 100 people floating in space shooting at each other, and of course, those 30 crew looking out at that mess must now get the information about those players. The situation is that each ship server has to deal with: 5 ships (2 of which are just floating, admittedly), 50 crew onboard, 100 crew outside the window. 750 player instances and 30 ship instances in total over 6 six servers, most of which are just copies of each other and need to be synced everywhere. We can't spin down the empty ships because the whole point is that they're about to be boarded any second now…

To effect the dream outcome of using server meshing to overcome the limits of a single server, we are rapidly approaching a scenario where we have 6 servers, each of which has to deal with the very situation we deemed impossible and which required the meshing to happen to begin with. We've increased the workload by 500% to arrive at the same place where we started, with nothing gained (other than at the Amazon billing department).


The only way for server meshing to work is to remove the very scenario it is meant to enable: sorry, you are not allowed to exit the ship or even look out the window — instance is full. Pool is closed. Keep repair-gunning that fuse box.

This is what confused me about the whole thing. Server meshing doesn't magically teleport the data you need around, in the end data still has to end up at each client.
The separate servers for different areas is fine when the areas they're handling are far enough apart that there are basically zero interactions between them, but once things are in interactable range you absolutely must have them on the same server or you're duplicating a bunch of communication and adding latency for no benefit. The intelligent scaling down of how much data is being sent between clients (full physics data for explosion vs. "this thing blew up") can still be done on the same server so no need for meshing there.

Dynamic servers is fine for your basic 'zones' where they can scale based on population or whatever, but there's a reason Eve uses TiDi for huge battles. And SC can't use that in a real-time FPS shooter context.

I guess Chris thinks he can defeat the laws of physics.

Adbot
ADBOT LOVES YOU

Blue On Blue
Nov 14, 2012

Fidelitious posted:

This is what confused me about the whole thing. Server meshing doesn't magically teleport the data you need around, in the end data still has to end up at each client.
The separate servers for different areas is fine when the areas they're handling are far enough apart that there are basically zero interactions between them, but once things are in interactable range you absolutely must have them on the same server or you're duplicating a bunch of communication and adding latency for no benefit. The intelligent scaling down of how much data is being sent between clients (full physics data for explosion vs. "this thing blew up") can still be done on the same server so no need for meshing there.

Dynamic servers is fine for your basic 'zones' where they can scale based on population or whatever, but there's a reason Eve uses TiDi for huge battles. And SC can't use that in a real-time FPS shooter context.

I guess Chris thinks he can defeat the laws of physics.


as evidenced by his chat with lord british on how you can swim in space

yes,

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply