RPC has moved! These pages have been kept for historical purposes

McBeefâ„¢ · **05-15-2016, 08:22 PM**

(05-15-2016, 05:22 PM)Setoh Aliapoh Wrote:
(05-15-2016, 04:59 PM)McBeefÂ© Wrote:
(05-15-2016, 04:55 PM)Setoh Aliapoh Wrote:
(05-15-2016, 02:32 PM)O Wrote: The simplest solution would be to just set the server to automatically spawn a new empty ward if all houses of any one size were already bought in all other wards. Low-pop servers would end up with a small number of wards, high pop servers would have a high number of wards.Â

I don't buy the excuse that this can't be done due to PS3, because a PS3 user is still only loading a given ward that they happen to personally be inside of at that time, so having a larger list of wards which exist shouldn't impact anything.

This solution would also gut the flipping market, because unless a person is really dead-set on getting a specific plot, there would always be at least one small, one medium, and one large available at all times. This solution also accommodates multiple houses per account, and even accommodates neighborhooding if players are so inclined (a cluster of friends could wait until a new ward spawns, and then all buy houses that are next to each other).Â

I also don't buy the excuse of it costing too much in server infrastructure/database/etc, because the higher pop servers are where all the income is coming from anyway, so... why are we per-capita getting less services than a smaller server?

This, exactly! LOTRO had a similar system, where they'd spawn new wards as the old ones filled up.

There are those who defend the current housing system by arguing that the housing servers can't support more wards (which is, honestly, pretty ridiculous in this day and age). Assuming this is 100% true, you could still get nearly the same benefit by simply pooling *all* the wards in a cross-server pool, and then allocating them to servers as they fill up. Low population servers would end up with a few wards, while high population servers would have quite a bit more. It still wouldn't solve the problem entirely, but it would help mitigate it.

Housing in an MMO isn't rocket science, though. It's a solved problem, in the sense that other games have been able to enable letting anyone who can afford it buy housing.
Honestly, I'm guessing it's a PS3 issue.

Something like some table somewhere can only hold so much data, and they can't rebuild it. It's why they have weird workarounds like adding sub-divisions instead of just increasing the number of wards.Â

I get the feeling they have to like reverse engineer it every time they want to increase the number.

That makes no sense. There are plenty of PS3 games that provide access to all sorts of information. I worked on the PS3 version of HBO GO, and there was no problem at all with the console being able to handle large amounts of data. There was no problem at all with the ability to visualize that data, to scroll through it on the screen, to page around it, etc.

I think we're coming up with excuses for them, but realistically housing is in bad shape because SE don't care enough to make it better, and because we're willing (as a whole) to live with it the way it is. Like I said before, housing in MMOs is a solved problem.

I did a little math, in case you like math:

Show Content

CS/Math follows
I've gotten the "It's too much for their servers" objection whenever I talk about housing before, so let's do some math on this.

Every housing ward is the same. This means that the overall map to the place is something the client can store. The only thing the server needs to handle is the specifics of what's unique about each house. What you really end up talking about then is bandwidth and storage costs. So let's look at those. Really, since we already know their network can handle transmitting the information, we're only looking at storage costs. So let's look at how much storage we're talking about.

A house has an owner, some permissions, and the like. We'll stretch it and say it takes 1k to store all that. 2k when you include the message on the placard.

A house also has some 200-odd items. Each item has an X and Y coordinate, as well as a rotation value. It has an id (because the individual asset is already in the client, so it only has to say "This is an X"), and a dye color. Say it's 20 bytes for all this. Let's actually bump that up to 50, to include all the extra stuff you might want to have on items, to cover for things like garden crops, etc.

A house also can have rooms inside, if it's an FC house. This gets pretty variable. Lots of FC houses have only a few rooms. Some have many, many rooms. The max is 512, but I'd guess the average is somewhere around 10 (including all the personal houses, which have none). So the average per house might be 10, but the max per house - assuming every house is an FC house - is 512. A FC room can have 50 items in it, plus we'll give it 1k for the message, permissions, etc.

So a FC room ends up having a max storage cost of 3.5k. A house, with 200 items and 10 rooms, has a storage cost of 47k. Assuming it's filled to the brim with 512 FC rooms, then it's about 1.8 MB.

A ward of 60 houses, then, has a storage cost of just over 2.8 MB. For our worst-case ward, where every house is a FC house, every FC house has 512 rooms, and everything is filled to capacity, it's 108 MB.

They're adding wards in 3.3, so each server gets 3 housing areas with 12 wards each. 36 wards. Our math above, then, says each server that fills up all its wards will have about 100 MB of housing data. The worst-case, where every house on the server is a FC house, every FC house has 512 rooms, and everything is filled to capacity is 3.9 GB.

I think there are currently 62 servers for FF XIV. Assuming every server fills all its wards, we're talking about 2,232 wards. If every server fills all it's wards, with the average sizes we calculated, then SE needs to store 6.2 GB of housing data. If we keep extending our fun worst-case scenario, this goes up to a maximum of 242 GB.

Let's pad that out a bit, because it's hard to account for everything. All this data will be stored in some sort of database, so there's some overhead there, too. So. Let's double it. Our best-guess calculation then becomes about 12.5 GB of data for all the housing data, to a max of about 484 GB. By this point, it's pretty clear that the worst-case number is ridiculous, so let's look at the best-guess number, instead.

12.5 GB.

It's easy to say "Hey, you can buy an SSD that stores that much on Amazon for $5", but that's naive. What you really want is something scalable. Something reliable. Something like a Thecus N8810U-G 8-Bay Rackmount NAS Server loaded with 8 SSD drives. That's about $1500, plus another $1200 or so for 8 500GB SSD drives. With a RAID 10 configuration, you get extreme reliability and 1 TB of storage out of there for $2700.

With our best-guess data, that would store all the existing wards, plus enough for every server to have 2,880 more wards. With our worst-case data (which is getting more and more ludicrous as we keep piling on those assumptions), it'll still provide double the wards across the whole game. But really, we're talking about our best-guess data.

2,880 more wards. Less than a ward per dollar.

Considering SE gets at least $156 per year per dedicated player, that seems pretty damn reasonable to me.

I really think that they've made some sort of mistake on the underlying architecture when they made the wards, that makes it difficult to change after the fact.

I think the subdivision thing is a good example of this. Why on earth would they make subdivisions (that are annoying to get to, and have no benefit over just more wards). I think they made subdivisions because they couldn't just make more wards for some reason. I think they've been working on a fix since then, and finally have something (hence more wards).Â

Clearly they just didn't expect the desire for housing (else they would have done it differently) and I think whatever solution they originally put in place just doesn't scale up well. I mean, if it's not an architecture issue, then why wouldn't they just add more wards? Because they're lazy? Because they don't feel like it?Â

I think your example assumes everything done in an optimal way, which if you look at SE's history with this sort of stuff, is rather unlikely. Things like this can been seen all over the housing, from the subdivisions, to the orchestron's not playing high quality versions of songs (which is apparently also due to performance issues).Â

I agree it's silly they can't just add more wards, but I think it's a little harsh to hold them up to perfect standards. I do believe it's due to performance issues, and I do think it's just something they need to figure out on their end. Whether or not those performance issues are due to incompetence is another question.

3.3 & 3.4 Housing Updates

RPC has moved! These pages have been kept for historical purposes