Frustrating Design

[Dirich]

your post

Thanks for the very in depth reply.

I don't see why the state of the inventory must be constantly synced with the server. If it's closed, no syncing is necessary, if it's open, you can sync on action (which is low rate due to being human interaction) or even batch the changes (at risk of losing the batch in case of crashes). Also, as you mention, this stuff is done by transmitting the changes and not a full snapshot of the state.
Ok, it's from 1.0, but how on earth can a major software house that's been around since the 90s (at least and afaik) end up with issues of such a basic nature. It's literally programming 101. Then again, I've seen codebases where literally everything was handled via the equivalent of std::list, so maybe I should wonder why this kind of stuff still surprises me.

5. I think there's been a small misunderstanding. I'm not against emotes in dialogues, those do add to the immersion. What I am arguing is that there is no reason to block character movements while a moogle is waving his hand, turning around and walking into the sunset.
The example is one of many from the daily moogle tribe quest. After a month of doing them, I just skip the text, but I can't skip that 1-2 seconds pause of wait for the moogle emote script to end, even though my character is not doing any emote.

3. I updated the second post with an example of excessive double checking: teleportation. Excessive to ask for confirmation since you can stop the teleport cast anyway.

[Squintina]

Ok, it's from 1.0, but how on earth can a major software house that's been around since the 90s (at least and afaik) end up with issues of such a basic nature. It's literally programming 101. Then again, I've seen codebases where literally everything was handled via the equivalent of std::list, so maybe I should wonder why this kind of stuff still surprises me.

Oh I can answer that one.

Handling data for offline games is simply not the same as handling it for online games. With offline games it mostly comes down to console itself (ram, cpu). With online games you have to account for bandwidth and the amount of people pushing said bandwidth at the same time.

With that same thinking there's also a difference in games that are online but with a smaller data scale (such as the Triad online game that existed) and an MMO with inventories.

FFXI was their only other data-heavy online game before this and it was a completely different team working on it. Simply speaking, whoever worked on 1.0 didn't have the large-scale online experience for it. They then chose to reuse some of the assets of 1.0 for 2.0, not fully thinking out into the future (and honestly given what happened to 1.0, who'd have thought 2.0 would become so popular? They mostly just wanted to get it to be good enough to stop being a big stain on their brand)

Of course they need to figure out how to get away from the 1.0 base code or else this game won't last many more expansions.

[Dirich]

your post

You are right.
Still, I've been there (starting from HPC background), and I've seen others been there and I've never seen anybody get it wrong. You need to completely disregard the hardware having physical limits in order to get this particular detail wrong, but if there is an industry that deeply think about (cores and caches) physical limitations it is the gaming industry.
Probably it was the work of someone new and they were not really doing a good job with code reviews.

Regarding the full replacement of the legacy code, I have to agree with others: between spending a year or two rewriting it, it is more cost effective to spend such time to develop new content to retain your current playerbase. They would otherwise be developing what could be rebranded as FFXVI (or FFXVII or whatever number they'd be at by the time they are done with).

[Tridus]

Thanks for the very in depth reply.

I don't see why the state of the inventory must be constantly synced with the server. If it's closed, no syncing is necessary, if it's open, you can sync on action (which is low rate due to being human interaction) or even batch the changes (at risk of losing the batch in case of crashes). Also, as you mention, this stuff is done by transmitting the changes and not a full snapshot of the state.

If it's closed, some things still need to be known (if you have a quest item, if it's full, if you do a search on something someone links), but yes, all of that could be synced when you login and simply updated with changes rather than resynced constantly. I have no answer for why they did it that way, except perhaps they thought it was better than doing the work to avoid desync bugs. Clearly, scaling wise it was a mistake.

Ok, it's from 1.0, but how on earth can a major software house that's been around since the 90s (at least and afaik) end up with issues of such a basic nature. It's literally programming 101. Then again, I've seen codebases where literally everything was handled via the equivalent of std::list, so maybe I should wonder why this kind of stuff still surprises me.

Nobody here is going to know why those decisions were made. In certain things, Japan is well behind the times in software best practices, but they should have known this from working on XI. The current team is pretty much stuck with it unless they can get the go ahead to put the work in to change it. I'm sure you're aware of what a big deal a change like that would be, although IMO it's the correct thing to do for the health of the game. It would solve so many limitations they run into now.

5. I think there's been a small misunderstanding. I'm not against emotes in dialogues, those do add to the immersion. What I am arguing is that there is no reason to block character movements while a moogle is waving his hand, turning around and walking into the sunset.
The example is one of many from the daily moogle tribe quest. After a month of doing them, I just skip the text, but I can't skip that 1-2 seconds pause of wait for the moogle emote script to end, even though my character is not doing any emote.

Ah, I see.

3. I updated the second post with an example of excessive double checking: teleportation. Excessive to ask for confirmation since you can stop the teleport cast anyway.

That's just a UI thing, and I have no idea why they do it. I tend to agree it gets excessive. Console players have it a bit easier there because it's just another button tap, but I find some of those dialogs aren't all in the same place with a mouse so I have to move around to confirm and it's kinda tedious. I certainly wouldn't complain if they changed it. Perhaps you should post that sugestion on the UI forum.