Over the past few months we’ve had a few new additions which we took from concept to creation. We began by designing and implementing a dynamic cross-breeding plant system, which yields various resources. These resources can then be used in other aspects of crafting to create some really unique and diverse items. We’ve also introduced player zones and customizable housing. This feature allows players to stake claim and create a unique plot of land, they consider home.
However with only a few months until the Alpha launch (Register Here), I’ve began shifting the development focus towards getting the game network ready. The game has been network aware for quite sometime but, there is a big difference between being aware and being ready. The progress in this area is going extremely well as most of the underlying fundamentals have been implemented. We are now going through and enhancing and implementing new features to make the online experience more enjoyable.
First let’s discuss player movement, latency and animation. When I began the average ping was right around 350-400 this was before implementing animation, yikes! This was to be expected as I knew that my initial packet push was overkill and had to be thinned out and optimized. So I ignored that aspect and continued by adding animation packets. Naturally the ping increased once again, this time it was sitting right around 2000-2500.
Alright, now it was time to optimize the packet delivery system. In a 3D environment a players position is recorded in what’s called a Vector3 and contains three floating point numbers which are extremely accurate up to several decimal places. So I began by rounding these numbers down for only the network transmission. Next I would evaluate these numbers and see if a significant movement or rotation had been detected and then forward that packet for delivery. This reduced the packet load dramatically as now only necessary packets were being sent, instead of sending redundant information.
Another bit of information that had to be removed and calculated after delivery was player direction and speed. When a player moves in any given direction their movement is a combination of forward, backward, left and right key combinations. Since a player may be moving in more than one direction at any given time, for example (forward & left): you have to calculate the blended direction and speed post process. I achieved this by retaining an instance of previous player position and calculating the DOT Product of the players movement. Using this technique I was able to obtain a direction indicator and also a speed modifier. Now I simply apply both of these variables to the players movement in-between draw cycles which results in very smooth and somewhat interpolated movement.
This entire process of packet optimization took a few days, but was well worth it! Remote players now experience very fluid movement, and rotation with no delays between packet to movement delivery. The best part is now the average ping from Florida->Texas->Florida sits stable at around 50-60, which is a HUGE performance increase! However, I’m not finished optimizing the packets yet! I’m still evaluating two different encryption/compression packages which should help reduce that number even further and assist in the prevention of packet sniffing.
We’re currently working on implementing a very unique and customizable player chat and communication system. Like most online games you have the standard chat box which displays public communications. We plan to extend this to offer private messaging, inbox notifications and local overhead chat communications. I understand that not everyone wants to see overhead chat communication, this is why we are implementing several options to customize the experience. You will have the option to change the onscreen duration, color and disable the feature all together.
On the back-end we’ve also added several improvements to protect players and allow game masters to quickly identify problems, such as: player abuse and hacking. Coming from a compliance and security software background, I understand the importance of not losing a single piece of information in day to day transactions and communication. This is why I’ve designed and implemented a 2-layer transactional log system. Using a non-blocking and low priority threaded logging system these transactions are sent to a MySQL server. In the event the MySQL server is unavailable or and error occurs during processing that data is then recorded into a local XML file. Upon the next server maintenance which is typically every hour and unnoticeable by the players, this local XML file is then merged into the MySQL database.
This system is being used to record communication, item creation, player trades, item destruction, etc. You can see from the illustration below how the system operates inside of the networking engine.
Over the next few months you will begin to see more and more networked components introduced. Some of these will include: equipment, inventory, resource node generation, gathering and much more! We’ve also allocated a solid month to improving the characters animation and combat system introduction. Since there are many underlying components that support the combat framework, we are saving that feature for last.