Will Server Meshing Save Star Citizen? (Ft. Mr. Tybio & Kevin Riggle) | Launch Sequence Podcast

As Star Citizen is built, the slow process has produced amazing moments and fun gameplay. But at the end of all of this, the game won’t work with the proper MMO backend. CIG is blazing a trail in the gaming industry, and trying to construct something never done before in gaming. With decades of experience in software and network engineering between them, my guests today hope to shed some light on just how phenomenal the system is, and how difficult it will be to run. Today we sit down with Tybio and Kevin Riggle of recent Star Citizen reaction fame to discuss server meshing with the pros.
Today’s Guests:
Kevin Riggle
KZbin: / @free-dissociation
Mr. Tybio
KZbin: / @mrtybio
ToC:
00:00 Introductions
06:20 Why Talk About This Now?
11:15 What is Misunderstood about Server Meshing
18:20 Has This All Taken Too Long?
23:40 Is Server Meshing That Special?
24:40 - 29:10 Cut this out
35:30 Can they license StarEngine?
40:00 The Structure of Server Meshing
49:30 What is gRPC?
55:30 Does Star Citizen Seem Possible?
01:06:30 How Will Server Meshing Rollout?
01:10:50 Will Server Meshing Solve Everything?
Support Space Tomato:
Patreon: / spacetomato
Paypal: paypal.me/SpaceTomatoPays?loc...
Gaming Community: / discord
Star Citizen Organization/Guild: gii.spacetomatogaming.com/
Start a Star Citizen account with 5000 extra credits in your pocket with the link or the referral code below.
STAR-JCG9-94TC
robertsspaceindustries.com/en...
#starcitizen #spacetomato #podcast

[@free-dissociation]

This was a lot of fun! Apologies for my network issues around the twenty-four minute mark-even software professionals struggle with software stuff sometimes. ;) Thanks to SpaceTomato for the invite and to both him and Tybio for a great conversation!

[@VonSpud]

Very interesting conversation, I totally enjoyed it. Learnt some things and have some hope for where CIG is going and plans to be in perhaps "five" years. My wife thinks I'm addicted to StarCitizen...she maybe right 😏 I have over a hundred games but SC is where my attention is. The scope and complexity intrigue me ... Our SC community is a big part of my interest. Many like minded folks who want more than just a shooter or FedEx game.

[@TechNaOkami]

I don't need sleep I need this podcast

[@TheDeadbolts]

foshizzle

[@amou2409]

Correct answer

[@Nicodemus_Archleone]

Really liked having actual experts come in to give their opinion and explanation.

[@antoniovinciguerra8982]

You‘re doing a great job as a host - picking guests, asking the right questions, not interrupting… you don‘t get enough credit man! Loving these podcasts, keep‘em coming and I‘ll keep hitting that like button

[@latech7671]

