Star Citizen: Network Engineer on Server Meshing (Part 2)

A slightly deeper dive into the topic from the Server Meshing video.
Still nothing interesting to put below the fold on a description, but this is the second video....so on the way!

[@loganwolfram4216]

Such in-depth and informative overview. Not hard for a layman like me to understand.

[@eltreum1]

Your data model is fairly accurate, we saw it at Citcon. The green bound containers do not exist, they are part of the parent node itself. Every physicalized object from a pop can to a planet is a node. They are using tree graph instead of mesh because it's easy to corrupt data in meshes if you want to change parent/child relationships real time and have a bug that twists it into a pretzel. Nodes can have many children but only ever one parent, so you only remap one nodes parent and all its kids come along for free instead of updating relationships per item. There is also plenty of understood established math for tree data integrity safety. Santon is a root node that has a star node, jump points, Aarons halo, and planets as children. The planets own its surface objects and containers that make points of interests and owns its moons who own their stuff. Today our game server has authority over the Stanton root node coordinate space and all its children. Pyro has its own root and world space coordinates and child containers. Jumping is a mini-map local driven mini game loop to keep us busy while the scene renderer unloads one system, transfers authority to the next systems root node server or delegate in server meshing and loads the new objects for where we land and lets us exit the minigame in the new space. Most game engines solve coordinate and accuracy issues by having a world space coordinate system and a local space system that covers your max draw distance from your point of origin. Not sure if SC is doing it that way, just know of the 64bit world space they talked about. Server instances will be delegated to drive nodes and all their children lower than the root level probably starting with planet and moon level. They will also read only sync their direct adjacent server instances along the borders so the object data and position is already cached and server starts caring about it once it's in its area of control or does something that affects its area. If I shoot a gun at someone those are ray casts with their path/endpoint pre-determined at time of firing vs a physics sim. If it crosses a boundary the server it lands in resolves damage because they both know about the shot and where its going. A physicalized missile is different and more like the penguins in demo and has a node on the graph. Both servers know the position and what it is and state and take over physics plus damage calc once in its area as a child in its containers. Depending on how each server instance talks to each other on internal server to server sync determines what the theoretical scale ceiling is because i/o time and the speed of light have finite limits what you can push through network and system busses with a 64bit processor per second. If you want 30 fps server sim tics that's ~33ms per tick to get everything calculated and resynced to clients that have a 60-90ms average latency from the internet. It makes predictive approximation math dodgy if too much is moving between ticks causing desync and rubber-banding. What we may see as initial bugs is instead of desync per player whole chunks of players could at the same time depending which side of a border they are on in a fire fight. I think they will make areas larger than a clients max draw LOD unlike their Citcon demo. In the data center we have fun things like DPUs and RAM servers now to handle networking and routing offloaded from CPU for lower latency that is OS independent from server CPU. Blade servers on a shared backplane would be fastest and be able to scale large but spendy and power hungry. Instances on same bare metal in separate core/threads would be the fastest internal sync and efficient but worst scale ceiling from a shared CPU bus and memory controller. Being this is an AWS service they likely get no control of hardware profiles and at the mercy of AWSs architecture.

[@tingil8439]

Very cool! Been working as a dev, mostly with web applications and distributed systems over the last 18 years myself, but I still very much appreciate you breaking this down. :) Just one note on the 64 bit coordinate system, if I may (I am no game dev, so I am taking what CIG communicated at face value here): CIG said they want a 1 millimeter (0.001 meter) precision for their coordinates and using a 32 bit coordinate system they'd get that precision only up to a play space of 8km*8km. That's why they had to switch to a 64 bit coordinate system for SC. So what I understand from that is that every star system will have its own coordinate system, with the star being at the point of origin (or at least close to it).

[@rayfighter]

Yes. For me doing archvis for ..ever.. dealing with AutoCAD mad precision sources imported to 3dsmax, this understanding became a second nature. One either can have the detail, or sheer size, and you have to trade between the two. Enlarge your scene too high, and you bump to being unable to move your little cup less than cm jumps around.

[@crispy9175]

Couldn't agree more. Really drives me nuts how many people call the game a scam or complain about bugs in the pre alpha without any consideration to how radical the foundation of the game is.

[@rayfighter]

for me, even without huge numbers of players crammed at the same small space, which is my least worry because in scenes like IAE expo hall, the truth or precision of the crowd of rabbits mindlessly shifting around just doesn't matter, and in space battle, I cannot recognize any of my teammates above some quite small range either - so I'm ignoring EVE weirdos and their wet dreams of thousands of players in a nonsense meatwaves.... But again, even without any of the above, CIGs approach to not fake anything, just makes Star Citizen experience like no other for me. All the other games feel like faking toys after this. Smoke and mirrors, fakes and rails, and loading screens, everywhere. In single player games! Not even multiplayer! I mean common "gamers", grow the fk up 😂

