Player Features and Ideas Discussion

Before I begin, let me preface this by saying that I don't make this request lightly because I understand how significant a change to the underlying code base and technology this could/would be. Not to mention the incredible technical challenge that it presents. However, I feel like it very well may be a necessary step to allow the kind of battles CCP would like to see possible in the future or to simply have a 'plan' for events like Asakai. For the large chunk of us in IT, I think you may already have an idea where I'm going with this.

The idea behind live migration of a system is pretty simple. You take a system that has more pilots than the hardware can handle and you move the system to more powerful hardware without disrupting the user's experience (eg. disconnecting them). The battle of Asakai would be a good example of the benefit. It would have allowed more people into the system by putting it onto a re-enforced node, but also allow those in the surrounding systems but on the same node to continue playing without disconnecting them. TiDi should help this process since you're already slowing everything down, you also give the server more time to migrate all important information (eg. ship location, targeted ships, pilots in space, etc.) to the new server before moving the actual pilots. The real nightmare is going to be in the form of managing user connections during the migration. TiDi very well may be helpful here too, but it would likely need to be extended to the point where the devs/servers are allowed to "pause" the game during the migration. Doing a live migration without this pause may be possible, but the wizardry involved would be astounding to say the least. Especially since the server is already operating above capacity.

Multi-Server Nodes are also a relatively simple concept as well. You take a task usually done by a single server and split it up among several servers thereby increasing how much work can be done at once. In the same vein, allowing another server to process pilot actions/movement/etc. should allow more pilots into a give system. This functionality also has the benefit of being scalable. It isn't without its faults though. Spreading real-time work between multiple servers requires a very strong network backbone to prevent the network from becoming saturated. You can mitigate this by allowing only the 'parent' server directly talk to the network at large and have the 'child' servers on their own dedicated network hardware. This however creates extra costs that, if not implemented with live migration, might result in hardware that goes largely unused a majority of the time. Depending on implementation though, you could allow any server to become a parent and allow available servers to become child servers and take on the overflow on the fly.

Now if we take a trip down make believe lane, we can imagine what may have happened with Asakai with both systems implemented. The system goes into TiDi like normal and things start slowing down. The devs take note and make the call to move the system. The players notice a little message indicating as such and player inputs are temporarily paused. A few moments later they're back at it, with TiDi still in place, but now on a reinforced node and things are moving along a bit better. Until, once again, even more people start showing up. At this point instead of capping the number of pilots in the system, the server starts diverting the work load among available servers allowing an even greater number of players to join the fight causing even more mayhem and destruction. Of course during all of this TiDi may very well continue to remain in effect. With some luck it may be implemented in a way that may allow it to go from 10% back to 25% or better.

I know I've left out a number of other things that need to be taken into consideration, but I wanted to keep this post short and get the thought in the open at least. Again, I don't make the request lightly but it is one I feel a game like EVE could greatly benefit from implementing.

-Wolf