Oke, this was a VERY good conversation I have only one thing to add. I think Tybio and Kevin did both not fully realise (or simply didn't talk about it right) the way Server-Meshing is going to roll out. Here is how I understand it: 1. We will get the separation of Replication-Layer (with CrashRecovery) which is basically what Tybio was talking about when mentioning SM with one DGS. That was in testing in the Tech-Preview since Dec. last year and only this weekend fully opened to all backers on the Preview-Channel which did highlight a few problems with older Game-Services not fully/rightly integrated with RL but did work generally 2. Next we would have Static Server-Meshing which is the infamous 4.0 update. All that would mean is that now they connect multiple DGS to the RL, each of them handling a different area of the overall universe (overall shard). These Zones are already given by the game in form of Object-Containers (that is a big aspect I think Tybio messed up a bit at the end of the Podcast. In the near future iterations they don't decide in RealTime where the border between Servers is but do that based on Object-Containers that are already existent in the game-world). For this version they need to tell the servers which area they should calculate and we don't know how small they will make these areas. What we do know is that they are going to need more than one Server for a single StarSystem IF they want to add the entirety of Pyro in 4.0 because Pyro has to many entities to handle by one Server (which is why the Tech-Preview Tests of Pyro have parts of the system not included) 3. Then they will probably first increase DGS Amounts per shard to look how far they can push the RL (at least in the Tech-Preview). I don't know if they will actually do that in Live because that will cost them A LOT OF MONEY given that they would need more and more Servers which they need to pay for and those servers have less and less to do. 4. They will use the Data they got from testing the limits of Static SM (how much can the RL take, what Entity-Count has good DGS Performance, ...) and create rulesets for Dynamic SM and then enable the RL to change Server-Allocation FOR OJBECT-CONTAINERS at runtime (that means they still are bound by the areas that are hard-coded in the game-world so the Borders between servers are still all pre-determined by designers). Once this is possible they can for sure also experiment with Player-Counts because they can now scale down to somewhat smaller areas IN SPECIFIC REGIONS. The main bottleneck with this system now is that wherever NO SMALL OBJECT-CONTAINERS are existent they still can't divide the load onto multiple servers and therefore there still is a hard limit/a possibility that too many players are in specific areas. Example: I am a massive org and decide to go somewhere random on a planet with 1000 people all in the same shard. The problem here is that as long as there is no Point of Interest with it's accompanying Object-Containers, the planet is still (as far as I am aware) one giant Object-Container (only outposts, cities, ... have their own object-container(-structures)). In other words with this first version of Dynamic SM they still can't split these 1000 players up onto multiple DGSs since there are still borders these Servers have to obey and for some regions these are massive (space itself would probably be similarly empty of Object-Containers to split meaning that that point massive Space-Battles are (as far as I understand it) still not fully possible 5. Now the one I am not even quite sure they are going to try (let alone actually achieve) as this is very much in the future (1-4 are very much possible in a "short" amount of time as I see it IF what they showed as CitCon is now possible). This would then finally be the version Tybio was (I think) talking about where the RL can split the GameWorld up into multiple DGSs at (almost) ANY POINT IN SPACE making it possible to split these massive Object-Containers into multiple smaller once. I think this actually had already some work put into it and it comes from work they did for the Hull-Series of Ships 😂 (not kidding). If you remember back: Tech that needed to be developed for these ships to be possible was to change the size of the physics grid of that ship when it extended and (as far as I am aware) physics-grids are based on Object-Containers. In other words they did work on changing the size of Object-Containers at runtime. IF that is true, then a portion of this is also completed. What they now need to do is be able to add new Object-Containers at Runtime (which would I think work similarly to resizing them) and they could split one massive Object-Container into several. NOW "all" they need to do (and this is the big problem Tybio was talking about) is find out WHERE they can split these big Object-Containers without problems. Now we have one last big problem (that I can see right now so there are more we can't predict): Where are the limits for the RL (how many DGSs can it handle, how many players, how many entites, ...). The problem here is that switching between RL (which is same as saying you are switching Shards at runtime) is NOT THE SAME as what they are doing with SM. They don't have an overarching Service that connects all RL together which means you would have to disconnect from one RL and connect to a new one while playing (which will have a delay). 6. Replication-Layer hopping: The easiest solution here would in my opinion be that RL-Hopping would at first only be possible in areas with nothing of note around you (in empty space between Points of Interest, in the transition of StarSystems, ...). Honestly this is such a future problem that I will not speculate about it more but they have talked about switching shards, instancing and other stuff at runtime which all require RL-Hopping to be possible so it seems that they do plan on implementing such a system Right, that was again one of my legendary MASSIVE COMMENTS. I really hope anybody has actually read this (I always feel bad for having done all that and nobody actually recognising the work). To sum up: 1-4 are very reliable as all that has been talked about a lot by CIG, 5 is what I am pretty sure CIG plans for the future but they haven't talked about it that much yet because they too will probably only tackle it when everything else is working, 6 is very much speculation on my part based on problems I still see and stuff they have said at some point. If you have anything to add, please answer. I really want to start a conversation here 😉

