http://preview.redd.it/enqgpxgafxg51.png?width=426&format;=png&auto;=webp&s;=90e561b644d23eb4146fa5cc929d60cc9735f41e Thought it might be useful to old and new backers to create this post which takes you through some of the key technical challenges CIG has faced and are still facing, including a description of what they are (in layman’s terms where possible). Be prepared, ‘get snacks’ for a long read.
The original post has seen a lot of input from the community, so I would like to just say a big thank you for all your input! Because of this I’d like to make this a running topic, I shall continue to update it as time goes on, whether that be updating the original threads or starting new for visibility and maximum community input (unless a mod wishes to sticky it).
I’d also like to invite any CIG devs to weigh into this post and clarify anything that we may have got wrong, or indeed if they’d like to flesh out any points with any contextual examples, I know they would be greatly appreciated.
Caveat: This information was put together by the community, trawling through CIG videos, dev responses, youtube creators etc so I cannot promise it’s 100% accurate, in chronological order or indeed manages to convey just how difficult these technical challenges are.
64 bit float precision & Camera Relative Rendering – In Game CIG made a move from 32-bit to 64-bit precision within the game engine, as 32-bit limited them on the playable size of the game world. 32-Bit is often used and ok for smaller worlds that span several kilometres. However, CIG clearly had the issue where they needed to provide detail from close up i.e. in your cockpit/ship all the way out to a distant planet and beyond. This of course cannot be faked with a backdrop or boundary in this game, if you think ‘hey I want to go there’ you can.
“Cryengine (and the majority of game engines in general) track position in 32bit floating point precision. The further away from the origin of the map you get, the less and less precise your location becomes. Because of the way floating point precision works, you basically start getting to the point that you can't move an inch at a time anymore. It becomes 2 inches and goes up and up until you're moving 1 foot at a time, and more till you're moving a mile at a time. This causes objects to jitter around all over the place as if it were trying to figure out where they ought to exist, here or there, because no in-between spot exists.
Object location in most engines are rendered in absolute terms. That is, it's exact position away from the origin of the map is what is passed into the renderer, and that's how it gets rendered.
Problem being, GPUs are good at 32bit float precision and FP64 isn't just half the performance of FP32, more like 1/20th or worse so basically unplayable. So how do we get around that?
Well, 32bit is MORE than enough for rendering if the camera is at the origin of the map, but what if the origin of the map was always where the camera is? So that's "camera relative". CIG rewrote the renderer so that when it is time to draw a frame, they translate their absolute FP64 position to FP32 with the camera as the origin. Since this is only used for drawing and not physics, it doesn't cause problems. Everyone is the center of their own rendering world and now our performance isn't hamstrung but we have very accurate sub millimeter precision out to solar system sizes.
Here's a little blip about it in an old monthly report:
The main task being worked on Large World this month was making the rendering Camera Relative: in fact the move to 64 bit required all rendering code to be changed to be relative to the camera and not simply in absolute world coordinates any more.
http://robertsspaceindustries.com/comm-link/transmission/14758-Monthly-Studio-Report-May-2015”
Source Reddit: wkdzel
Physic grids – In Game – Will be iterated on to scaleup Physic grids were implemented to calve up entities in the game world into their own ‘grids’ for them to behave independently from each other, allowing for players to behave as per the grid they are within. For example, a ship orbiting a planet at speed would have its own grid so you could get up walk around inside regardless of whether you were moving in the game world at 1000m/s. In the meantime, a player on a planet could look up and see this ship as they themselves move separately with the rotation of the planet (as they are part of the planet grid).
Bind culling or Serialized Variable Culling – In Game Bind culling was introduced to improve server performance. It works by eliminating the need for the server & network to have to update entities that are far away from the player.
Client - Object Container Streaming – In Game Before OCS was introduced, both the client and server had to track all items at all times, whether it was near you or not. Client-OCS was introduced initially so that only items you interact with/near are streamed into your client, which meant your machine only has to stream in items it needs, thus improving performance. However, the server still has to track everything.
Server-side - Object Container Steaming (SSOCS) – In Game This is the desired state for OCS, it would effectively mean that neither your client nor the server has to keep track of everything in the game which is not being interacted with. For example, an abandoned ship where no players are near i.e. no interaction, is saved in a state until a player or interaction with it takes place, at which point the server would stream these saved states back into the game. An example given by CR was that a player could land on a planet and drop their favorite mug on the ground by a tree. Once that player left, that mug would be saved off and not actively tracked by the server, when the player drew near the server would stream that item back in. The idea behind this is to improve server performance drastically by the servers not having to track all items all the times.
ICache – aka Item Cache – Actively being worked on ICache is a new breed of database being designed to optimize querying of items in a scalable fashion, whilst also using best practice for fault tolerance and recovery. For example, all nodes have their data replicated in the network so even if one goes down a new node can be spun up taking its place ensuring data isn’t lost.
Global Persistence – Actively being worked on Is part of SSOCS, global persistence is the added funtionality being developed to load in and out the state of items. ICache is the data base it queries and thus relies on ICache being implemented first. Here are a few examples that have been given on how Global Persistence touches so many areas of the game. “we can explore gameplay that can permanently or on long term scales modify locations in the game, for example space station damage. Port Olisar could suffer an attack on a shard and it would be damaged for some time until repairs could take place. This would persist even if the serveshard went down as it is no longer just in memory state. There’s a ton more, such as full server recovery after a server crash. People often complain about losing cargo after a server crash, as we can’t get players back into their ships right now after a server crash, unlike a client crash where we lose the state of the server. With global persistence this will be recorded in the shard record it was associated with, so quickly we spin up another instance, it recovers the shard record, then we can use matchmaking to get players back into the shard they just lost connection to, and boom, they’re back in action right where they left off.”
http://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/where-is-icache-and-physicalised-inventory-at-now/3033094 Physical Inventory – Actively being worked on The move to physicalised inventory is to remove the Mary Poppins style bag that has everything in it, no mass or size restriction. It’s not just for realism reasons. By physicalising inventories they themselves become persistent entities with state. Which means they could be left inside a ship or under the base of a tree on a planet, they are no longer arbitrarily tied to the player. Physical inventory requires both ICache and Global persistence above in order to work.
Static Server Meshing - Actively being worked on The idea behind Server Meshing is to move away from a single server as we have it now (with a limited cap of 50 players) by dynamically spinning up and down servers based on the population of an area to allow for as many people in a location as needed. The first intended stage of this is to introduce Static server meshing. This means the game world is served by multiple servers, these servers would be dedicated to run certain parts of the game world. For example, one server for each planet. Each of these servers would communicate with each other and you’d seamlessly move between them as you traversed it. The added step beyond this to implement recovery, i.e. the server looking after Crusader dies, everyone in Crusader would get a 30k, but would be given the option to spawn back into the world just as they left it on a new server which had just spun up in the background (iCache & Global Persistence) All players outside of Crusader would not be impacted.
Dynamic Server Meshing – “Working on it” via proxy of Static Meshing This iterates static meshing to the desired level, no longer do you have servers serving static parts of the game would, instead the system works dynamically to create as many servers as it requires to manage parts of the world determined by the player count and interactivity. Therefore, any object container in the game can theoretically become a server based on the player population. One of the goals is to potentially have a global server (depending on latency across the world) where every player is effectively in the same universe. It works by dynamically spinning up servers and share what’s going on in highly populated areas, relaying that information to each other and back to the client as if it were one giant server. FYI This also helps remove servers from running in areas of the game where no one exists. For example say Port Olisar has 300 players at its location, this may be split up by several servers performing the compute whilst at the same time talking to each other so it appears to the player as if they’re all on one server. Or indeed 2 caps ships with 200 players on each could be handled by several servers. Even giant fleet battles could be split between servers to deal with smaller sections of the larger battle.
Server Meshing is dependent on SSOCS, ICache and Global Persistence, with Static server meshing being the first iteration.
Server to Client actor networking – Actively being worked on This refers to how actions in game like walking forward are shared with other clients. At present when you press the ‘W’ key it's controlled by your client, this information is then sent to the server which then replicates that to all other clients. This has several issues, there can be a noticeable lag between what you do and what the other clients see, whilst also being difficult to manage from an anti-cheat perspective. Therefore Server to Client actor networking aims to take the inputs you create at the client and send them to the Actor Action Handler, these actions are processed together, before being sent to both server and client simultaneously. This will help when facing players on poor connections, whilst also improving interactions with things like the Mobiglass, where you currently see it popping on and off as the server try’s to play catchup with your interaction.
Vulkan Integration – Actively being worked on CIG have decided to move from DX11 to Vulkan, they have opted against DX12 which requires Windows 10 on the user side. Vulkan which is a graphics pipeline and render interface (Part of the Gen12 Renderer rework) which does not require its users to be on Windows 10. Vulkan reportedly has all the same features of DX12 so fidelity shouldn’t be lost by converting.
Subsumption – Actively being worked on This relates to the AI within the game. Subsumption is being implemented to give AI added realism in the verse. It effectively allows for NPC’s to choose which of their actions are top priority and ‘subsume’ or override that the current task should the AI deem they need to.
Zonal Coordinates – In Game “The system that allows CIG to e.g. rotate a planet with tens or hundreds of thousand of entities on it, without lagging the server to death (or have different objects update their position on different frames - which would be freaky :p). Each zone has both a 'world position' (its coordinates in the parent zone), and an Origin (0,0,0) - which are usually the same position. Every object inside a zone now measures it position relative to the
Zone Origin, not the global origin. This also means that if the zone moved (e.g. because it rotated), every object inside that zone moved because the position of those objects is calculated from the Zone Origin.“
Source Reddit: logicalChimp
Procedurally Generated Planets “aka Planet Tech v4” – In Game Procedural planet tech was created to speed up and standardise the way planets are created in the verse, using a set of parameters to flesh out a planet, including different biomes. This gets the dev team much of the way there, allowing them to go and place handcrafted points of interest, outposts etc.
Included in the PG Planet tech are also “Spherical Physics Grids (prior to this a Physics grid
had to be a flat plane, even if it could move independently of another grid) are the big one, but spherical water levels is another (previously, 'water' was defined as a flat plane across the entire map)”
Source Reddit: logicalChimp
Building Blocks UI – Part implementation in game “The new UI Framework and (more importantly, imo) supporting tools that allow anyone to start building placeholder UIs in order to iterate on gameplay designs, etc - instead of having to wait for a UI Team Member to explicitly code up a placeholder UI.”
Source Reddit: logicalChimp
Inner Thought – In Game “This is more than just providing a text description other than just <