[@SpaceDad42]

Lol

[@logicalChimp]

I'll add comments as I watch... FYI The 'Microtech city' is called New Babbage :D Regarding your first decision point (the coordinate system, ~2:00) - iirc CIG have said it's a separate coordinate-system per star-system, with no ability to travel between systems except via pre-defined Jump Points. A 64bit Coordinate setup is sufficient to model our Solar system at 1:1 scale - but in-game, CIG have scaled star systems to 1:10, because some of their planned star systems are *far* bigger than Sol. The Jump Point also acts as a 'hidden' loading screen, as it allows the client to e.g. completely unload the 'Stanton' container, and load in the 'Pyro' container. Regarding the 'bounds' - iirc each Container has its own separate 3D Coordinate system, that gets 'nested' into the parent system. All the nested coordinate systems share the same scale - so e.g. 0.0.0 in the 'Crusader' container could correlate to e.g. 1234.6543.10 in the Stanton system... and if you e.g. moved to 3.4.0 in Crusader, you'd be at 1237.6547.10 in Stanton. CIG discuss this quite a bit in the old Bugsmashers youtube episodes (more specifically, they discuss all the various bugs caused by failing to convert coords correctly to the appropriate grid :p). The net effect of this is that you can be deemed in the 'Crusader Bounds' if you're within the boundary of the Crusader grid... or in more generic terms, you'd be within the 'perimeter' of whichever container coordinate system is the most deeply nested... CIG have referred to this as 'Zonal Coordinates' or the Russian Doll / Matryoska Doll coordinates. Edit: quick addition to the above - a 'Container' in CIG terms is the foundation of their Object Container Streaming, and the foundational element that makes the Graph setup work. Each node in your simplified graph would be a separate Container... and the Container defines the 3D 'space' that all its entities take up, and where they''re placed relative to each other. In the space port, it's not just the hangars that are child containers - every room is a separate container, and it's likely that e.g. each 'floor' in the spaceport is a containerr... it's *exceptionally* heavily nested.... but this is also what lets them e.g. have 'proper' rotating planets for day/night cycles, without completely bogging down the server - they don't have to keep 'moving' every single entity on the planet every frame - they just 'rotate' the parent container (e.g. Crusader Planet). Thus, if you were standing at 3.4.0 in Crusader, and Crusader rotates 90 degrees, you'd *still* be standing at 3.4.0 in Crusader... but if you translate back to 'Stanton' coordinate, you'd now be at 1230.6546.10... hence the importance of being 'in' the correct 3D Coordinate space for your current location. Regarding the complexity of hand-offs and e.g. 'missiles hitting ships' (~9:08) - at this point, you appear to be comflating the Graph data model, with the processing of entities. Under Server Meshing, a single 'server' can be responsible for multiple 'zones' (or Boundaries, as you've called them)... at the simplest lest, if a server is responsible for e.g. 'Microtech (Planet)', then it's *also* responsible for all the nested containers / boundaries within it (unless that nested container has been explicitly off-loaded to another serrver). Thus, one server might handle MT (the planet), New Babbage (the city), NB Spaceport and hangars, and so on... and a separate server handles the Convention centre because IAE is active.... and because entities will have their 'parent' Entity updated as soon as they cross the 3D Coordinate boundary, the server that handles the processing will be the one that handles the Zone the entity is currently in (although CIG will likely need to set up some basic rules to handle the vanishingly rare possibility of a collision happening *perfectly* on a boundary edge).

[@MrTybio]

Thanks for the comments, I totally agree I was conflating things and posted Part 3 just a few minutes ago to try to clean that up. Do you have a source for the coordinate information? Not that I question it, I'd just love to go get it from the source so I can expand my knowledge! I wasn't aware they had addressed that. If you don't, no worries...I'll go googling until I can find it. I appreciate the care and detail you took in adding your comments, I'm going to make sure to dig into each one and refine my messaging.

[@miguelhidalgo9372]

Whewie! Great discussion and sensible constructive comments. As stated in the previous video, keep going!

[@yous2244]

Well even if Cig said something before it is subject to change

[@logicalChimp]