[@d.politegaming1188]

I am a layman and was able to understand point by point. I appreciate you taking the time out to explain this. I love hearing about the technical side and what hurdles are next for this project. This was very insightful.

[@latech7671]

@@d.politegaming1188 Great to hear this gave even additional info. In a way I think over 99% of people are layman when it comes to this topic (me included) 😂

[@Tsudico]

I don't think that they will ever make it so that you can hop from shard to shard without exiting the game because the way the system is set up (through their descriptions) has the back end entity graph that primes each shard's replication layer only receiving information that has to be passed between shards. In addition, I think that many people either don't know, or are ignoring, the fact that the replication layer as an entity graph database doesn't have the same constraints a normal database has. For example, the replication layer doesn't have as stringent of requirements for consistency in time because it takes time in reality for information to propagate and the in game universe is large enough for time to be a viable restriction. Different solar systems or planetary systems within a solar system do not need to be updated at the same exact moment as an event occurs which means that CIG can utilize that in configuring the replication layer to be as performant as possible.

[@latech7671]

@@Tsudico 1. Well, if I am not mistaken in the presentation of SM from Citcon 2021 they talked about Shard-hopping and from the recent leaks on Pipeline we know they want to focus more on instancing (which would also be you being removed form the current shard), at least if that part of the leaks is actually real. I right now consider it working in such a way that it will only work when you are away from populated areas (in QT or during a jump). How it really will work we can only guess as CIG has not talked about it any more (and they too are probably not quite sure yet as they first will look at everything else and how it works on live). What will for sure happen (in terms of PES being on Shard-Scale) is that the world around you would change (which is why it can only happen away from populated areas) BUT stuff like missions or the economy should slowly be outside of Shard-Constraints with Quantum and other Services being implemented so everything that would change when Shard-Hopping would be Objects in the world. Also, Shard-Hopping would obviously not be for one player but more for one Object-Container (most commonly the ship you are traveling in with all items and other players hopping with you together) 2. Yes, the Replication-Layer NEEDS to run in realtime because IT is the connection between DGSs and Clients and for the game to function at all player-movement, AI, physics, ... all need to be dispatched between clients and servers in realtime

[@Tsudico]

@@latech7671 I think we may be talking past each other on these topics. If I remember correctly, nothing they mentioned in 2021 indicated that shard hopping would be while connected to an existing shard but would happen if the player for some reason needed to connect to a different shard like if the shard was full or they partied with a group that was mainly in a different shard, it can happen because the data is transferred to the back end entity graph when the player logs off and so can be copied to another shard when the player logs on again. I think there is too much data to transfer related to a player's account and all the in game things they own that shard hopping in real time isn't feasible. Instancing could happen "within" the same shard depending on your definition of instances. I completely expect them to run a server full of hangar instances because it will be very performant to have a single copy of all hangar assets and just connect the various hangar instances to the specific locations once ATC is called. Nothing in their architecture that has been shown indicates they can't have multiple entity zones that are not connected in the game world to each other from operating on a DGS. Multiple copies of any of the in game events like IAE or Invictus could also be done in a similar manner, with the hand-off occurring while in the elevator as a natural transition point. Just because you click the elevator to go to a certain hall doesn't mean that they couldn't have multiple copies of that hall running on a DGS within the same shard. Here again I think you may have missed my point. It doesn't matter if multiple instances of the replication layer architecture communicate _with each other_ in real time due to the size of the game world they are replicating. They can partition the services based on locality in the game world so that consistency is preserved for "nearby" updates but isn't as big a factor for cross-system updates. To give a basic example, some people might be fighting near Seraphim station but clients connected to Orison wouldn't need to see the fight in "real-time" until they approach it, so if it takes a few extra ticks to propagate across the replication layer and to the clients at Orison it doesn't affect game play. Similarly, if someone gets a crime stat, it is perfectly acceptable for it to take time for that crimestat to be reported to the opposite side of the system because the player themselves will not be able to travel that distance within the time it takes to propagate through the replication layer. If I start a quantum jump from the Pyro gate in Stanton, the players and servers at my destination do not need to know it the instant it happens because it will take time for me to reach my destination. All of these show that time consistency is less of a concern due to the scale of the game world itself. I'm not sure if other games would be able to utilize the architecture of the replication layer to the same extent CIG might be able to specifically because of the scale of those games versus the scale of Star Citizen's universe. It is possible it would still give benefits at a planetary level, but it comes down to how fast the replication layer can become consistent across all the instances of its services. This is where the scale of Star Citizen, and the time it takes to get from one location to another, actually might help make the replication layer work where in other scenarios it wouldn't because consistency would be an issue.

