Frustrating Design

[Tridus]

1. Why the need to keep the saddle-bag something separated from normal bags? How does it increase the playing experience? Restriction can enhance the playing experience, but these do not.

It's not meant to increase the playing experience. The way the client/server interaction works is that there is frequent state syncs, where the server sends the full state to the client, including inventory. More inventory = more data to send. Multiply that by thousands of people logged in simultaneously and the server load becomes significant. YoshiP has said they can't easily increase inventory space due to this problem.

Chocobo saddlebags are a seperate thing. The primary difference is that they aren't available while crafting and they aren't available in dungeons. For crafting, that lets them ignore that extra state while crafting is going on. In dungeons, it means they don't have to transfer the contents of them to the instance server, as you don't have it available there. It also means less state transfer, because as it's locked out, the client doesn't need to know about it.

This stems from design decisions made in 1.0 that were frankly poor decisions but that everyone is stuck with now. Changing that stuff is hard in a game in production, would require significant resources, and would likely lead to instability once a new version was pushed out at scale. While it'd be a useful exercise, it's hard to get the time and budget to justify it when people want that budget going to new content.

Saddlebags were added the way they were specifically because it allowed them to add more storage (something people wanted) in a way that doesn't overwhelm the existing infrastructure and netcode. They know it's suboptimal, but that's the price of technical debt. (A better optimized MP game would sync initially and then simply keep track of changes on both ends, doing fewer full syncs. That helps server load significantly, but opens up the risk of desyncs in the client state. Which is why changing it is so hard.)

2. Why opening the MB must close my bags, even though I can actually have my bag open when I use it (if I re-open it later)? Why instead the saddlebag need to be restricted from opening when MB is open? (double confirmation is when you popup a "are you sure" dialog box as a consequence of my click to execute something)

I don't know why inventory bags would close in that case. For saddlebags being closed and unavailable, see my previous answer.

4. MB prices not visible from retainers means I need to go back and forth (or use paper to take notes) when I need to sell multiple things.

If it's an item you or your retainer has, you can see prices at your retainer by using the option to list it for sale. You can see prices and historical sale prices without actually listing it for sale from that dialog.

5. Why do you need to waste my time with useless pauses? When NPCs emote during a conversation (walking away at the end included), when I auto-skip an already seen cutscene etc. Granted they last 1-2 seconds or less, they still have no reason to be. It's not immersive, and it's not enriching gameplay.

NPC emotes in a conversation are part of immersion. If you don't like it, that's cool, but that's a deliberate design decision. I like them, it feels like talking to someone instead of getting a glob of text like what WoW would give me.

My understanding on cutscene skips is that the skip option is client side. So the way the code works is you trigger the cutscene by whatever condition activates that (getting to the end of the dungeon or whatever), and the start of the playing code is what checks if you should skip or not. If true, it bails out. Moving it to check before going into the cutscene viewing code (ie: at the trigger condition point), would make the code more complicated.

Fundamentally, there's lots of non-optimal stuff in this game on the technical side, due to there being a lot of bad decisions made in 1.0 and 2.0 being built off that. It kinda sucks, but it's the way it is now, and it'd take considerable time and budget to fix it all.

[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.