@@MrTybio No unified source, unfortunately. Most of it came from e.g. older ATV / ISC episodes, and dev-posts in Spectrum (alas, Spectrum Search will only go back 2 years, so you can't find older posts). Best bet would perhaps be to look at some of the Bugsmasher episodes where Mark fixes related bugs, as he tends to explain how the coordinate system works, in order to explain the bug, and the fix.

[@LuismaLorca]

AFAIK it's a separate coordinate system per object container (actually per zone because not all object containers are zones but all zones are object containers). So when move a box from space to ship, the relationship includes the box coordinates within the ship zone/object container. And yes the root, the world coordinate system, is the system, so essentially moving between two systems would be the same as moving between for example, two docked ships, just that there isn't anything above then hierarchically speaking. I'm actually curious how they're implementing the jump gates specially. Will it be a third world separate from the two connecting systems? Will be split in half between the two? Or handled entirely by one system up until the point the ship exit the wormhole and is acquired by the next system? Maybe in the future they want to make alternate routes inside the wormholes (like bifurcations within the tunnels) to different systems or even exits within a system so jump points ideally would be their own "system" adjacent and independent from the connecting systems.

[@Gibby0825]

CIG is not only making a game, they’re making advancements to gaming technology that so many others can benefit off. It’s really wild that they’re making and as a backer/ player it would be so awesome for them to pull it off. Really appreciate you taking the time to explain this to less tech savvy people like me. I’ve participated in a few 50vs50 org battles at ghost hollow or jump town with org leaders communicating with a dev to let them know what we’re doing to hopefully help them gather on a stress test. Makes me feel like I’m doing my little part to help them develop this

[@realnerdethan]

Your explanation has really helped me understand the magnitude of the goal they have and how complex a problem it is to solve. Thank you!

[@bitmau5]

Caught your first vid on Mikes channel, catching this here. Subbed. Great breakdown, thanks!

[@Hav0k]

Love the explaination of how complex this will be and how industry changing this is. It really puts things in perspective with why they're taking so long to implement it.

[@Ultrajamz]

The shard “matchmaking” system will be crucial also, and they need to incentivize people honestly friending/orging with people to avoid gaming it and also I worry an entire org can “claim” a planet’s shard and get risk-free mining in that area for example.

[@TheNefariousFox]

Yeah, I don't think you understand the technology yet. Proximity will dictate who you see, and only when you have too many people in one place will they have to "balance" how many and who see's who. Which is unlikely to matter in most cases. There is no "matchmaking" system. Not until you get to the point where there's so many people in your vicinity that they will have to compartmentalize. Planetside 2 did a lot of this. There was no matchmaking, and really CIG doesn't even have to do that. But they do need to ensure that the fights stay balanced, (or imbalanced) at the appropriate proportions. Stop focusing on the least important aspects of the tech. It's not going to "matchmake" for you. "Shard" is the wrong term. This is not shards, and not instances in any way that you can relate to. It's all one big system. And you'll have to deal with all of the people in it, better than you or not. --- In the shortest timescales for meshing release you can expect that they will have a non-dynamic system that will have to make such choices, but that is only in the short term until they can scale and compartmentalize their graph into however small or large needed. This game won't have matchmaking. That's is an irrelevant concept to the technology they're building.

[@Ultrajamz]

@@TheNefariousFox not irrelevant, I am using “matchmaking” since thats a known term, but I don’t think proximity should be the only factor or else it will be way too easily to game the system and hard to ensure you see your friends.

[@TheNefariousFox]

@@Ultrajamz, Irrelevant because it is a very minor detail, and not significant to the problem. It's so easy in comparison, it almost doesn't matter at all. Unless they don't do anything, which is entirely unlikely. So yeah, it's kinda not worth mentioning, since it doesn't matter to server meshing problems.

[@ctzn3lack]

Great breakdown. 👍

[@Rollsta47]

I feel the exact same way about your statement at the end... could not have put it better myself. Hope you make more videos, even if you have to branch outside of networking I think you might have a unique perspective. good luck.

[@marcoweidner1805]

Thank You for the 2 Vids about this overimportant Topic. :) I wish You will make more about it in the Future.

[@EntityVII]

These videos are so interesting and easy to understand. Subbed

[@talon2000uk]

What you call bounds is what CIG call Oject Containers. These are a hierarchical/nested set of containers ranging all the way down from the main Obect container of stanton all the way down to say a pair of pants that you are wearing. They are are nested one in each other so say a bottle of cruze would be nester in your pants which is nested in you character which is nested in your ship which is nester in your hangar and so on all the way up to the main Stanton Object container. These object containers are mirrored in the graph database on a 1 to 1 relationship. So when you move object containers when leaving a hangar you move graph nodes from Hangar to Microtec on the graph. One thing to point on is that some objects will eventualy have their own seperate stats such as wear but these will proabably be applied as a transform to a primary object type. I hope that makes sense.

[@fingazblank]

Thanks man. It helps, I can at least be proud of the crew doing this game when I have to defend the game from my wife. They are changing the world woman and I am part of it.

[@0WaxMan0]

Thanks for putting up an extremely rational and considered discussion of what the technical leaps we are seeing them make, so much of the real break through stuff being done is not visible and we can only infer, what most people are seeing is detailed star ships and glitchy NPC's missing all the foundational work being done that has just never been attempted by any one else. Think about it almost every game around relies on the engine developer to make the tools they use to make the game I know there is still a lot of custom code involved for everyone else but did any one else create nanite? or just use it when it was made available. What jumps to mind when thinking about cross zone interactions is to replicate the nodes (in the example the ship) to 'adjacent' branches (server/zones/instances) and have some intrinsic sync hierarchy and probably various update frequencies for various node properties and subnodes to then stream out to clients interacting with the node in the other zones. Possibly taking lessons from distributed nosql designs, this being a big part of what i think the coordination services will be doing. The sync between node copies is of course going to be extremely sensitive to be causing lag, but if you are planning to do this from the bottom up does give them a chance to be able to get this working.