[@jonahhekmatyar]

Yoooo! This is why launch sequence is such a good podcast. Two great guests.

[@Vaffi]

I'm not a tech guy but this was incredibly interesting. "This is a structural improvement, not like a feature improvement", was probably the most important statement everyone should understand at this point. Meshing will not solve all problems, but it is enabling CIG to solve problems and make things possible. Can't upvote this podcast enough

[@Gates54]

This.was.awesome. Kudos for having these two on. Server meshing is clearly an incredibly difficult challenge, and these guys explain why.

[@Lysurgic]

bro you are the coolest star citizen streamer/content maker for having these 2 on your podcast. much love!

[@jazzynupexbox6008]

@55:34 the demo was to point out Meshing sharing space & streaming objects in & out. Not that they would scale it that small intentially. But the point was the server scaling up & down as needed. Based on server resources & needs of the event.

[@N1ghtCOB]

This is an exceptional Q&A podcast. Hats off to the guests for doing their best to keep this in a format most of us could understand. And Tomato, I've watched your launch sequence for a while now and I'm continuously impressed by how good you're getting as a host. One of the best!

[@TedManAte]

As a SW engineer, this felt like a conversation that I would have at work on a good day. I loved every minute. The guys really gave good insight and it's clear that they know their stuff. Well done guys! Quick anecdote: today I reproduced a compute issue on a virtual environment that I support. While the issue itself is discouraging, reproducing it was as exciting as solving the problem. I understand Chris crying for the replication layer demo completely.

[@FinNapalm]

I'm bit late for party, but thank you for doing this show. I sure hope you will get this setup again after 4.0 goes live.

[@witchspace-yt]

Solid chat, nicely done all. Only cautionary words I would add is not everything that works well for web style applications transfers well to the CIG environment; a web view of real time as sub half second works great for LTP , inventory and loading ops, but when you get to physics and combat where you are looking to many hundreds of transactions completing in under 33 milliseconds ... whole order of magnitude of extra fun ;)

[@malismo]

Great talk! More of these should happen for sure. I wish I could have caught it live, but alas :)

[@magvad6472]

This podcast episode was awesome, more like this please! As much as it sucks, I think the "12 years" thing is fairly simple: 2 games, 2 different formats, 2 different design hurdles, split teams, AND 6 years into that cycle...they rebuilt the entire goal to be BIGGER. 100% a management issue.

[@wisewasabi]

Great episode these guests work well together

[@tingil8439]

I love talks like these about SC tech. As a dev myself, I cannot stress enough how incredibly complicated the tech is that CIG are developing for SC and thank you very much for putting emphasis on that! :) One other aspect about SC tech, that I'm very interested in is, how CIG is going to deal with data/state consistency. One of the first things I learned when I started developing distributed systems is that you will always have inconsistent data across systems for a moment in time (there this phenomenon is called "eventual consistency"). In SC, we see these as desync and CIG have already talked about how they are using predictive algorithms in order to minimize the desync we are experiencing. I am wondering whether they are going to use real recorded player behavior to train an algorithm to do these predictions. During CitCon 2023 Yogi briefly mentioned how they used real player behavior to train dogfight AI, so the idea is not so far fetched that they will most likely do the same to predict player movement in order to hide desync.

