Server Physics & Zone Management news - Realm Zero

When I first began this project, it was on a very small scale and utilized only a single 400 x 400 terrain (world) tile. This also played a huge role in the network transmission between players, basically everyone connected would receive all packets. I was aware that one day there would be multiple terrain tiles and even multiple instances such as dungeons, training areas, etc. So throughout the course of development, I always held that information in the back of my mind when designing the network architecture. Essentially I had to create a programmatic way to keep track of the players and only transmit player data when they were within range of one another.

My original idea was to perform distance based calculations before the packet transmission. This approach simply wouldn't work as it would be a huge performance hit and ultimately result in delayed packets once the server held any significant player load. This led me to seek out another solution to consistently manage player location and without any complex calculations keep the players updated with vital information. Then is when I decided it was time to remove the windows form aspect from the server engine and encase it entirely inside of the Unity3D framework.
Can a 3D intense framework could run on a server that didn't have a graphics card?

Initially my first thought was no, however it’s possible! Since Unity3D applications can be launched with conditional parameters allowing you to disable the 3D rendering aspects and even run it without a window all together.
The command is: -nographics -batchmode

Now that the server is running inside of Unity3D, I can take advantage of all the engine has to offer including: physics and collision detection! Keeping track of world and player physics server-side is a must for any online game that doesn't want to be ridiculed with hackers. It’s very easy to hook into a game client and modify game variables to allow your player to move faster, jump further and even fly. However, since the server now manages and checks these conditions it’s also very easy to find out who’s doing something they are not suppose to be doing and even cause them to “snap-back” to where they actually belong in the world.

The second part of this is zone management and tracking the players location at all time. I've designed a real-time player tracking solution utilizing box colliders that are 25% larger than the actual zone and allow for zone sharing. As you can see from the image there are sections that overlap neighboring zones and in the corner of all interior zones there is a total of 4 overlapping zones. This is very important and is the bases for the design implementation.

The system does two primary checks and underlying shared zone validation.

• Do players currently exist in this zone and load them for the entering player.
  • Ensure that the new players zone(s) don’t match any other zone occurrences.
• Do the existing players exist in same zone as the player entering.
  • Ensure that the entering player doesn't exist in more than one zone occurrence.

Upon successfully loading the player reserves a pointer to the new player for fast data transmission. Now without any additional checks the system knows exactly who needs to receive the packet information! The reverse is also true for unloading a player from a zone.

The next phase of development includes adjusting the code for environment tree generation. These adjustments will allow spontaneous generation of trees across all terrain tiles which have a valid spot for placement. A valid spot will be determined by terrain elevation (since we can now check that server-side), the elevation check ensures that a tree will not be created underwater or on mountains. The second part of the system, which is already implemented ensure that new trees are a certain distance away from existing trees.

Then finally pushing this change to other world items such as houses, dropped items, monster spawns and world effects. This will allow players to utilize the same 25% zone buffer to load/unload these items. This is an important factor and allows a zone to load before it becomes visible to the player. This technique will help keep game performance high, while keeping consumed memory low.