We've been a software development company for over a decade. We designed and created many applications for B2B clients, Telco, Media companies and more. At some point, we decided to try our chance in the game industry. We couldn't completely resign our development due to long term contracts, so we took volunteers from our company who were willing to do this huge step and we built a separate team. To make this task even harder we agreed to make the hardest of all possible games... yes MMORPG. We evaluated possible options and software which could speed up our development and we made our decision to invest in the most promising solution on the market - Atavism. After nearly 3 years of development, we received an offer to take ownership of the Atavism project. It wasn't an easy decision for us, as we were in the early alpha tests stage with our game, and we knew that we will have to put our game on hold for a while, but eventually, we took this step and since November 2017 we became Atavism owner. Since then we are continuously developing and improving it. Over these 2 years, we released 7 major releases, where we added over 1000 new functionalities, improvements, and fixes. In 2018/2019 Atavism was featured by Unity as "Insanely advanced MMORPG platform for Unity". We wanted to make Atavism accessible with the same top quality not only on Unity but also on Unreal, and thanks to the community and its feedback we evaluated possibilities to make Atavism for Unreal Engine. Now here we are, and we can officially announce that we've been awarded by Epic Mega Grants and that the project to provide Atavism for Unreal has started.

We have very ambitious plans related not only to the Atavism for Unreal project but Atavism in general.

Because the Atavism server is written in Java and it's not engine related, we have a huge headstart because the server-side in 95% will remain the same for both Unity and Unreal.

The first element which we need to change is Atavism Editor because it's a native Unity application, where using its graphics interface developer can adjust most of Atavism related elements like create items, define quests, mobs, NPCs, stats, abilities, and much more. We decided to rewrite the Atavism Editor from the scratch, and also make its engine independent. The new Atavism Editor will be a standalone application written in Electron with Angular, so we will use very modern but on the other hand stable and reliable technologies. During the process, we also redesigned the application to have more features and be even more friendly.

The second element is preparing networking layer and port client scripts written in c# to c++ or to preferable to Unreal Blueprints.

We will also be going to port the whole UI system to provide the same quality for both engines.

We will prepare community tools like discord server, forum, social media pages to periodically inform you about the progress, and also discuss some topics related to some implementations. We want to develop it in correlation with you - The Community.

Conceptually, there are two levels of architecture: the master server which can control accounts and world server details for multiple worlds, and individual game worlds.

NETWORK ARCHITECTURE

Atavism uses mixed TCP and UDP protocols to handle network traffic, the login process is based on TCP while world messaging is based on UDP as this is the only way to handle a significant amount of traffic. To offload networking Atavism uses a number of performance enhancements like Dynamic Quadtree which limits the number of entities required for streaming around the player, packets aggregation, to reduce the number of packets, native Unity prefabs system to read less important data from the client, and present them like tooltips for items. etc. but also server uses the caching system, so for performance reasons it loads static data from the database during startup, to work on them, and handle database operations only if necessary, mostly for dynamic content like player progression. Atavism also lets you split the workload of world server into 12 functional servers like combat, mobs, auction house, proxy, to just name a few.

LOGIN PROCESS

A user logs in to the Master Server (authentication server), using credentials, and connects to the newest login manager which is part of the world server infrastructure (can be on a separate server as well). At this stage, the user can change the world server if there is more than one, and create a character within a particular world server, and enter the world. The login process can be secured by an SSL certificate.

WORLD ARCHITECTURE

Once a user is logged in to the Master Server, he can enter any world for which he is authorized. Each game world runs on a suite of world servers.

The world-specific servers consist of:

• Proxy server: handles communication between the client and all other services.
• Authentication Server: handles user authentications.
• Login server: character selection and creation.
• World Manager Server: controls a world's geography and what PCs and mobs can see using dynamic quadtree functionality.
• Object Manager Server: saves and retrieves permanent object data to and from the world database server. Communicates with the database using JDBC.
• World Database: contains all of the world's persistent information. By default, this is a MySQL/MariaDB database, but can be any JDBC-compliant database.
• Message Domain Server: facilitates messaging among server processes
• Mob Server: controls mobs and NPCs.
• Combat Server: controls combat functions .
• Inventory/Trading Server: controls objects and secure trading.
• Chat Server: handles all chat related tasks, including saving all chat commands in the database or the log file.
• Weather Server: controls weather, randomization, and transition which can be adjusted per instance.
• Auction Server: handles auction house functionality.
• Quests Server: controls quests related tasks.
• Instance Server: handles instances (world, dungeons, private, guild, etc.).
• Faction Server: defines states between entities based on the factions and their relations.
• Proxy Server: handles all clients-servers communications.

You, control and operate all the above servers. They can run them on separate hardware platforms, if desired, for improved performance.

INSTANCES

The world is split up into one or more instances. An instance can be a single and contiguous zone defined by a single scene. There is no visibility between instances. except for groups, guilds, chat, and some global messaging. Moving between instances requires a loading screen.

ZONES

Zones are dynamically partitioned by a quad-tree. The topmost level of the quad-tree represents the entire zone, which is then divided into 4 equal-sized regions by the quad-tree. The four new regions cumulatively cover the entire space of its parent node. As leaf-nodes (nodes that have no children) become populated by objects and users, the server will further subdivide regions using the same algorithm. All objects are placed into the quad-tree to make it easier to find out what is near an object. This allows the server to consider only a subset of all objects it knows about when performing distance checks. For example, when a user moves around and comes close to an object, the server tells the client about the new object. Using the quad-tree nodes, the server compares the client's distance only with objects within the user's current quad-tree node and adjacent ones which are within the user perception range. 

MULTIPLE INSTANCES/ZONES

When do you need a new instance (as opposed to a quad-tree region)? When you cannot fit your content into an existing instance, you need to create a new instance. This may happen in the following scenarios: your world is extremely big or the new area does not occupy the same space, as is with instanced dungeons, or if you enter a house that is bigger than its physical structure. Instances are also used to partition large player populations or create private spaces. When a PC moves from one area to another, it is called instancing or zoning. The client will switch to a loading screen while it's loading the new zone. Game developers have to keep this in mind when designing gameplay. The client does not see or know about zones other than the one it is occupying.