[@MrTybio]

Honestly, I think we are all very interested in that. There is an inherent issue with data sync when you have local servers that can update at near real time and clients that all update at various timeframes based on latency. That's what makes Online game development so hard, and so bloody interesting. There are ways to solve it, right now we see that with rubber banding....but as they move forward I expect some of the better solutions to come into force here...and honestly, just getting good FPS from the server so our clients are as close as possible to the state engine will be a massive step forward.

[@VonSpud]

I saw Space Tomato and recognized Tybio... Yes!!! Must watch. First time seeing Kevin, will have to check out his channel now.

[@medicsansgarantee]

not that I dont like reactions of reactions or speculations of reading off CIG websites, but some experts talking about things they know about is very refreshing and healthy

[@Tainted-Soul]

thanks for keeping it layman LOL I did get lost one or two times lol . Many thanks for the input into the what CIG is trying to do it does put the time in to prospective and understand what they are trying to do is hard and not been done before. fingers crossed this all works by the end of the year

[@glutrino]

Great talk.. being a tech guy myself was very interested as well on technologies used by SC and AWS...

[@luke5g230]

Thank you so much for this amazing interview was so good hear from your two guests and there insights into what SC is doing ❤

[@tree0311]

This was an incredible conversation to listen to and has sooo many powerful quotes to put Star Citizen and what CIG is doing with Server Meshing into appropriate context.

[@jasonwestmoreland7337]

Another super amazing podcast, even with some of the technical issues. I really enjoy these discussions with people who have industry experience - but maybe that is just my own inner developer coming out! Great show, keep up the good work.

[@sketchtherapy1218]

These two sound like they would have some fascinating conversations for hours that we wouldn't understand lol.

[@thehoodedvoice2768]

I had to sit up outa bed after I saw who the guests were 😅

[@medic4christ777]

The honest issue is that for 12 years the entire focus was on Squadron. The PU was nothing but a cash cow to fund that project and got MINIMAL support. I warned them years ago that this was a mistake. Well, here we are. People have lost interest at a staggering rate. They thought they had forever funding and they didn’t. Their talent has left, their funding is down. So we will see if the game is recoverable.

[@mattst2717]

Honestly, with what we have already seen on the current PTU with CIG's work on the Replication Layer, as well as transferring servers after a 30k, that tech will be HUGE for the step into server meshing. I think there are a lot of other pieces of tech that will need to be worked on if CIG wants to allow higher player counts in a single system though. For instance, throughout all of stanton, most stores only have a maximum of 2 terminals to purchase items. This would have to change, or have another alternate 'avenue' so to speak on how to order items and goods. Even worse, some places like New Deal only have a SINGLE terminal. I know CIG have mentioned adding ASOP functionality to the Mobiglas, and I'm hoping that some of the other planned mobi applications would solve this bottleneck.

[@MrTybio]

Hurm, that's a great point, I've been so focused their groundbreaking use of new tech in an online game that I've sort of missed all the actual in game implications of it. Thanks for bringing that up! Worth a lot more thought!

[@Tsudico]

@@MrTybio They have previously talked about some of the ways they can artificially limit access in order to be able to meet the performance needs of the mesh, it is quite possible that the terminals are another aspect of that but for the back end services they connect to. It wouldn't surprise me if they convert most of the terminal accesses into Mobiglass apps so they aren't constrained by in game physical terminals. I think the issue currently is connecting the apps to the appropriate service nodes, but they could have in game "NFC style" tags that players could use to "connect" their Mobiglass to if they don't want to do an invisible zone that indicates a service node.

[@BankonTim]

What great content Damn! I'm currently studying the field in university and that was amazing! Love it!

[@SpaceTomatoToo]

Glad it was insightful! Some seriously smart talk!

[@jazzynupexbox6008]

