Networking & performance

Logging out and back in at the same place is part of the plans, and the intention is to do everything possible to return players to the same position, whatever their scenario.

The mission first teaches players to take the shuttle to a transit platform and join an instance, with no reward, and the new instance lets a group of four play a more directed experience without outside interference.

Benoit Beausejour says the game is still being turned into an MMO and content and features are outpacing the guardrails and cross-system validation, so the team needs to add stronger validation.

Beausejour says the game is night and day compared with a year ago, with much better server performance, stability and player capacity and much longer sessions, though there is still a long way to go.

The plan is for bases, land and extraction pots, and much of their functionality, to be visible across all shards in a region, but raiding can only happen on one shard, usually the owner's if online, so players must switch shard to attack.

The developer says the next step is rolling out the finished Vulkan renderer, already default in Squadron 42, then improving memory usage and optimising individual shaders and systems, with GI and reflections expected to cost significant GPU time.

No single technology will drastically improve main-thread performance; many teams are improving it across the board, often by finding and fixing individual bugs, and the speaker suggests using a profiling console command to pinpoint bottlenecks.

Vulkan multithreading already runs internally with big render-thread speedups but may not raise framerate; it likely misses the next big release, with the second major patch more likely, not guaranteed.

AI performance is tied to server FPS, working poorly under five, struggling between five and eight, decently above eight or nine and ideally over ten; they are working to make AI cope better and fixing bugs that mimic unresponsiveness.

They take the joke well, explaining that standing on chairs and T-poses come from several different bugs, mostly streaming-related, and deliberately aren't hidden, since they flag problems that need proper fixing.

Roccucci says AI performance depends on limited server CPU budgets and unresolved decisions about NPC counts, and Server Meshing and population management are still coming together, so it's a balance of trade-offs.

Stowed items you own can travel between shards, but anything left in the game world persists only on that shard, and the intent is to improve the chance of returning to the same shard later through matchmaking changes.

The maximum visible player count depends on client performance and scenario; the aim is for about 100 players to see each other at reasonable framerates, but the absolute limit can't yet be predicted.

Server meshing is described as very advanced, with the prerequisite streaming, authority and replication work largely done, a static mesh next, and a dynamic mesh still to come after that.

The main gain is expected in server performance, with less lag and rubber banding once even the static mesh is in place, while client FPS should improve only slightly.

NPCs standing on chairs come from many different bugs, mostly streaming and sync-order problems between the character and the chair, that look identical; they are being fixed one at a time, and progress is real even if players don't see it.

Server performance affects AI quite a bit, since calculations are spread over time and slow updates make social reactions, vision and ship aiming sluggish or off; server meshing is expected to help.

They write behaviors both for the ideal case and to tolerate slow servers, using persistent states and reactive decisions, and they also design AI code (like caching) so it doesn't slow the server.

The "i" in icache stands for item, not Ignite; the icache service is largely custom-written, though the wider backend uses open-source technology and may move parts to a cloud-native architecture.

QUIC isn't suitable because it is stream-based and prone to head-of-line blocking, whereas the game's custom UDP protocol uses per-entity semi-reliable messages, and connection problems are mostly bugs rather than network protocol issues.

The panel expects server object container streaming to raise server frame rates toward a 30 target, improving AI, combat and responsiveness, allowing more content in the solar system, and speeding up developer iteration.

In theory a higher player count should be possible, but without enough testing they can't say definitively, other bottlenecks may appear, and it's unknown whether it lands in 3.8 or later.

The goal is smooth performance, at least 30 and closer to 60 frames per second, which he thinks is a good shot since single-player avoids multiplayer networking overhead.

The telemetry page replaces fixed minimum and recommended specs with an interactive graph of collected performance and hardware data, letting players log in and compare their own machine's results against other players' CPUs and GPUs.

Graham Philipson is polishing the first VoIP release, which is a building block toward voice commands, and asks for patience because syncing voice with facial data at this scale hasn't been done in a game before.

The developer says the graphics pipeline does not wait for server updates and server or netcode performance does not drive client FPS, and that fixing performance is slow because the game pushes the engine beyond its design while chasing high fidelity.

Cargo piled up in a doorway stays while someone is near but is cleaned up once everyone leaves, and they can clean up more aggressively when a region hits capacity, so trolling is handled.

Face capture has a performance cost, currently around a couple of milliseconds per frame at 60 hertz, so the team is working on load balancing and it will be an optional setting.

Footprints currently use short-lived particles, but a dynamic decal system is being worked on that could let such marks persist longer, though the team says it can't promise this will happen.

An object container holds a hierarchy of objects on top of a unified zone partitioning system and can be streamed in and out dynamically, like a level inside a level, which capital ships and universe streaming need.

Object container streaming basically works, but the size limits and content rules are still being figured out and tested, and budgets can't be given to designers until they are.

Physics-enabled props already exist and more are a goal, but the team is still refactoring CryEngine's player-centric updating and networking to make simple rigid bodies efficient before adding more.

CPU multithreading work is ongoing, with current focus on optimizing servers to run on three to four cores per instance before the client, which scales well to about eight cores.

Anti-cheating measures are planned and on the roadmap, though not much is done at this early stage; a server-client model makes validation easier, and the game isn't a pure competitive shooter.

The main downside of frequent PTU patches is the bandwidth cost, but the testing gave much better stability and iteration, so they plan to keep patches on the PTU for about a week before going live.

The goal is no loading screens and seamless travel from orbit to planet without leaving your seat, though that may not be achieved in the first version, and they say they are working toward it.

Chris Roberts thinks the Dogfighting Module will be a great benchmarking tool, though the game is currently less optimized than the final one; if it runs well now, the final game should run well.

Chris Roberts jokes about the NSA, then says CIG runs the servers and the game is server-authoritative, so CIG can see and track data from all battles, such as ship and weapon balance.

Chris Roberts leans toward building the proper MMO-ready backend rather than hacking something in, even though it may delay release and upset players who want early access.

Tagging a ship tells the system you want to fight it, but there will be no single shared real-time star-system instance; players are dynamically placed in limited-slot instances by allegiance, interest and skill.