[@themando-smith]

I will watch your career with great interest. But jokes aside. Great video. Great explanation and great start. (also cool to see good constructional criticism and discussions in the comments. For the video I'd recomend having an eye on where you take cuts and either line em up on cut or to cut the audio line to the right or left of the cut depending which picture is more on topic (called J or L cuts). But details. You'll get the hang of it quite fast I guess. Happy to see a new face that I can watch, especially with such topics. Keep going and have fun creating.

[@R1po]

Amazing video. Those questions around the 8min mark bothered me too. And I'm no Network Engineer or Developer. But the sheer scale and complexity were obvious and seemed unfathomable to me. I researched a bit out of curiosity and learned something like this has never been done. That's when I understood what a milestone in gaming history this could eventually become. And while my patience isn't endless, I understand that something like this takes time. I started gaming in the 80s-early-90s. I've seen monuments in the gaming development.

[@Mr_Beaubles]

Omg, agreed with your conclusions 1000%!!! I've worked in networking and as a sysadmin for 15 years, and I extrapolated the impact their server meshing tech would have on the entire gaming industry, and maybe much more just like you did! Finally, someone that understands!!! Being able to seamlessly devide any virtual space up across many different physical and logical machines for many, many people is basically the holy-grail of game design. They're going to sell that with StarEngine to everyone and online games will start getting bigger and bigger. Population limits of servers could be immensely increased, or maybe even virtually eliminated! I have been losing my mind ever since the citizencon demo ever since. Again, I think you are exactly right in your conclusions, and yes, grouping up into large groups during the replication testing will definately be the best way we can assist them in gathering the vital data they need to make this work!

[@everettumphrey]

Nicely explained.

[@user-ux9sm8hq6s]

lol. im a old backer but my knowledge about this is far from your knowledge. But you do explain it very well even i got the feeling i understood it. so thank you

[@sc_cintara]

Regarding the 64-bit precision, larger containers in SC have a nestable "zone"-system. Each zone is a freely movable coordinate system in the game engine and a movable container can have a zone. For instance a space ship can have a zone. When players go into a space ship their positions are calculated relative the space-ship zone and are no longer updated in the global zone. This way the ship can move in a complicated pattern without updating the location of all the players and items inside the ship; only the ship coordinates are updated and because the players and everything inside it are relative the ship-zone, their locations get updated for free. The zone system is essential to enable things like rotating planets with many millions of objects. You can build an affine transformation matrix that collapses any depth of nested zones to a single matrix multiply by the transformation matrix, so moving between zones can be done very efficiently and you can chose at cheap cost what zone you want to compute an objects' movement in. The coordinate system in the zones is 64-bit, probably because the global zone had to be 64-bit to fit a whole solar system at sub-millimetre precision and that meant that all code had to be 64-bit anyway.

[@j.d.4697]

I don't think CIG can be judged purely based on SC because they are working on SQ42 too, and mainly so, from what they have been saying. SQ42 can't be judged at all yet, but it's worth keeping in mind.

[@MrTybio]

Oh, I agree. I think that things dramatically improved starting about when they made that announcement that SQ42 was the priority. It helped set expectations, but they've still had issues with communication...even if they are getting better.

[@Bitfire31337]

1:53 "I would assume it's a complete coordinate system, otherwise they wouldn't need a 64-bit number." Let's do some math and see, what we can fit in 32 or 64 bit coordinates. Beware: Lots of big numbers ahead! I'll use the dot as decimal seperator and comma as thousands separator as usual in the anglican world (tell me if I mixed something up). First off - 32 bit (or 4 byte) can hold 4,294,967,296 different values (2^32 or about 4.29 * 10^9, i. e. 4.29 billion) while 64 bit (8 byte) can hold 18,446,744,073,709,551,616 different values (2^64 or about 18.45 * 10 ^ 19, i. e. 18.45 quintillion). Now, space is large. Like really large. Here are some rough sizes of things in space: diameter of the Earth: 12742 km avg. diameter Mars orbit: 4.56 * 10 ^ 8 km avg. diameter Jupiter orbit 1.56 * 10 ^ 9 km distance Sol Proxima Centauri: 4.25 light-years or 4.02 * 10 ^ 13 km Diameter of the Milky way: 87400 ly or 8.27 * 10 ^ 17 km To find the precision or resolution (i. e. minimal distance between two separate points in space) that is possible, if we want to fit each of these things in our coordinate-system, we need to divide the latter by the former. In a 32 bit system, this gives the following results for the minimum *resolution* of each map: Earth: 3 mm (might just be usable, though CIG wanted 1 mm precision) Mars orbit: 106 m (obviously not practical anymore) Jupiter orbit: 363 m (yeah...) Sol + Proxima Centauri: 9360 km (*cough*) For 64 bit on the other hand, we get: Earth: 700 femtometre (700 * 10 ^-15 m, about 1/100th the size of an atom) Mars orbit: 25 nanometre (25 * 10 ^-9 m or 1/20th the wavelength of light) Jupiter orbit: 80 nm Sol + Proxima Centauri: 2 mm (still enough, but if you add some more distant star systems, this quickly gets to large) The entire Milky way: 45 m (not gonna work for SC, but probably viable if you only simulate astronomical objects) *Conclusion:* You need 64 bit coordinates to simulate anything bigger than the size of the earth. But even this is not enough to fit multiple star systems in realistic ditances within. Using 128 bit coordinates, one could map the entire Milky Way with 25 nanometre precision. That would be an incredible waste of ressources though, since computing 128 bit numbers on the current 64 bit computers is very time expensive and the space between star systems is incredibly empty.

[@MrTybio]

Good context, I admit to just short-handing that in my head and obviously getting it wrong. I'm not sure where my mental math failed, but given what you showed, 64-bit per system makes sense.

[@vast634]

As fas as I understand their explanations: there is a single large replication-layer-server (database and processor) that holds the object state, parent-relations and who (server) is responsible. Player-Clients only interact with this replication-layer to get the current object state and send their actions. The replication layer does not need to process complex logic like AI, pathfinding, physics or scripts. Its just a fast data transfer and storage server. Then there are many "region" servers, that hold ownership over objects in their region, get the state from the replication layer, process the gamelogic (AI, physics, scripts etc), and send back state changes to the replication layer. The regions in the convention presentation where those tree small sections of the room, but in reality would be things like a whole station, a settlement, a complete moon, a capital ship or just a part of a station. All dependent on the expected population count. If a server crashes, the replication layer can quickly send the object-state and responsibility to another server on standby, and quickly resume operating on those objects. From the players view, the game would only permanently crash when the replication layer blows up.

[@j.d.4697]

This is fascinating! Maybe what you could do is showing some interesting events in gameplay videos of other people and explain what's actually happening under the hood.

[@MrTybio]

Right now there isn't much I can contribute, it is all on a single server in a single process. However once we start testing Server Meshing in Prereview I'll be sure to jump right in and see if I can provide useful information on anything!

[@adamjohnson2961]

Subscribed. Excellent.

[@ZeratKJ]

This is great :)

