(02-07-2015, 12:00 PM)Flickering Ember Wrote: I wouldn't be surprised if they don't have the technology to split up wards to go to different servers that need it more. Seems like it could be the case considering they couldn't even create personal housing. (What we got was FC housing with a single bow on top and they called it 'personal' housing)
Sorry in advance if this gets a little esoteric...
You know, I was having an argument (in the civilized "debating an issue" sense of the word) with someone, and they brought that up. We both scratched our heads, because I've heard before that SE is struggling with a code base that's both old and unfamiliar to many of them. So we did some extrapolation:
- We know that the neighborhoods aren't on the same servers as the rest of the server - they're instanced
- We know that individual houses are instanced, with very little connection to the rest of the server you're on
- We know that housing is a new thing for FF, so the actual code for housing doesn't fall into the "old and unfamiliar code" camp
I figured that what's probably going on is they have one or more wards running on a single server, with multiplexing code at the ward entrances to handle shunting you into the proper ward. All fairly basic stuff, the only new thing they'd have to add would be the actual multiplexer, as well as the neighborhood design.
Now, once you're in the ward, the only connection you have to the rest of the server is through chat and your various player groupings: party, friends list, linkshells, etc. And I'd be really surprised if these aren't all implemented through chat*.
This means that there's no real hardware limitation causing the number of wards to be limited per server. Instead, they've probably got a pool of machines that limit the total number of wards they can offer. Each ward's connection to chat would be nebulous - the client would connect to the proper chat system based on your server, no problem at all.
This means that all you'd really have to do to replace the current system with one where you have a pool of wards would be to change the ward-selection multiplexer to handle a variable number of wards, instead of a set number. Now, I don't know how their multiplexer works, but I'd expect this would be something you could hand to a junior developer and have done in a week. Two, with QA. That would give you one where they'd manually assign wards to servers. Adding an automated system to do this would lighten the load on their end, but considering we're only talking about a small number of wards (a few hundred, tops), they'd get more bang from their buck by simply having someone look at server stats every week or two and manually doing it.
Now, granted, this is all extrapolation from a position of ignorance, but seriously: If I could figure out a way to do this with a typical MMO server architecture using a team of 3 in two weeks, how hard can it be for them? Even if you assume that their architecture is especially Rube Goldberg-esque, you're only adding an order of magnitude to this. A team of 3 operating for the length of time it takes to do a major point release (2.4 to 2.5, say). That's still a cheap and easy win.
*SE is known for doing their own crazy thing, but if I were doing it, I'd have chat be an XMPP server, with all the groupings handled by XMPP contact management, linkshells as multi-user rooms, etc. Now I don't think SE use XMPP, but the basic concepts are the same for any chat system. Other games do this, which makes chat a no-brainer in them - Eve Online and Star Trek Online, for instance, are known to use XMPP.
