New info on housing plots, PVP, squadron changes

[Berethos]

Other MMOs can do it just fine.

Really?

Which MMO generates entire housing zones that then act as permanent, always on zones, on the fly, that also happen to provide features that essentially have to always be "on" like Chocobo Stables and the Market Board?

All the ones I've seen dynamically scale the number of individual instanced housing plots (Wildstar, ESO) or have a set number of zones (LOTRO, which does have a LOT of housing wards but also has severely limited customization with housing items as a result).

Dynamically scaling the availability of housing areas can be easier or much harder based on how those areas work - something to consider before throwing around the "This other MMO does it, XIV should be able to easily as well." The details of how they do "it" are important, after all.

[Paladinleeds]

snip

Ok, so let's tackle this. Since you've mentioned other MMOs, and what they do, how could we translate this to FFXIV?
Dynamic scaling: So, make it so it's only loaded when a user is accessing the area. If needed, potentially put a cap on the number of instances that can be loaded at once.
Chocobo stables: Tie this into a "Holding area" (similar to the area outside apartments for apartment residents).
Marketboard: See "Chocobo stables".

This is why I suggested in another thread to tie it into a new area, so that the backbone (someone has mentioned inn rooms to act as a starting point for the code re-use, since these already dynamically generate, they just need expanding for housing adjustments) can be made for this without breaking the other areas. Ishgard maybe? Can even tie in MSQ requirements to be able to purchase (though we'll need some handwavey magic for FC housing and members accessing without completing the relevant MSQ, maybe look at how Shirogane does it?) so as to keep within the post-DSW.

There we go, some ideas on how FFXIV can do, like these other MMOs.

Instead of instancing by server, instance by player and allow visitation by others.

Isn't that how RuneScape does it?

[kikix12]

All the code, except for dynamic increase of instances (which shouldn't be too difficult to write, seeing as it would only make a check here or there and either copy a set data or not copy it), is already in the game.
Most importantly, there are apartments that are instanced locations which players can customize.

I don't want to hear this "inside or outside" crap. There is no such thing in this game. It's just graphical talk, there is zero difference for the games engine. Every instance have its set parameters, and the only difference between "inside" and "outside" is how the parameter that allows or denies certain pieces of furniture be placed is set. The other differences are superficial, in that they decided to make the outside a large instance with exits into many smaller instances. That have nothing to do with the code at all. It's just how they designed it, and there is zero reason why they couldn't do a single-plot sized instance with a single exit into a single "inside" space. The entirety of the code exists.

Why they are not doing it is clear. Money. Housing with customization does require significant amount of computing power and drive space. They would NEED to buy new physical servers to match the demand. And they find the expenses exceeding the gain. Simple as that. Everything they say about how it's not possible or whatever are just excuses to shush as many people as possible. It's a business. They lie. That's normal. As long as they lie as to why they don't bring something that they never did make a promise for, there is nothing "wrong" with that.

The only solution is to hope that whatever bonzos at Square Enix treat Final Fantasy XIV as cash cow for other projects will finally see it as a stand-alone game that should be invested in more significantly from the huge funds it earns, instead of moving that money into multiple unrelated crap-games.

[Berethos]

I don't want to hear this "inside or outside" crap. There is no such thing in this game. It's just graphical talk, there is zero difference for the games engine.

Pretty big difference between the insides (which are ALL dynamically loaded based on when a player is there or not, for every house in the game) and the outsides, which are always loaded, even when a player isn't there. And it's setup that way because of certain features the game allows players to access in that area (like the Market Board). I'm sure it's possible they could make it so those outside areas also dynamically load and connect all the relevant stuff...but what does that do for the stability of the feature/zone/server when it has to do that for 72 different zones?

Ignoring that and acting like there is no difference is just putting your head in the sand.

[kikix12]

Pretty big difference between the insides (which are ALL dynamically loaded based on when a player is there or not, for every house in the game) and the outsides, which are always loaded, even when a player isn't there.

Wrong. Even if it is like this, it's got nothing to do with the code. It's just a decision they made to follow. And the reason for that that I believe is just to make the instances more suited to completely unrelated people stumbling across each other, rather than for whatever features you seem to think of.

Market board, retainers and the like all are no different than armoire or aesthetician. They are separate pieces of the database that work separately from the remaining code and are active only "on demand". The proof is easy. Try to do something unrelated to these things when having those open, like change class or use food. Aesthetician aside, of course. You won't be able to. Why?! Because at the moment, you are connected to a different database. It's like trying to overwrite a file that's open in a different program.

I am talking about supposed limitations of the code, you are talking about the way the code is used. Those are two different things. Don't mix them up. For the code, the inside and outside are no different. An instance is an instance. If they can make a large limited in amount instances that allow gardening or stables, they can make small, unlimited in amount instances with the same characteristics. They can...provided they have the hardware for that. That's all it boils down to.

[Claviusnex]

First I want to say that I have always considered any move to instanced housing as a parallel system to the current ward system. If people want to be in a ward and are willing to live with the wait and restrictions I see no reason not to allow it.

All the code, except for dynamic increase of instances (which shouldn't be too difficult to write, seeing as it would only make a check here or there and either copy a set data or not copy it), is already in the game.
Most importantly, there are apartments that are instanced locations which players can customize.

I don't want to hear this "inside or outside" crap. There is no such thing in this game. It's just graphical talk, there is zero difference for the games engine. Every instance have its set parameters, and the only difference between "inside" and "outside" is how the parameter that allows or denies certain pieces of furniture be placed is set. The other differences are superficial, in that they decided to make the outside a large instance with exits into many smaller instances. That have nothing to do with the code at all. It's just how they designed it, and there is zero reason why they couldn't do a single-plot sized instance with a single exit into a single "inside" space. The entirety of the code exists.

This is what I have been saying for a while. SE could build a parallel housing system that is fully instanced. This would allow the interior and exterior to share the instance that is only instantiated when a player enters their property. In fact making the exterior and interior part of the same instance resolves the small number of exterior furnishings currently allowed with the ward system. Another problem it could resolve is the inability to upgrade the house without moving. It would also make system resource management easier in a number of different ways.

Why they are not doing it is clear. Money. Housing with customization does require significant amount of computing power and drive space. They would NEED to buy new physical servers to match the demand. And they find the expenses exceeding the gain. Simple as that. Everything they say about how it's not possible or whatever are just excuses to shush as many people as possible. It's a business. They lie. That's normal. As long as they lie as to why they don't bring something that they never did make a promise for, there is nothing "wrong" with that.

The only solution is to hope that whatever bonzos at Square Enix treat Final Fantasy XIV as cash cow for other projects will finally see it as a stand-alone game that should be invested in more significantly from the huge funds it earns, instead of moving that money into multiple unrelated crap-games.

SE doesn't need to buy dedicated servers if they design the instanced housing system correctly. All they need to do is lease a dynamic server pool from their datacenter provider and have the system add or remove housing instance servers as needed. It is a concept that has been around since the 1960's in one form or another and is being done everyday. With the pool SE would only pay for the system resources when they are in use and not have to waste money with privately owned servers that will likely sit idle much of the time. My gut also tells me that a dynamic housing system would probably cost less than the ward system they use today.

[kikix12]

SE doesn't need to buy dedicated servers if they design the instanced housing system correctly. All they need to do is lease a dynamic server pool from their datacenter provider and have the system add or remove housing instance servers as needed.

I think, though I may be wrong, that Square Enix bought the company that owns the datacenter, and that the savings from having the servers under their own umbrella were why that location in particular was picked. Hence, they'd pay in one way or another all the same.