Jump to content

Search the Community

Showing results for tags 'speculation'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Starting Zone (EN)
    • Rules & Announcements
    • General Discussions
    • Off Topic Discussions
  • Starting Zone (DE)
    • Regeln und Ankündigungen
    • Novark's Registratur
    • Allgemeine Diskussionen
  • Starting Zone (FR)
    • Règles et Annonces
    • Registres du Novark
    • Discussions générales
  • Beta Discussion
    • Beta Updates & Announcements
    • Idea Box
    • The Gameplay Mechanics Assembly
    • Streamer's Corner
    • The Builder's Corner
    • Innovation Station
    • DevBlog Feedback
  • Organizations
    • Org Updates & Announcements
    • Novark's Registry
  • Fan Art, Fan-Fic & Roleplay
    • Novark Agora
    • Novark Story Time
    • Novark Art Gallery

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL










Found 1 result

  1. I'm a developer, you're a developer, she's probably a developer too! Let's face it, DU is born to attract the developer types to it. So let's start a (serious) wild speculation thread about what we think the back-end server architecture might look like! I have to imagine that since NQ is targeting a single-shard server structure the back-end will probably need to be broken up into micro-services. But since it is a real time game, it will also need to be as compact as possible with as few network boundaries to cross as possible. A server cluster, perhaps similar to Azure Service Fabric would do the job very well, with services partitioned out and distributed across nodes for density and automatic failover and scaling. First off, there will be a single point of contact for establishing and authenticating connections to the servers. The authentication service will check credentials and negotiation the session security keys and reserve a socket connection endpoint on the gateway layer for the client. The client will then connect to the specified endpoint with provided symmetric keys to prevent tampering. The gateway layer will be scaled as necessary to provide raw network throughput. At 5 KBps bandwidth per client, that means we get a theoretical maximum of roughly 200 clients per server until the gigabit network ports are fully saturated. Incoming packets (messages) are dropped into an event queue system for processing by the back end processing services. The regions are partitioned spatially using an octree algorithm (essentially a 3-dimensional binary search, where every cubic region of space is split in half on each dimension, into eight cubes, as necessary). The regions are separate services and are spread amongst server nodes for density and scalability. Each region is responsible for calculating physics on region objects and routing events between players in the region. A level of detail system is also in place for sending lower frequency important message across regions. As more players move into a region, the region is split cubically into sub-regions that redistribute amongst nodes in the cluster. As players leave the regions, they are collapsed back into the parent region to conserve resources. When the server cluster hits specified usage limits, additional nodes are added/removed from the cluster to scale up/down as needed. The service cluster framework (for example, Azure Service Fabric) is responsible for redistribution of partitions across server nodes and replication of services for failover purposes. Each of these scale units are also distributed geographically to maintain low latency, with a backplane in place to keep geographic regions in sync. That's my initial spitball idea for the architecture. Feel free to elaborate, correct, or share your own architecture ideas. Let's get a conversation going.
  • Create New...