@50:48 the point of gRPC is to be a service communication as fast as possible. So it became the modern way for fast communications between systems. If you follow service communication from the beginning it shows how the evolution from RPC, Com, Soap, Rest, JSON, etc. But as of today gRPC is one of the faster & efficient ways to communicate.

[@prometheus7069]

I love to learn more about how it works

[@Warius5]

great Guest choice watched both these guys and thought theyd be good on the pod cast

[@arthurhalter8760]

Hey Tomato how can I get a tomato sweater like that one ? Great vid like always ! You are one, if not the best SC streamer. Chill vibes, with time passing by you educated yourself extensively on the game, and your interviews are top-notch.

[@chawkes70]

This was interesting and thought provoking.

[@cqc2238]

Great episode. I am new to star citizen. I was a backer on kickstarter. I’ve played a few times over the years. I recently went in hard and pledged some ships, starting putting the hours in. I want this to work like everyone. I just want to keep it real though. It took less time to build a real spaceship and actually go to the moon than it’s taken to make this game to its current state. I love the game but 12 years is just too much. The current state is still a horror show. I keep coming back but, It really needs to get turned around and FAST.

[@Skyguy22]

@SpaceTomato fyi, I think you linked the wrong channels in the describtion. Both links go towards a R3vak.

[@sketchtherapy1218]

This is a great panel.

[@yasinzeydulusoy]

Yes it will, even if there is not enough content its the people often who make the content and the game enjoyable such as literally any other game but VRchat Gmod could be the star examples of it just like irl, even if there is nothing around having a company could make things endurable

[@Human_OU812]

I think Kevin was demonstrating the internet latency issue in realtime.

[@TheBuddhamachine]

great interview with great people

[@Kwagga_1972]

Thx......Loved It

[@victorvendetta9409]

I think cig is definitely pushing boundaries of gaming. Soneones gonna have to do itm i live that they kinda drive that point in the middle there

[@benmaier7232]

light needs at light speed 133ms to travel around the earth. (That would require hollow core optic fibers tough) With the optic fibers we currently have, where information travels only at 200 000 km/sec takes, it takes at least 200ms for information to travel the 40 000km of earth's circumference (without delay due to electronic amplifiers...). Considering this, do the two experts think that a single world shard is possible for Star Citizen?

[@Sybernetix]

I fully expect that due to the numbers of servers required to build out the mesh CIG will require OCP Timecard implementation, not sure if AWS has this already (its over 2 years old) to be able to keep the replication layer in sync. This would be the first use for a video game surely?

[@MrTybio]

The number of "1sts" in this work is ever growing. I'm not sure how they are dealing with this (As I said in a reply in another thread here), I hope we get more information once they have the plan...to be honest, I'd be playing things close to the vest myself as it is very likely they will have to make some quick changes that have huge impact to the structure as they prepare to roll this out. Most people don't get that in Development, you code what you "Think" will work, then try it out...and recode when you learn where you were wrong. To the average player, hearing that the new wizbang didn't work out would sound like a failure rather than the success it is...as now they know the constraints and considerations in a much more factual way rather than by theory crafting as they code.

[@furyiv]

Lol at the 'Cut this out' section...

[@RD-qn4gt]

Thank you ST! Really enjoyed this conversation! Although just a side note, Kevin seems way to eager to split hair's over things like milliseconds and seems to get bothered by it to much. I have to say, I really enjoyed Tybio's class, and kindness with touch confident response to Kevin who seems to egar to be just right at any cost. But great overall, also thank you to Kevin and Tybio!

[@MrTybio]

Thanks for the comment, I'd like to stick up for Kevin however...I was over-generalizing at times and the techies struggle is to figure out the right balance. There is no problem with someone else pointing out the complexity under the hood, as it helps deepen the conversation in a way most people can find more value in over just Kevin and I spouting techie-babble at each other.

[@kudos1729]

They want to put as many backers together in one ‘convention’ center for IEA…. Sell ships baby!

