well, i bought a pre order for Crowfall, but I'm glad I didnt get one of star citizen....
IMPORTANT: Please keep all replies to my posts about GAMING. Please no negative or backhanded comments directed at me personally. If you are going to post a reply that includes how you feel about me, please don't bother replying & just ignore my post instead. I'm on this forum to talk about GAMING. Thank you.
Personally I don't really care about 'seamless' worlds. It depends on how the instances are used whether I would like it. The OP shows that they will go for instanced (creating new instances when a certain region will become too busy etc, like many MMO's do). But also shows it is still unsure what the max amount of players within one instance will be.
Anyway, what strikes me as odd in this thread, is that some expect that CGI at some point will still switch to seamless. There is no way they will overhaul their networking tech again after they have implemented this ' temporary solution' which they are now working on. Also, I don't know how recent this news is in the OP, but if it is from this year, it is kind of late during development imo.
This to me is annoying, because it is the kind of detail I want to know for sure about a game before I spend money on. Kind of like those EA Steam games where they change their original plans after you buy it.
The OP shows that they will go for instanced (creating new instances when a certain region will become too busy etc, like many MMO's do). But also shows it is still unsure what the max amount of players within one instance will be.
That is incorrect, the setup is not like many MMO's do, quite the opposite, the intended setup is to split areas of space into multiple servers to handle player density, not instances of the same area, instances are more related to regions (EU, NA servers, or multiple per region) that depends on the global population of the game, an actual instance of SC's intended setup would be a game-world with its own server mesh.
Anyway, what strikes me as odd in this thread, is that some expect that CGI at some point will still switch to seamless. There is no way they will overhaul their networking tech again after they have implemented this ' temporary solution' which they are now working on. Also, I don't know how recent this news is in the OP, but if it is from this year, it is kind of late during development imo.
This is also incorrect, what SC has already is by default seamless all within a single-server, there is no "temporary solution" for server transition because there isn't server transition yet and the one to exist is already intended as the server mesh (the described server mesh is not the temporary solution).
OP was misleading about "region-locked", that is just wrong info, what one MMO player understands as region-locked is the type of MMO's that will lock you to play in only NA, or EU, in most cases where you have a character in each that you won't play with it on the other region, being the data not shared.
That is not the case in SC, in the reality of server meshing the region lock is pretty much, you select the server region you play on, and for as long you play on the NA region, you will be on NA servers within that server mesh until you change region again, you will be able to go to a new play session as you do now and play in another server region.
The dev comment means that during a play session on a region you stay on that region, you wouldn't be in-game moving from a server in EU to a server in NA (inter-connects between regions).
The data is global, shared across all of them, not locked per region.
Personally I don't really care about 'seamless' worlds. It depends on how the instances are used whether I would like it. The OP shows that they will go for instanced (creating new instances when a certain region will become too busy etc, like many MMO's do). But also shows it is still unsure what the max amount of players within one instance will be.
Anyway, what strikes me as odd in this thread, is that some expect that CGI at some point will still switch to seamless. There is no way they will overhaul their networking tech again after they have implemented this ' temporary solution' which they are now working on. Also, I don't know how recent this news is in the OP, but if it is from this year, it is kind of late during development imo.
This to me is annoying, because it is the kind of detail I want to know for sure about a game before I spend money on. Kind of like those EA Steam games where they change their original plans after you buy it.
The developer just posted this today so after 6 years they now start with the development of the networking. Something that should be done first in any multiplayer project.
OP was misleading about "region-locked", that is just wrong info, what one MMO player understands as region-locked is the type of MMO's that will lock you to play in only NA, or EU, in most cases where you have a character in each that you won't play with it on the other region, being the data not shared.
That is not the case in SC, in the reality of server meshing the region lock is pretty much, you select the server region you play on, and for as long you play on the NA region, you will be on NA servers within that server mesh until you change region again, you will be able to go to a new play session as you do now and play in another server region.
The dev comment means that during a play session on a region you stay on that region, you wouldn't be in-game moving from a server in EU to a server in NA (inter-connects between regions).
The data is global, shared across all of them, not locked per region.
Also dev comment on that:
I thought we agreed not to keep bashing other people? Discuss the topic not the person, you got that now?
There is nothing misleading if the developer himself says the game will not work across regions. Servers are not connected meshed or anything else. If they are not connected then the data can not be global shared across all of them. I really would like to know why you keep saying the opposite the developer says.
"We won't be connecting servers across server regions (US, EU, etc) in this version."
You also still owe everyone an explanation how you deleted your post.
I thought we agreed not to keep bashing other people? There is nothing misleading if the developer himself says the game will not work across regions. Servers are not connected meshed or anything else. If they are not connected then the data can not be global shared across all of them. I really would like to know why you keep saying the opposite the developer says.
"We won't be connecting servers across server regions (US, EU, etc) in this version."
I'm not bashing you, I'm calling your statement misinformation because it IS.
I even posted the other dev commenting on that bit that backs up the way I was understanding it, servers of several regions are NOT meshed together, that is not a region lock, when you go play in one NA server in one game that openly shares the data globally that you could then go and play your game on the EU server, that is not a region-locked game.
Allow to explain again, not connecting servers across regions in the context of a server mesh means that the server mesh would be only made of servers frome one region and you wouldn't transition to other regions unless you start another play session selecting another region. It is not about stopping you from playing with friends in another region by locking you or your data to one of them.
It's about reading it with its context, you are the only person I've saw who read that and understood it as when the server mesh is added SC will become a region-locked, I wonder why is that...
Don’t take it personally. The fans will spin anything to make it look like this was planned all along or that it’s not as bad as it seems or this was in the expanded vision. Anything that casts SC in a negative light, no matter how small, is misinformation and must be yelled down.
Ahh the usual cheap attacks, I know you don't have arguments to counter my argument when you come with those type of posts excusing and vilifying the other posters.
Feel free to prove me that the server mesh plans did actually change and things are as bad as the poster OP states that what the developer described somehow justifies and means: "From seamless universe MMO to region locked fixed single map arena game with multiple instances".
I have arguments to counter your arguments, and I have many.
But , let's calm down, and .. let's talk about arguments when you'll actually have the game to play.
No. The current "alpha" and pre-made cgi trailers which Robert workers are showing here and there , are not counting as a Game.
Reporter: What's behind Blizzard success, and how do you make your gamers happy? Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
<snip> the intended setup is to split areas of space into multiple servers to handle player density, <snip>
That was / is my understanding. I haven't bothered following the network architecture discussion details.
The concept was showcased by IBM and back then they presented it as "original" - whether it was or not? And contrary to suggestions that the tech would never see the light of day IBM realized it in the late 2000's. Remember IBMs interest - selling servers and software solutions!
Since then of course we have seen a growth in cloud computing and a number of games which run on different - different - mega-server solutions. So things have probably moved on even more.
Anyway the fundamental idea behind what IBM proposed was that instead of a server managing a set number of people a "server" would handle a volume of space. (Most games have a third dimension). And regulate everything in that volume. How big a volume would be dynamically adjusted depending on the population density.
So if everyone on a server congregates starts to congrgate in one place more and more server compute power is brought to bear on that area with those servers handle smaller and smaller volumes. And since the population density elsewhere would be decreasing some other servers will be handling larger and larger volumes.
Various advantages were claimed including the ease of scaling the design to population growth (up to and in excess of 500k back in early 2000s) and decline.
Obviously this type of design creates a different set of messaging requirements. Decisions till have to be made about what secondary servers you have for handling logins, chat etc. etc. And there are different ways all of this can be done.
My understanding of their approach however was not some fanciful, unproven idea.
They still have the challenge of getting it to work of course. Compare what they have today to what was being said they would never have 2 years ago, 1 year ago etc. and progress is being made. Is it fast enough etc. - that is a debate that cn be had.
The title of this thread - as a minimum - is misleading though!
A more interesting observation would be: does this mean they have had a design review and decided what will be in 3.1? For - assuming they are aiming for an end March release and not an end March development cut off - they have c. 5 weeks to go. Allow some time for Evocatti and PTU and ..... a version of 3.1 should be making its way to the launch pad.
That was / is my understanding. I haven't bothered following the network architecture discussion details.
So if everyone on a server congregates starts to congrgate in one place more and more server compute power is brought to bear on that area with those servers handle smaller and smaller volumes. And since the population density elsewhere would be increasing some other servers will be handling larger and larger volumes.
They still have the challenge of getting it to work of course. Compare what they have today to what was being said they would never have 2 years ago, 1 year ago etc. and progress is being made. Is it fast enough etc. - that is a debate that cn be had.
The title of this thread - as a minimum - is misleading though!
A more interesting observation would be: does this mean they have had a design review and decided what will be in 3.1? For - assuming they are aiming for an end March release and not an end March development cut off - they have c. 5 weeks to go. Allow some time for Evocatti and PTU and ..... a version of 3.1 should be making its way to the launch pad.
Scalability is one way to attack the problem, but then in a game like SC or even DU, you have another problem, where the servers could perhaps handle the load, the clients could not, it would turn into a client performance issue, and one way or the other, either enforce caps or extreme optimizations to ever handle high density.
What DU is doing as said ties in many ways to what SC wants to do, so we are to see how this involves and we will see this tech finally get proven on a scale both titles need it to work.
This is not for now, the server mesh stands attm put in Alpha 3.4 (late 2018) if it's not pushed back, what is for 3.1 is aactually network culling.
I have arguments to counter your arguments, and I have many.
Odd, I swear the last time I heard your arguments they ended up on implying I am a delusional person with mental problems. hmmm
Delusional mostly , don't really remember saying you have "mental problems" .
But hey! When someone is waiting 6 years for his dream game , and is just around .. 15% completed 6 years later, with the biggest budged ever for a MMO in the entire history, then .. how should I call you? DFD? (Delusional Faithful Donor)
Reporter: What's behind Blizzard success, and how do you make your gamers happy? Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
Delusional mostly , don't really remember saying you have "mental problems" .
But hey! When someone is waiting 6 years for his dream game , and is just around .. 15% completed 6 years later, with the biggest budged ever for a MMO in the entire history, then .. how should I call you? DFD? (Delusional Faithful Donor)
I'm not waiting for 6 years. You call me delusional, yet I'll say even as I fan I can be more realistic in my arguments than you with your naysaying/trolling, so you'd be more fitting of that label than I am.
Don’t take it personally. The fans will spin anything to make it look like this was planned all along or that it’s not as bad as it seems or this was in the expanded vision. Anything that casts SC in a negative light, no matter how small, is misinformation and must be yelled down.
Don't take it personally but the trolls will spin anything. Anything that casts SC in a negative light no matter how small must be reported and embroidered. See what I did there?
The title is misleading.
As for 20 year old i.e. 1998 technology the OP obviously never played multi-player games back then.
Yep and I’m completely ok with it. I don’t get bent out of shape like some posters here lol
Network bind Culling for 3.1 patch at end of March, baring any problems.
This work aims to help improve performance in multiplayer by cutting
down the number of entities that exist on clients. Entities too far from
a player will be removed from the local client, and when the player
moves or the server otherwise detects new entities entering the player's
range they will be added to the client. Because clients will then only
consider updating entities that are near to them the overall CPU load
will be reduced and performance should improve.
Network Entity Streaming for 3.3 patch at the end of September, baring any problems.
Restructuring how the network code handles entity spawning and binding to allow for asynchronous streaming.
Object Container Streaming for 3.3 patch at the end of September, baring any problems.
At its core, Object Container Streaming allows Star Citizen to create
our Universe. We will no longer be restrained by the physical memory on
your PC and will be able to stream in new environments, locations and
ships seamlessly as you approach. This will also be one of the biggest
wins for increased performance as your graphics memory will no longer be
overloaded.
Parallel Network Jobs for 3.4 patch at the end of December, baring any problems.
Moving packet receive processing into the job system so that the server
can handle a greater number of connections. This system should allow the
game to increase player count per server beyond the limitations of the
current tech.
Lobby Refactor for 3.4 patch at the end of December, baring any problems.
This will lay the groundwork for server migration technology that will
allow us to connect multiple servers and clients in the same game
session. As this task is closely aligned to server meshing, there won't
be an immediate observable benefit to the tech until all server meshing
work is complete.
Server Meshing for 3.4 patch at the end of December, baring any problems.
First iteration of the server meshing technology. With this system,
individual servers would be responsible for different locations within
the solar system. When operational, players and entities should
experience seamless transitions between servers during quantum travel.
Now as far as this tread, response the OP is trying to show as feature loss and game downsizing. Was in an answer to the following question:
Yorokobiy@Yorokobiy
What will be the extent of the first pass on the server meshing planned for 3.4 ?
discussion
February 5th at 05:17 pm
Is the tech gonna be working completely + further improvements or is it gonna be more of a test before the proper tech ?
Network bind Culling for 3.1 patch at end of March, baring any problems.
This work aims to help improve performance in multiplayer by cutting
down the number of entities that exist on clients. Entities too far from
a player will be removed from the local client, and when the player
moves or the server otherwise detects new entities entering the player's
range they will be added to the client. Because clients will then only
consider updating entities that are near to them the overall CPU load
will be reduced and performance should improve.
Network Entity Streaming for 3.3 patch at the end of September, baring any problems.
Restructuring how the network code handles entity spawning and binding to allow for asynchronous streaming.
Object Container Streaming for 3.3 patch at the end of September, baring any problems.
At its core, Object Container Streaming allows Star Citizen to create
our Universe. We will no longer be restrained by the physical memory on
your PC and will be able to stream in new environments, locations and
ships seamlessly as you approach. This will also be one of the biggest
wins for increased performance as your graphics memory will no longer be
overloaded.
Parallel Network Jobs for 3.4 patch at the end of December, baring any problems.
Moving packet receive processing into the job system so that the server
can handle a greater number of connections. This system should allow the
game to increase player count per server beyond the limitations of the
current tech.
Now as far as this tread, response the OP is trying to show as feature loss and game downsizing. Was in an answer to the following question:
Yorokobiy@Yorokobiy
What will be the extent of the first pass on the server meshing planned for 3.4 ?
discussion
February 5th at 05:17 pm
Is the tech gonna be working completly + further improvements or is it gonna be more of a test before the proper tech ?
Way to misrepresent.
I’ll be surprised if they get even half of that done by December 2018
On another note, and in an attempt to try and get back on topic.. Personally I never believed for a second that this game would be able to support even close to a hundred "on grid" or instance, whatever you wanna call it, let alone a thousand... or thousands.
The game already supports 50 per instance, and as it is known the servers are capable the problem that overwhelms performance so much lies on the client being overwhelmed by updates (the lack of culling), and the needed streaming tech that is a fundamental optimization to handle its scale better.
So let's say Stanton gets done, even if 50 per instance remain, all Stanton needs is being split in 20 areas with their own server that it would allow up to 1000 people in that solar system.
So it's not as far-fetched as you seem to think.
The only counter is if too many people try to go to the same place, GW2, for example, solved that by adding temporary overflow instances.
T'is isn't working this way. Your 50 pocket dimensions have to talk to each other in 3 dimensions so you need to contact 6 other Pocket dimensions (assuming they are cube like shaped) to render a picture. and now the 1000 players now all decide to go to one place. you need to dynamic rearrange your pocket dimensions and with changing one you need to change the 6 adjacted, too. While changing the size you may not loose any data like what if a player just changed pocket dimension and the pocket dimension shrinked so he is back into his old pocket dimension. This is working in a 2D environment but there is no server mesh that can dynamically pass data for this in 3D. It would need a team of network professionals that are only dedicated to this problem to solve it and a couple of years.
You actually need to talk to 26 other instances/servers/areas if you change the size of one 3D area (assuming it's a cube in the center of 27 cubes).
There are 26 adjacent cubes not 6.
I agree with you, the technology is nice as a theory but most likely not ever going to be reality.
The amount of data that needs to be moved between instances/areas/servers if just one of the instances is resized is going to be a real problem even if the servers are in the same cluster.
The logic to make this all happen without the users noticing is something even the best network engineers will have a problem with.
I don't even want to think about all the implications this has on client performance.
Oh I should have written "at leaast" 6 because the cubes could be vary in size and I can surround every one with minimum of 6 others (i.e. merge the 9 on top, the 9 on bottom, 3 on the left and 3 on the right and you have 6 cubes surrounding) thats what it makes so complicated > the size calculation
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it. The cake is a lie.
Network bind Culling for 3.1 patch at end of March, baring any problems.
This work aims to help improve performance in multiplayer by cutting
down the number of entities that exist on clients. Entities too far from
a player will be removed from the local client, and when the player
moves or the server otherwise detects new entities entering the player's
range they will be added to the client. Because clients will then only
consider updating entities that are near to them the overall CPU load
will be reduced and performance should improve.
Network Entity Streaming for 3.3 patch at the end of September, baring any problems.
Restructuring how the network code handles entity spawning and binding to allow for asynchronous streaming.
Object Container Streaming for 3.3 patch at the end of September, baring any problems.
At its core, Object Container Streaming allows Star Citizen to create
our Universe. We will no longer be restrained by the physical memory on
your PC and will be able to stream in new environments, locations and
ships seamlessly as you approach. This will also be one of the biggest
wins for increased performance as your graphics memory will no longer be
overloaded.
Parallel Network Jobs for 3.4 patch at the end of December, baring any problems.
Moving packet receive processing into the job system so that the server
can handle a greater number of connections. This system should allow the
game to increase player count per server beyond the limitations of the
current tech.
Now as far as this tread, response the OP is trying to show as feature loss and game downsizing. Was in an answer to the following question:
Yorokobiy@Yorokobiy
What will be the extent of the first pass on the server meshing planned for 3.4 ?
discussion
February 5th at 05:17 pm
Is the tech gonna be working completly + further improvements or is it gonna be more of a test before the proper tech ?
Way to misrepresent.
I’ll be surprised if they get even half of that done by December 2028
You miss-typed the year! Is ok. I fixed it for you!
Reporter: What's behind Blizzard success, and how do you make your gamers happy? Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
T'is isn't working this way. Your 50 pocket dimensions have to talk to each other in 3 dimensions so you need to contact 6 other Pocket dimensions (assuming they are cube like shaped) to render a picture. and now the 1000 players now all decide to go to one place. you need to dynamic rearrange your pocket dimensions and with changing one you need to change the 6 adjacted, too. While changing the size you may not loose any data like what if a player just changed pocket dimension and the pocket dimension shrinked so he is back into his old pocket dimension. This is working in a 2D environment but there is no server mesh that can dynamically pass data for this in 3D. It would need a team of network professionals that are only dedicated to this problem to solve it and a couple of years.
We will see Dual Universe as they already actively show some work on this on that and gives one overall direction on what works and what doesn't work, the same questions arise there and it does with SC, if the approach is possible for one it shall prove its viability.
And in DU we talk about nodes that are meant as small as 8 cubic meters if it needs to, they already did tests I'm not sure if they already manage to split areas in different server nodes depending on pop density.
Yes I know this video from 2016 (Don't know if there is an update to this)
The test was on virtual clients (slowly walking assets - Position, Quaternion) and virtual servers in a 2D environment, this tech has been used for 2D environments before.
In 3d the complexity is expotentialy higher and every single variable that needs to be communicated makes it more complex.
Oh and regarding DU I don't trust nor like Unigine (Russian render engine formally for demos not games)
Every player thats adds to the game needs the Data of every other player in his surrounding. The data has to go over multiple server instances (that can not be synced cause there will be a delay from instance to instance no matter what) in a fast paced Space Battle. Where Servers will spin on and off in realtime so you can not predict the delay between instances.
All this will definately lead to shadowing and rubberbanding which could be tolerated in UO and EQLive but not in a fast paced game where the player needs to get feedback for every single action and a phantom hit because of shadowing is frustrating.
I won't say that this is impossible, basically everything in star citizen is possible (including carrots in your biodome). But at the moment Star Citizen has not the manpower to develop it (obviously) which is why they switched over to static instance sizes (Like WoW or GW2 is using).
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it. The cake is a lie.
Aaand interactions ... just imagine: - 10 players in a row (where player01 can see player10) - 8m space between every player - we are at 8m^3 cubes (because reasons) - player01 shots at player10 (72m distance should be shootable) The ray has to pass 10 server instances within 33ms and this is a best 2D case where the players stand still and no resizing of the server mesh happens during the 33ms.
And this is just a very simple scene that'll happen very often.
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it. The cake is a lie.
Network bind Culling for 3.1 patch at end of March, baring any problems.
This work aims to help improve performance in multiplayer by cutting
down the number of entities that exist on clients. Entities too far from
a player will be removed from the local client, and when the player
moves or the server otherwise detects new entities entering the player's
range they will be added to the client. Because clients will then only
consider updating entities that are near to them the overall CPU load
will be reduced and performance should improve.
Network Entity Streaming for 3.3 patch at the end of September, baring any problems.
Restructuring how the network code handles entity spawning and binding to allow for asynchronous streaming.
Object Container Streaming for 3.3 patch at the end of September, baring any problems.
At its core, Object Container Streaming allows Star Citizen to create
our Universe. We will no longer be restrained by the physical memory on
your PC and will be able to stream in new environments, locations and
ships seamlessly as you approach. This will also be one of the biggest
wins for increased performance as your graphics memory will no longer be
overloaded.
Parallel Network Jobs for 3.4 patch at the end of December, baring any problems.
Moving packet receive processing into the job system so that the server
can handle a greater number of connections. This system should allow the
game to increase player count per server beyond the limitations of the
current tech.
Now as far as this tread, response the OP is trying to show as feature loss and game downsizing. Was in an answer to the following question:
Yorokobiy@Yorokobiy
What will be the extent of the first pass on the server meshing planned for 3.4 ?
discussion
February 5th at 05:17 pm
Is the tech gonna be working completly + further improvements or is it gonna be more of a test before the proper tech ?
Way to misrepresent.
I’ll be surprised if they get even half of that done by December 2018
We're already reaching the first quarter of 2018 and end of March so we can soon see just how 3.1 and step one with the "network culling" is going to turn out or be delayed. Time sure flies.
Network bind Culling for 3.1 patch at end of March, baring any problems.
...
Lobby Refactor for 3.4 patch at the end of December, baring any problems. ...
Server Meshing for 3.4 patch at the end of December, baring any problems.
CIG's roadmap is more like a best case scenario. Even if they won't have any problems it's more likely than not that they won't be able to make core features like this in the time they estimate.
So all those nice new server features are coming. But even without any problems getting those features listed for patch 3.4 this year is a best case scenario.
Hello,
neckbeards, look at your game, now back to mine, now back at your game, now
back to mine. Luckily, it isn’t mine, but if your project lead over-promised
while waving his hands around it could bug out like mine.
Look down, back up,
where are you? You’re in a queue at a food bank because you dropped your life
savings on The Vision. What’s in your hand? Back at me. I have it, it’s an
oyster with two tickets to Citizencon where you’re going to get blagged with a
demo again. Look again, the tickets are now JPEGS. Anything is possible when
you trap some nerds in a nostalgia trip.
I’m on a tank.
On a more serious note. So they're now starting to work on the network tech, that really is laughable.
Comments
The OP shows that they will go for instanced (creating new instances when a certain region will become too busy etc, like many MMO's do). But also shows it is still unsure what the max amount of players within one instance will be.
Anyway, what strikes me as odd in this thread, is that some expect that CGI at some point will still switch to seamless. There is no way they will overhaul their networking tech again after they have implemented this ' temporary solution' which they are now working on.
Also, I don't know how recent this news is in the OP, but if it is from this year, it is kind of late during development imo.
This to me is annoying, because it is the kind of detail I want to know for sure about a game before I spend money on. Kind of like those EA Steam games where they change their original plans after you buy it.
This is also incorrect, what SC has already is by default seamless all within a single-server, there is no "temporary solution" for server transition because there isn't server transition yet and the one to exist is already intended as the server mesh (the described server mesh is not the temporary solution).
¯\_(ツ)_/¯
That is not the case in SC, in the reality of server meshing the region lock is pretty much, you select the server region you play on, and for as long you play on the NA region, you will be on NA servers within that server mesh until you change region again, you will be able to go to a new play session as you do now and play in another server region.
The dev comment means that during a play session on a region you stay on that region, you wouldn't be in-game moving from a server in EU to a server in NA (inter-connects between regions).
The data is global, shared across all of them, not locked per region.
Also dev comment on that:
There is nothing misleading if the developer himself says the game will not work across regions. Servers are not connected meshed or anything else. If they are not connected then the data can not be global shared across all of them. I really would like to know why you keep saying the opposite the developer says.
"We won't be connecting servers across server regions (US, EU, etc) in this version."
You also still owe everyone an explanation how you deleted your post.
I even posted the other dev commenting on that bit that backs up the way I was understanding it, servers of several regions are NOT meshed together, that is not a region lock, when you go play in one NA server in one game that openly shares the data globally that you could then go and play your game on the EU server, that is not a region-locked game.
Allow to explain again, not connecting servers across regions in the context of a server mesh means that the server mesh would be only made of servers frome one region and you wouldn't transition to other regions unless you start another play session selecting another region. It is not about stopping you from playing with friends in another region by locking you or your data to one of them.
It's about reading it with its context, you are the only person I've saw who read that and understood it as when the server mesh is added SC will become a region-locked, I wonder why is that...
But , let's calm down, and .. let's talk about arguments when you'll actually have the game to play.
No. The current "alpha" and pre-made cgi trailers which Robert workers are showing here and there , are not counting as a Game.
Reporter: What's behind Blizzard success, and how do you make your gamers happy?
Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
The concept was showcased by IBM and back then they presented it as "original" - whether it was or not? And contrary to suggestions that the tech would never see the light of day IBM realized it in the late 2000's. Remember IBMs interest - selling servers and software solutions!
Since then of course we have seen a growth in cloud computing and a number of games which run on different - different - mega-server solutions. So things have probably moved on even more.
Anyway the fundamental idea behind what IBM proposed was that instead of a server managing a set number of people a "server" would handle a volume of space. (Most games have a third dimension). And regulate everything in that volume. How big a volume would be dynamically adjusted depending on the population density.
So if everyone on a server congregates starts to congrgate in one place more and more server compute power is brought to bear on that area with those servers handle smaller and smaller volumes. And since the population density elsewhere would be decreasing some other servers will be handling larger and larger volumes.
Various advantages were claimed including the ease of scaling the design to population growth (up to and in excess of 500k back in early 2000s) and decline.
Obviously this type of design creates a different set of messaging requirements. Decisions till have to be made about what secondary servers you have for handling logins, chat etc. etc. And there are different ways all of this can be done.
My understanding of their approach however was not some fanciful, unproven idea.
They still have the challenge of getting it to work of course. Compare what they have today to what was being said they would never have 2 years ago, 1 year ago etc. and progress is being made. Is it fast enough etc. - that is a debate that cn be had.
The title of this thread - as a minimum - is misleading though!
A more interesting observation would be: does this mean they have had a design review and decided what will be in 3.1? For - assuming they are aiming for an end March release and not an end March development cut off - they have c. 5 weeks to go. Allow some time for Evocatti and PTU and ..... a version of 3.1 should be making its way to the launch pad.
Scalability is one way to attack the problem, but then in a game like SC or even DU, you have another problem, where the servers could perhaps handle the load, the clients could not, it would turn into a client performance issue, and one way or the other, either enforce caps or extreme optimizations to ever handle high density.
What DU is doing as said ties in many ways to what SC wants to do, so we are to see how this involves and we will see this tech finally get proven on a scale both titles need it to work.
This is not for now, the server mesh stands attm put in Alpha 3.4 (late 2018) if it's not pushed back, what is for 3.1 is aactually network culling.
Delusional mostly , don't really remember saying you have "mental problems" .
But hey! When someone is waiting 6 years for his dream game , and is just around .. 15% completed 6 years later, with the biggest budged ever for a MMO in the entire history, then .. how should I call you? DFD? (Delusional Faithful Donor)
Reporter: What's behind Blizzard success, and how do you make your gamers happy?
Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
This work aims to help improve performance in multiplayer by cutting down the number of entities that exist on clients. Entities too far from a player will be removed from the local client, and when the player moves or the server otherwise detects new entities entering the player's range they will be added to the client. Because clients will then only consider updating entities that are near to them the overall CPU load will be reduced and performance should improve.
Network Entity Streaming for 3.3 patch at the end of September, baring any problems.
Restructuring how the network code handles entity spawning and binding to allow for asynchronous streaming.
Object Container Streaming for 3.3 patch at the end of September, baring any problems.
At its core, Object Container Streaming allows Star Citizen to create our Universe. We will no longer be restrained by the physical memory on your PC and will be able to stream in new environments, locations and ships seamlessly as you approach. This will also be one of the biggest wins for increased performance as your graphics memory will no longer be overloaded.
Parallel Network Jobs for 3.4 patch at the end of December, baring any problems.
Moving packet receive processing into the job system so that the server can handle a greater number of connections. This system should allow the game to increase player count per server beyond the limitations of the current tech.
Lobby Refactor for 3.4 patch at the end of December, baring any problems.
This will lay the groundwork for server migration technology that will allow us to connect multiple servers and clients in the same game session. As this task is closely aligned to server meshing, there won't be an immediate observable benefit to the tech until all server meshing work is complete.
Server Meshing for 3.4 patch at the end of December, baring any problems.
First iteration of the server meshing technology. With this system, individual servers would be responsible for different locations within the solar system. When operational, players and entities should experience seamless transitions between servers during quantum travel.
Now as far as this tread, response the OP is trying to show as feature loss and game downsizing.
Was in an answer to the following question:
Yorokobiy@Yorokobiy
What will be the extent of the first pass on the server meshing planned for 3.4 ?
Is the tech gonna be working completely + further improvements or is it gonna be more of a test before the proper tech ?
Way to misrepresent.
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it.
The cake is a lie.
Reporter: What's behind Blizzard success, and how do you make your gamers happy?
Blizzard Boss: Making gamers happy is not my concern, making money.. yes!
(Don't know if there is an update to this)
The test was on virtual clients (slowly walking assets - Position, Quaternion) and virtual servers in a 2D environment, this tech has been used for 2D environments before.
In 3d the complexity is expotentialy higher and every single variable that needs to be communicated makes it more complex.
Oh and regarding DU I don't trust nor like Unigine (Russian render engine formally for demos not games)
Every player thats adds to the game needs the Data of every other player in his surrounding. The data has to go over multiple server instances (that can not be synced cause there will be a delay from instance to instance no matter what) in a fast paced Space Battle.
Where Servers will spin on and off in realtime so you can not predict the delay between instances.
All this will definately lead to shadowing and rubberbanding which could be tolerated in UO and EQLive but not in a fast paced game where the player needs to get feedback for every single action and a phantom hit because of shadowing is frustrating.
I won't say that this is impossible, basically everything in star citizen is possible (including carrots in your biodome). But at the moment Star Citizen has not the manpower to develop it (obviously) which is why they switched over to static instance sizes (Like WoW or GW2 is using).
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it.
The cake is a lie.
just imagine:
- 10 players in a row (where player01 can see player10)
- 8m space between every player
- we are at 8m^3 cubes (because reasons)
- player01 shots at player10 (72m distance should be shootable)
The ray has to pass 10 server instances within 33ms and this is a best 2D case where the players stand still and no resizing of the server mesh happens during the 33ms.
And this is just a very simple scene that'll happen very often.
When you have cake, it is not the cake that creates the most magnificent of experiences, but it is the emotions attached to it.
The cake is a lie.
So all those nice new server features are coming. But even without any problems getting those features listed for patch 3.4 this year is a best case scenario.
Hello, neckbeards, look at your game, now back to mine, now back at your game, now back to mine. Luckily, it isn’t mine, but if your project lead over-promised while waving his hands around it could bug out like mine.
Look down, back up, where are you? You’re in a queue at a food bank because you dropped your life savings on The Vision. What’s in your hand? Back at me. I have it, it’s an oyster with two tickets to Citizencon where you’re going to get blagged with a demo again. Look again, the tickets are now JPEGS. Anything is possible when you trap some nerds in a nostalgia trip.
I’m on a tank.
On a more serious note. So they're now starting to work on the network tech, that really is laughable.