[@ultrastoat3298]

My expectation is that at least for phase1, CIG will simply craft these handover boundaries in areas where player 1 sitting on server A would usually not see player 2 on server B. So like the boundaries would be many thousands of kilometers from POIs.

[@TheNefariousFox]

It is my understanding that ships in quantum are not outside of the grid. Therefore the entire map must be held in the graph. So the borders between nodes do not have gaps. This correlates with your observation of a 64bit coord system.

[@MaxPSVR]

Thing is. I don’t think the hangers are that separate at the moment. Yea the hanger doors are tied to the person. Which is why if you had two different people in the same party and same ship. Even if their in the same hanger. They will call to open 2 different doors. The ship and hanger doors are linked to the player. However the area around is all the same. The jabs, the shops, the terminals, the hangers and even a few thousand meters out. Basically anywhere inside the armistice zones. The hospitals have recently been changed to have their own areas and some cities might have different areas like orison’s platforms. But if you went to a LeGrange point like CRU-L1. Then as soon as you get into the armistice zone. That is all one area. (Well except for the hospital for now)

[@Glandorray]

Even if the game turns out to be terrible, the technology developed will go on to be useful in all sorts of other places and games.

[@OneFingerYT]

My educated guess is that every object that can have things attached to it (e.g. sun, planet/station, moon, building, vehicle, person, modifiable weapon) has a local coordinate system, and they are rotated and translated via matrix math (for each frame?) to be within the coordinate system of the next higher level coordinate system, up to the appropriate scope. So that silencer on your P8 is mathed to the gun, to the back of the pilot, to the vehicle being piloted, to the coordinates of Hurston. But updates being sent to other players only need to be sent based on what has changed. If the pilot hasn't left the seat, but the vehicle has moved, only the vehicle's coordinates, rotation, and facing are transmitted. The position of the silencer has already been anchored relative to the vehicle. If the pilot's head moves, that has to be remapped to the vehicle, but the helmet he's wearing does not explicitly get updated.

[@alexanderdooley5833]

per your example of cruz in the backpack, could that inherited attributes be the reason why stacking of objects in game was and still is an issue? Also what issues do you think orbits would impact this kind of system?