[@MrSmith123123]

Planetside 2 has had over 1000 players in the same game map for over 10 years (MMO fPS) it is feasible to have low latency gameplay with meshed services by other dev teams. Eve online too. PS2 won a guiness world record.

[@RN1441]

These guys are great, but Kevin needs to put another MB of ram in his 486 if he's going to do lives streams. It's hard to take a network expert (which he is!) seriously when they don't have their home network on lock-down. edit: I'm glad they addressed the fundamental trade off between latency, consistency, and correctness in distributed systems as there's an unfortunate habit of treating meshing like a panacea that solves everything when it actually brings new problems that can only ever be traded-off never eliminated.

[@ThomasD66]

Probably a Compaq with proprietary memory modules.

[@MrTybio]

Just a note, Kevin is the software engineer, I'm the network Engineer...what you don't see here is me fighting with my camera in the post-show when it decided to get all wonky!

[@RN1441]

@@MrTybio:D My mistake. From my vantage point though, both of you know more about software and networking than I do, except maybe embedded stuff and FPGA.

[@UnknownMoses]

Server meshing is awesome but the replication layer being decoupled from the game server is more important

[@northendtrooper]

If possible to correct the links to the guests pages? I doubt they both have the same youtube and twitch pages. TY! #EngagementForTheAlgorithm

[@CosmicD]

1:17:15 , I was asking myself this yesterday. We're playtesting a replication test with recoverable servers rightnow. But the new quantum travel mechanics aren't in yet, nor are the personal cargo elevators; I'm a power user but I don't know much about network or server programming, so I was always in the headspace that all these new features would only be possible when server meshing was production ready. But now it seems they already split the replication layer from the dedicated server. So I wonder if that's an efficient way to work ? Because the new quantum travel mechanic is going to behave differently on the network, also the cargo elevators, and persistent hangars. So I wonder, do they already have that working internally, ? Because they have to teach the RL and the dgs how to communicate these new behaviors. Could it be that it'll be a long wait for 3.23 or whatever major patch they want to include these new features into, while at the same time also moving RL / DGS split ?

[@latech7671]

The biggest problem here is that we don't know WHICH systems need to be adjusted to work with RL. If a system works with RL I really don't think they will introduce it before RL is implemented into the game. The good news is that (as far as I can tell) when a service is build to work with RL NO additional changes are required to make it work with SM as RL with one DGS is basically SM with a single server. Only aspect might be that some systems need to be tested again and maybe slightly tuned because they don't replicate on non-authoritative servers as well. Example: Mission-System. Right now in the RL-Tests it is very obvious that missions aren't yet hooked into RL but still only exist on a DGS Level (which they already told us about at CitCon). With only RL that is already noticable because missions don't persist when CrashRecovery is used. On a SM Shard this would be even more catastrophic since now you would loose missions when transitioning from one server to another (and also wouldn't get missions from the area that is handled by a different server) BUT the issue is already recognizable with only one DGS and RL because of CrashRecovery. The reason that is the case is because CrashRecovery IS basically switching Servers (like in SM) just that the old server doesn't exist anymore and the new server you transition into first has to start (and load all entities) which creates a long pause in all simulations

[@PwningSarge]

Anyone know the outro song? It's not in the description

[@PwningSarge]

sounds like maybe mr fijiwiji

[@ColbyWanShinobi]

I applaud the guests for coming on and sharing all this info, but there was a ton of time being spent in the weeds. Some parts of this were way too technical for most people. I understood 99% of what they were talking about and it was still tedious in parts. I just can’t anymore after 45 minutes. Bottom line: Hopefully more people will understand that CIG has been working on doing new things in game tech that are far from trivial. Sure, they could have sped things up a bit hypothetically, but this was never going to get accomplished in something as short as 3 years even.

[@voodoo22]

Gonna take years to smooth this out

[@josephjohnson9857]

