FriendlySTH
Well-Known Member
Posted Today, 01:49 PM
So a bit of a progress report on the day that was.
We finished yesterday hopeful but cautious, as the server FPS was just not where we needed it to be realistically. Today was a day of highs and lows. I'll try and explain the difficulty we experience right now in the optimization.
The Challenge
The system was never designed or conceived to run such a huge amount of dynamic entities, over 11000 currently (in addition to the 2 or 3 million static map objects). So each system we refactor, redevelop or fix we bump into the next bottleneck. I think perhaps it is not unlike fixing traffic congestion, you fix it in one area only to find you have moved it somewhere else. This is what we are doing, trying to adapt and redevelop a system designed to handle perhaps 100 dynamic objects in a local area to one that handles tens of thousands distributed over tens of kilometers.
The Progress
We achieved some real success. We broke some things in the process, but nothing unworkable. As an example, we were refactoring how the "bot client" (a system that acts as a handling pot for messages sent to connected computers) handles error calculation (figuring out the difference between current and past, to see if it needs to notify clients of updates). Previously it was not only checking everything, all the time, but the engine was also checking with the bot client to see if it had received its messages. This is redundant as they are part of the same application; messages will always be received by the bot client.
However in optimizing this system (which involves the calculation of hundreds if not thousands of potentially different state management scenarios) we missed a few things, and this results in weird out of sync errors in inventory between the client and the server. Nothing that stopped many people playing, but an example of the pitfalls and challenges faced with optimizing.
Zombie pathing, collision, and tracking is "on par" with the mod for now, and in order to achieve what we want we need to redo the internal engine targeting methods to be more in line with the scripted targeting methods per the mod. This will take some time, so it's been timeboxed to be completed after the release of the alpha.
Our new programmer was straight into work, creating a sound system change that allows different footstep sounds to be played for different shoes worn. Awesome! Now if only we had the sounds to fill them in! Our big brother A3 has been loaning us people, including the A3 sound lead, to help set this function up. Some audio changes are already creeping in which is great to see and will be much appreciated for those joining into the alpha.
The Result
This puts us pretty much in the situation we need to be for server performance, assuming the remaining state calculation errors can be resolved quickly. Our new architecture can support much more, so the future will involve us tearing down the remaining bottlenecks but for now; they seem to offer a good enough structure to push forward on. This is good news. We'll be doing a full review of server performance tomorrow based on tonights metrics and make a decision regarding the server performance.
The Status
As I said yesterday, there is going to be quite a few bugs and problems - but our aim is to mainly turn off the unfinished features so that the bare-bones system largely just works. I think this gives people a good impression, rather than a bunch of unfinished stuff that simply doesn't work.
The real challenge for us now is to figure out what must be fixed versus what can be left until after alpha and redone from scratch properly.
So a bit of a progress report on the day that was.
We finished yesterday hopeful but cautious, as the server FPS was just not where we needed it to be realistically. Today was a day of highs and lows. I'll try and explain the difficulty we experience right now in the optimization.
The Challenge
The system was never designed or conceived to run such a huge amount of dynamic entities, over 11000 currently (in addition to the 2 or 3 million static map objects). So each system we refactor, redevelop or fix we bump into the next bottleneck. I think perhaps it is not unlike fixing traffic congestion, you fix it in one area only to find you have moved it somewhere else. This is what we are doing, trying to adapt and redevelop a system designed to handle perhaps 100 dynamic objects in a local area to one that handles tens of thousands distributed over tens of kilometers.
The Progress
We achieved some real success. We broke some things in the process, but nothing unworkable. As an example, we were refactoring how the "bot client" (a system that acts as a handling pot for messages sent to connected computers) handles error calculation (figuring out the difference between current and past, to see if it needs to notify clients of updates). Previously it was not only checking everything, all the time, but the engine was also checking with the bot client to see if it had received its messages. This is redundant as they are part of the same application; messages will always be received by the bot client.
However in optimizing this system (which involves the calculation of hundreds if not thousands of potentially different state management scenarios) we missed a few things, and this results in weird out of sync errors in inventory between the client and the server. Nothing that stopped many people playing, but an example of the pitfalls and challenges faced with optimizing.
Zombie pathing, collision, and tracking is "on par" with the mod for now, and in order to achieve what we want we need to redo the internal engine targeting methods to be more in line with the scripted targeting methods per the mod. This will take some time, so it's been timeboxed to be completed after the release of the alpha.
Our new programmer was straight into work, creating a sound system change that allows different footstep sounds to be played for different shoes worn. Awesome! Now if only we had the sounds to fill them in! Our big brother A3 has been loaning us people, including the A3 sound lead, to help set this function up. Some audio changes are already creeping in which is great to see and will be much appreciated for those joining into the alpha.
The Result
This puts us pretty much in the situation we need to be for server performance, assuming the remaining state calculation errors can be resolved quickly. Our new architecture can support much more, so the future will involve us tearing down the remaining bottlenecks but for now; they seem to offer a good enough structure to push forward on. This is good news. We'll be doing a full review of server performance tomorrow based on tonights metrics and make a decision regarding the server performance.
The Status
As I said yesterday, there is going to be quite a few bugs and problems - but our aim is to mainly turn off the unfinished features so that the bare-bones system largely just works. I think this gives people a good impression, rather than a bunch of unfinished stuff that simply doesn't work.
The real challenge for us now is to figure out what must be fixed versus what can be left until after alpha and redone from scratch properly.