[@JaumeSabater]

The reason why they switched to 64 bits back in 2017 or so was because they needed a coordinate system for the whole solar system. It has to be insome video in their KZbin channel, heh😅

[@vast634]

The game is not using 64 bit for local simulation, physics and rendering. It holds the object positions in 64 bit and converts it to local 32 bit coordinate for anything gameplay and rendering related. Simply using all transform positions directly as 64 bit floats would be overkill and cause a bad performance on client machines.

[@dtrjones]

This video while useful to newbies feels like you are still playing catchup to what CIG have already presented on the subject. I guess it's good that you can see the same complications being forsceen by CIG but a lot of the scenarios have been shown off in demos. I would watch the Citizencon panel for server meshing in October last year as well as the videos MyYTUserID has already suggested. If you are doing a video like this again, remember Star Citizen fans will be watching, so it's important to get familiar with CIG's own technology jargon like object containers, replication layer etc as these concepts will also make your presentations easier to understand for the rest of us.

[@MrTybio]

Fair enough, I do admit to finding myself switching to Graph Theory terminology and back a bit....I'll work on that and try to get the terminology lined up. Thanks for the feedback!

[@Exsulator2]

first video is not in the playlist btw

[@davidanderson2567]

Would it be possible, that once you leave a server, then everything in the old server just becomes NPC's that mimic what other players are doing until you step into the same server?

[@0BLACKESTFUN0]

is it realisticly speaking a fluent fps experience , or does it still have the nuances of client sided advantages in a engagment.

[@paulklein8556]

CIG already stated they have there own 64 bit coordinate plane. He also says this when they demonstrated a working server mesh. So, from what I understand they should be on the same coordinate plane from one system to the next. In theory it's easy to hand off data from on system to the next?

[@MrTybio]

I addressed this in another video, I'm unclear as to what the plan is. I know at one point they were talking about each system being it's own bubble, so you couldn't fly from one to the other...even if you were willing to sit around for the months+ it would take to make that trip. I'm leaving it open at the moment until they clarify at some point. The size of the coordinate plane is a relative thing, so we can't know what "64 bit" means without another point of reference. As a stupid example, if each grid point describes a 1mm square.... As to handing off between systems, that would be only slightly more difficult than handing off between containers in the same system...as it will happen a lot less, I think that's likely to be one of the more simple things for them to do.

[@SideQuestStories]

You made it unnecessarily confusing calling New Babbage Microtech lol

[@j.d.4697]

Ahh ok, I asked this in a second question on the other video. I guess my confusion comes from the lack of knowledge on how space is simulated and represented in software and hardware.

[@MrTybio]

I get it, it isn't the most obvious concept. Perhaps look at it this way, there are "Physical" elements to the universe, like Planets, Ships, players etc. Then there is the space they occupy. There is a parallel process to the graph with a coordinate system...like a ship crossing the Atlantic, there is a whole ocean out there, but only bits of it have "Physical" items. So we use Lat/Long to track where things are on earth. In space you need to add a 3rd dimension, X,Y and Z. So think of each physical object having a lat/long/height...more like an airplane actually. When it comes to the data structures, each server has an "Area", likely a cube of space defined by 2 3 value numbers. 1,1,1 -> 10,10,10. All of the space that would be contained within that section of the universe is under the management of that server. If you leave that space, your physical representation (player character) moves do a different server that is managing the new area....but to you it might just be walking off your ship. So Servers manage areas that contain objects. You know, I'm not sure that was at all helpful...I'm trying here!

[@Luredreier]

1:19 I assume that you mean Area 18 and not Microtech city?

[@MrTybio]

New Babbage actually, that gaff is going to stick with me forever!

[@Apocalomega]

Well explained, but damn if it didn't get boring after about 10 minutes. Not your fault though, you were explaining great.

[@forcedtoexist6221]

Possible to put it into context of the eve-online server?

[@sevilnatas]

I hope they are taking 30 years of experience and building on it. This is the achilles heel of capitalism. The concept of "standing on the shoulders of giants" is massively great for human advancement, but there is no economic benefit for corporations to allow others to stand on their shoulders.I often ponder how many great advancements have been lost or the possible advancement made impossible, or at least massively delayed, because it was part of a knowledge base, belonging to a company, that either decided to not pursue it or went out of business. Do CIG devs have access to the wisdom of the devs that preceded them in this endeavour? Can one find out, from prior attempts, in other companies (WoW, etc.) where the pitfalls are, what works, what doesn't work? Or are the condemned to try it all over again, making the same mistakes, going down the same dead ends. Having short term successes, not knowing there is a landmine waiting for them around the corner, stepped on by many others, before? Really, the only current path around this problem of knowledge sequestration is via either stealing away employees from other companies or hiring them after the original company has gone out of business, and technically, the knowledge they bring is ip belonging to the prior company, even though we all know this is the way many advancements are made today. Imagine the advancements that could be made, if only ideas were freely exchanged, for the betterment of mankind and for gamers, especially! ;-)