Are these the same guys that said that server meshing at this scale or application couldn’t happen. Here we are putting the final touches on server meshing.

[@justwords3882]

Dual universe already uses server meshing 🤔

[@D.Enniss]

It should be noted that the first years of CIG was mostly about growing the company, saying 12 years is not really accurate to describe the effort and manpower that went into developing the game because it wasn't a linear process, it's not like CIG started out with 1000 trained people with well defined methodologies of work and development etc, and they did so while doing many new things that don't exist anywhere else, they were/are explorers charting a new map, going where no one has gone before, most other companies have the "luxury" of having the "map" from the get go. Not to mention that we mostly measure progress with SC alone, often forgetting to factor SQ42 into that "how long it's been" question.

[@snowmind]

@SpaceTomatoToo Both YT links point to the same channel. Could you please amend it, thanks in advance.

[@wilddoggamer6167]

They can bring up as many servers as they want, but eventually CR needs to drop this idea of full persistence. He sold it as "if you place a empty can somewhere, a month later you should go back and pick it up." No stupid. There is absolutely no reason to do this, and trash is already filling up the servers and slowing them down. You want it to persist for a couple hours? Fine. But with replication and server meshing, none of this in theory will ever be cleaned out again when a server restarts. I said it years ago it is stupid, and have only been proven correct since then.

[@SgtHack802]

I hope the game gets better. I used to love mining. It’s so complicated now, not fun anymore. I hope they don’t do this to the rest of the game.

[@UnknownMoses]

47:00 you guys are not entirely correct

[@mizardelwana]

The real question is: Does Star Citizen needs saving?

[@gyratingwolpertiger6851]

Click bait title going to click bait I guess

[@justwords3882]

Dual universe, has a full game in one online universe. They started with server technology then built the game on top of it.

[@arcidalex910]

If SC started that way it would have never had been funded since there would be nothing to show. And also SC of today is far beyond what the original goals called for

[@justwords3882]

Agree

[@tlove21]

Remember Icache? Yup, they have started and failed probably more times than we now. As a developer, we are often tasked with building applications with very short scopes within 3-6 months. I then looked at the scope of SC, and I would have estimated 20 years of development. This is also taking into consideration other games, and looking at their scope, and iterations over the years. SC scope already includes the expansions and upgrades all rolled into one. Hence they can implement many tier 0, based on their obvious design documents that are so robust. So hence beam citizens are mainly tier 0 implements.

[@cromwellw91]

I don’t understand “save” SC. Has something changed? Is SC on the brink of failing? Funding hit a record 2023, SQ42 was announced to be feature complete and CitCon was a solid success. SM has ALWAYS been noted as a critical technology for the MMO. Was this just meant to get our attention Tomato?

[@yous2244]

First

[@TheMrcomics]

The links for your guests are each the same and also neither of the gentlemen on screen.... Kind of no point linking if it's not actually being checked/edited

[@internet_tough_guy_]

If server meshing doesnt get them to a minimum of 1000 players concurrent this project has failed period considering in 2019 Chris Roberts boasted about how it was going to let them have between 4000-40000 concurrent players.

[@Aimerxd]

I hope what Cris said comes true

[@heru_ur6017]

Never happening

[@ArcaneDgR]

o7

[@TrueManu]

Would the game came faster if CR wouldn't pay himself or his brother 500k a year each? Who knows. Good for them, hopefully once the belly is full than some work can be done.

[@r0yalew1thcheese]

I hope you don't take your opinion as fact.

[@TrueManu]

What opinion?

[@r0yalew1thcheese]

The comment you posted

[@TrueManu]

@@r0yalew1thcheese You are wrong. Go read financial report mr dong.

[@r0yalew1thcheese]

I did read it, where does it state this?@@TrueManu

[@fingazblank]

He's probably on 150k a year and can't even get a decent mic let alone a decent internet connection

[@CMDR_Scorpion]

Super interesting chat from a nerd perspective, gaming perspective and just in general........