[@0WaxMan0]

And this is why despite feature creep and delays etc. i don't want CR to stop what he is doing. Server meshing is just the most visible paradigm change, working from the ground up to make all parts of the engine be 'Dynamic' and reactive and not rely on hardcoding is not the easy option (and why there was a big delay a few years in when they realised just how far the needed to go down the rabbit hole). My favorite example was when they rebuilt the character movement to be able to use Animation, motion capture and IK as well as blend between any different sets and with that they could switch actions and movements at any point no action lock-in etc.with that work done there were a ton of downstream benefits. As Tybio said I want to see more games using the star engine and accessible in game via sim pods just like Arena Commander is supposed to be, having my space man login to play a wizard in an ingame-ingame MMO.

[@sketchtherapy1218]

More please. o7

[@OrniasDMF]

Couldn't they solve a lot of server boundary issues by making sure the boundaries are in deep space, or as close as possible to it? Having a boundary on a hangar door seems like a bad idea, compared to putting it 20km away in a desert, or half way to the closest moon.

[@georgemoonman2830]

I think you think they are going to have separate servers to a much lower level of granularity than what they are actually planning. Dont forget the final game will have mnay multiple systems, so players will be far more spread out than current where everyone is in a single system.

[@MrTybio]

My hope is that as this is implemented we will find that they can increase the population. Kind of pointless to have these Capital ships if our server limit is still 100. I've been expecting a modest increase in player density as we move forward in the Alpha...with hopefully a much more populated universe by live.

[@findern2arm62]

Concerning accountability I wish they had made it more clearer that they were doing this in the background but they were focusing on sq42 before the pu, that's why I believe there is an opinion that this is some sort of scam, had they marketed it in such a way things would appear better.

[@jomo3564]

They have been very transparent about this

[@elsilossos626]

Now I want to buy CIG stock…

[@Tsudico]

If you haven't already, I would highly suggest looking at the _Unofficial Road to Dynamic Server Meshing_ because it includes a lot of detail including the sources for that information. It might help you better understand the specific plans of CIG or where to find out more information regarding specific aspects of CIG's plans. When you talk about the missile at about 9:00, the way you talk about it makes it seem like you might not understand how CIG plans to deal with entity authority, especially when it relates to the dynamic mesh. I think CIG mentioned in the talk at the last CitizenCon (with the 3 rooms demo) that object containers with a certain flag would be considered entity zones. Entity zones appear to define the smallest unit of physics area that a dynamic game server (DGS) can have authority over. The demo showed that the dynamic game servers could have authority over multiple entity zones and showed that servers could also load entity zones that they didn't have authority over but that were neighboring because the neighbors might have entities that would cross into the server's authorized zones. This means that DGS can have entities that are projected to enter their zone loaded in advance so that all they need to do is flip which DGS has authority over those entities. The replication layer then only accepts physics updates from the authorized DGS. I think this solves the missile hitting the ship and portions of the ship getting blasted into the hangar. The missile is easy because it likely is a single entity and so transitioning zones is fairly simple. It might seem that the ship being a complex entity graph that must now spawn multiple other entities with their own graphs for each portion of the ship would be more difficult, but they indicated during the Maelstrom presentation that the ships will have a graph of the extents that the ship can be broken up into so the neighboring servers that have the ship loaded should have that loaded as well. The DGS with authority over the ship just needs to send the portions of the ship graph that changes. If any of the portions have positions or velocities that would cause those portions to enter any of the neighboring DGS, like the hangar, then the authority is flipped appropriately for those entities. Honestly, this doesn't seem difficult to me because Second Life and OpenSimulator have versions of server meshes that create entity "ghosts" on neighboring servers and do an authority transfer when the entities cross the border. They don't, or at least didn't when I last worked on OpenSimulator code, use an entity graph and I think CIG made a good choice putting the Replication Layer/Hybrid Service between clients and servers unlike previous meshes because it separates what clients need to see compared to what servers need to see and allows optimizing for both separately. It will be interesting to see how far from entity zone borders CIG will start loading entity graphs on neighbors but I think one of the reason for all the elevators, trams, and the jump points themselves will be to restrict player movements in known ways is to gather data on how quickly complex graphs can be loaded.

[@TruthIsKey369]

CIG should let the lead tech head to make a indept overview for the backers. Not to give away propriatery tech (which the likes of Microsoft should pay through their ass if that would be the case later). This tech can truly set CIG on the map, and IMHO make other type of games inhouse to take advantage of this FULLY! True seamless worlds regardless of game genre, and making a insane coop adventure would be easy with their game engine. Like Ratchet and Clank is a very cheap imitation of world hopping and transitions, it's laughable in comparasion. Not to mention Starfield..... Yelp! Endless possibilities!

[@toddbair9347]

They've already made tons of videos, and recently. They just published an engine demo that's essentially an advertisement. They're 100% going to license this thing out at some point, especially since they seem to be out from under Crytek and Lumberyard.

[@joeheeney4821]

Yes there is a universal coordinate system, I remember this from years ago. Sorry I do not have a reference. I don't think that CIG has done this badly. I think you are just disgusted from having seen the sausage being made for the first time in your life.

[@MrTybio]

Not at all, I make sausage everyday in my work. Hard to avoid it in the tech sector! I do think they have had issues with communication and have stumbled. I don’t hold it against them as people in any way. I think that’s fair myself. Thanks for the comment!

[@joeheeney4821]

@@MrTybio Oh absolutely communications stumbles and some bad turns in the dev process, but that is part of the process when you are trying to exceed all previous limits and pioneer new levels of technology. I do not hold it against them. They are all products of their industry trying to re-invent themselves into a more ideal image, It ain't easy reforming your self image.

[@davescott7680]

It's coordinate system per system. So Pyro and Stanton is not using same coords. In the graph, I'd have each system as seperate connected graphs.

[@D.Enniss]

I can't stress this enough, it really hasn't been a long time, CIG started out of nowhere from a basement with about a dozen people, they already made many breakthroughs in graphics and technologies for their Star Engine that don't exist anywhere else. Then not only they're doing a revolutionary MMORPG they're also doing a single player game, all the while they grew up their company to over 5 studios and over 1300 developers; CIG has done excellent work in the allotted time with the funds they've had, I'm not defending them or wtv, *I know* how hard it was to get to this point. Really if anyone reading this comment doesn't agree with it, just think about it for a minute, doing all I described above and starting all of that from a basement with a few of your friends. *_Do not undermine their endeavor_*

[@ceb1970]

I'm a bit concerned about some of this being subject to hammer and nail syndrome, where everything looks like a nail when all you have is a hammer. You're coming at this from the perspective of a network engineer, and I'd love to hear more about the massive challenges CIG faces related to networking between the Dedicated Game Servers (DGS), the Replication Layer, and the players. I'm far less interested in hearing your explanations of how object streaming and physics zones work and interact with each other because this is outside your area of expertise and your "hammer" explanation may not be entirely correct (and, ahem, could be totally wrong). In particular, I think soneone with your background may be able to offer useful insight into the network changes implied by the introduction of the Replication Layer. As you know, without the Replication Layer, the various DGS's in a mesh would need to communicate between themselves to coordinate server authority and pass information back and forth about objects that are under authority of one DGS but visible from the context of other DGS's. Then each DGS needs to communicate with the players connected to it. That's all a lot of complex network traffic. With the introduction of the Replication Layer, much of the complicated network traffic is simplified as each DGS communicates with the Replication Layer, and the Replication Layer communicates with the players. Each DGS no longer has to communicate with all the other DGS's and connected players. The network implications here are huge, and this is what I'd personally like to hear your thoughts on.

[@Blight-fp3vt]

Hmm. I dont feel like anything you are talking about, or the stuff from RSI hasn't been done before. The issue for them is that they had nothing pre-existing, so its a ground up build, and the scale of the entities and players they need to persist is very very large. The size is what requires that last step of server meshing (again, nothing new), and with the number of systems they have had to create from scratch they have been clearly trying really hard to make all of those systems scale together as part of that. Its a big bang approach in a (forced?) way, which can be excellent given enough time and good management, but you can really imagine all the points along the way when one set of technologies and systems will have required a rethink of the other systems and work starts again, rather than say a simpler starting system and making it live and having it evolve. Of course evolved systems have their own issues (ie, some hard limits will just be intrinsic to the initial simple system), and in development once a feature is 'released' its hard to go back to basics again and change it due to the lack things to motivate that recode (its done, lets move on to simpler things etc.).

[@forjo]

I think you need to equivocate less. You seem to recognize the enormity of what they are trying to achieve while at the same time passing judgement without actually being there. The simple fact that they are human means that mistakes were made. But too many people are too ready to classify whether those mistakes are reasonable or the result of mismanagement or something worse -- without actually being behind the scenes and knowing what went into each decision and each "failure". To say you will hold them accountable for "doing it badly", in my view, is out of line. We haven't seen droves of people quitting CIG complaining about mismanagement and bad decision making. Yes, there are the few; but even the most well run business will have a few employees who for one reason or another leave with an axe to grind. No, what we've seen in a level of dedication in a work environment that, for better or worse, seems to encourage doing the impossible -- even if it's beyond some original scope. Thank you for your insights and please continue to share your unique perspective. But I ask you not to follow the heard in arm-chair quarterbacking.

[@Ynterianel]

Comparing SC to iphone is just insulting to SC.