Why is the Post-MSQ Content so Passive in Endwalker?

[Sjol]

You could even break down FF16 to be using a lot of things that FF14 can do.

I guess I'm wondering why they would want the two systems to be the same. MMO engine design and Action-oriented RPG design are very different. I can understand that they share a lot of commonalities, and it seems that based on interviews they started with XIV for at least the preproduction stuff.

I certainly wouldn't want to use the gameplay processing from my MMO for my action RPG or vice versa. Rendering pipeline, sure. Asset sharing, sure -- your comment about the eat animation. But there are so many things where those systems wouldn't well align as I alluded to. How you would implement glam systems in XIV and XVI would vary greatly. In XVI you could cache the specific choices the character had made and load them quickly. In XIV you can cache your own, but you can't cache everyone else's. You don't know who's going to pop onto your screen until they do. And when they do, they can also quick change. Which means you need to have all the assets for all their potential equipment swaps as well. It's just a different set of needs. FFXIV assets are probably a lot more memory intensive than a lot of MMOs, especially for when it came out. XVI doesn't need to be able to randomly fetch assets because another networked player popped into view.

Responsiveness is another big change. The gameplay loop in XIV has to account for a lot of network latency and has netcode. XVI doesn't. XVI processes locally on a fast CPU and GPU meaning you can tune the engine for low-latency responses. Why would they do that for XIV? Why tune it for low latency when the floor for XIV in terms of latency is orders of magnitude higher than for a locally processed PS4?

I'm not saying XIV is bad, though it is older and still needs to support bad hardware. But the devs have repeated said that they can't do certain things because of technical debt / spaghetti code from 1.0. I choose to believe them, and I do not judge them for it. I just have an understanding that there are likely some things that are difficult to pull off with their current codebase and execution engine -- half which lives on our machine and half on their servers.

They've likely done their best trying to build on top of sometimes shaky foundations all the while living under extremely tight deadlines. I do not envy them.

[Jeeqbit]

the devs have repeated said that they can't do certain things because of technical debt / spaghetti code from 1.0.

Untrue. See my signature for proof where Yoshi-P himself debunks this.

However, while there isn't technical debt from 1.0, there is likely technical debt from 2.0, since like a stack of cards the entire game (4-5 expansions) are now built upon the foundation that is ARR.

Still, this doesn't seem to faze them. Reworking the physics, adding a world visit system and DC travel, overhauling the loading code so it's faster, overhauling ARR MSQ, overhauling old dungeons, adding flight and diving to ARR, overhauling the graphics and most recently announcing they will overhaul the character creator. These things would have likely been a can of worms to change, but they did it anyway.

I think people just mistake issues that stem from using physical servers instead of cloud servers as "spaghetti code". They also mistake "console considerations" and "average PC considerations" for "spaghetti code". They also mistake things like the distinction between hunts and FATEs as spaghetti code, but I don't think that's really the case, they are just separate. Separate things are valid in a code context, even if the difference is hard to see for a lot of players.

[Sjol]

Untrue. See my signature for proof where Yoshi-P himself debunks this.

...snip for length...

I think people just mistake issues that stem from using physical servers instead of cloud servers as "spaghetti code". They also mistake "console considerations" and "average PC considerations" for "spaghetti code". They also mistake things like the distinction between hunts and FATEs as spaghetti code, but I don't think that's really the case, they are just separate. Separate things are valid in a code context, even if the difference is hard to see for a lot of players.

With no disrespect to Yoshi P., he's not a code developer and isn't omniscient when it come to the state of his own codebase. No one could be with something that big. I'm sure there's some technical debt in the engine they ported over. Also, technical debt is a constant in any codebase. You will have some amount of it no matter how diligent you are. And with tight deadlines, people are going to take shortcuts in order to get cool thing out the door before the release window. Technical debt can also be not just code, but ideas engrained in the design of the data.

Other people may confuse "average PC considerations" for "spaghetti code". I'm not one of them. I'm also aware that cloud servers aren't a magic bullet that would save the game. A lot of cloud services aren't designed for that kind of compute, more B2B and some B2C scenarios. It's more likely that the design that they've built on top of that worked when they started and was designed under the constraints of the time is extremely difficult to unravel. In my development world, that difficulty is technical debt. Tech debt is the thing you need to pay off before you can do the cool new thing you really want to do.

I would bet money that retainer and character inventories are modeled identically, probably in the same database storage which is why they are the way they are in game. We can't have a unified inventory because they don't want to load all the various character records into memory at the same time. Being able to buy additional ones just makes it that much more difficult to change. Crafting from inventory probably naturally fails due to the same limitation.

I would also bet money that the limitations around accessing and transferring inventories on so many screens is because their system doesn't have the server-side guardrails to prevent accidental or intentional data corruption (e.g., duping). So, instead the UI locks a lot of screens to prevent you from consuming an item and transferring an item at the same time. Note how the Use button is disabled in item transfer scenarios (e.g., chocobo bags or retainer inventories open). There's a lot you can figure out about the design of a mature system by observing its behaviors and limitations.

[Jeeqbit]

With no disrespect to Yoshi P., he's not a code developer

He has stated that he understands code. He believes anyone getting into the game industry should have at least had a go at coding something, even if it's something really basic, so that they have a better understanding of how code works. It would be strange to say that if he himself did not have that understanding. Without a little experience of using it, they can have all sorts of wild and vague ideas about how coding actually works.

I'm sure there's some technical debt in the engine they ported over.

There was. The full interview that I have linked clarifies that there was a problem with the collision (fixed now), a problem with chocobos not being regarded as pets and being a party member (fixed now) and I think there was one other thing. But they addressed all of it they said.

They also explained it pretty well. "We rebuilt it from the engine". That means getting a brand new engine and adapting it for an MMORPG. Brand new classes and objects. They most likely ported things over, but for the most part it wouldn't make sense to do it in a sloppy way when the goal should be to make it tidy and object-oriented.

Now there might have been a few odd situations where they had to do it in a sloppy way due to time constraints and these are the situations they told us about but say were addressed.

Also, technical debt is a constant in any codebase. You will have some amount of it no matter how diligent you are.

I agree and that's why I tend to think it's more realistic to call it "2.0 spaghetti code" than 1.0 spaghetti code, because the game has evolved beyond a lot of the original 2.0 principles the game is built upon and that has got to make it challenging to adjust.

And with tight deadlines, people are going to take shortcuts in order to get cool thing out the door before the release window.

I've definitely seen that happen by game developers, but ultimately, if it's such a big issue that it is preventing work on new features or changing existing ones, you would think the programmers would have told their boss. If they haven't told their boss, then what excuse are they making instead for not be able to do things?

Technical debt can also be not just code, but ideas engrained in the design of the data.

I think it's more that, honestly. They have all sorts of ideas and misconceptions. Take the lodestone for example - a website that looks like it's from the early 2000s with blogs and other concepts like it and features that should be in the game.

One of the biggest ones is the "you can't do x, y or z" because "you have to carry the data with you" and "you can't retrieve x item" because "you aren't on y physical server". It immediately makes you think it's a style of thinking or an entrenched idea of how to setup their server structure, because many games don't have those sort of problems and there are all sorts of ambitious ideas I can come up with to solve those problems regardless of how entangled their code is.

Another example is how they said with confidence it's not possible to show on the tooltip that you obtained an item already. I was engulfed with doubt over that and they proved it by doing it shortly after. So mindset seems to be playing a part in it.

Of course, these ideas have shaped how it's all structured and that can be difficult to change, but it doesn't make it impossible to change with data transfers, migrations or bridges.

They could even just let players do the migration by saying "here's a brand new inventory system that is much better, old players can still access their retainers to remove items but they can't add them back in".

It wouldn't surprise me if they end up having to meticulously plan which scenes get The Money and which scenes get the stock stuff.

They do. When designing an ultimate they have limited development resources at their disposal, but they want it to be cinematic so you can enjoy it on twitch (since they expect more people will watch it than actually clear it), so they invest some of their resources into making it look good to a viewer.

In general, they have said they slowly improved the cutscene system to do more than just discuss things like it did in ARR and that they will continue with interesting ideas (like the one where Tesleen becomes a sin eater which they explained in detail at a development panel).

[Sjol]

There was. But they addressed all of it they said.

.snip.

They also explained it pretty well. "We rebuilt it from the engine". That means getting a brand new engine and adapting it for an MMORPG.

.snip.

I agree and that's why I tend to think it's more realistic to call it "2.0 spaghetti code" than 1.0 spaghetti code.

.snip.

I think it's more that, honestly. They have all sorts of ideas and misconceptions.

.snip.

Of course, these ideas have shaped how it's all structured and that can be difficult to change, but it doesn't make it impossible to change with data transfers, migrations or bridges.

In my experience brand new engine doesn't mean starting from scratch. It's mostly a marketing thing and it means you've made sufficient changes to how the engine works you feel comfortable slapping a 2.0 or a new name on it. Engines are tens of millions of lines of code sometimes and starting from scratch would be irresponsible.

If it is code written in 1.0, 2.0, or later I don't think it matters to their overall situation. Tech debt is tech debt.

The issue is that there's all these systems built on top of those base data structures. "Bank" inventory mapped to character records and retainer interactions done as trades behind the scenes (I don't know this for sure but I very, very strongly suspect it).
This design, which is now tech debt prevents them from doing unified inventory, craft from inventory, and dedicated crafting storage. I don't know if that system came from 1.0 or 2.0 as I wasn't around, and I don't feel like doing that particular research right now (bad on me). Nor does it matter to me if it's from 1.0 or 2.0. It's the system they have.

They also built the market on top of the retainer system, and they created a financial reliance on them as well. That could be solved by creating a unified storage system that expands as you buy retainers.

The problem with adding the extra storage while keeping the retainers in read-only mode is that they still just doubled their storage costs. Even if the problem would eventually be partially self-correcting -- unsubbed players still expect to be able to come back to their stuff -- there's no end date where they would be able to fully transition as long as it was in players hands.

The alternative to waiting on the players is to do the migration themselves, but they've shown poor bulk update performance. It takes a lot of time to migrate trillions of rows in your various databases, so you'd be looking at multi-day downtimes probably presuming everything went well and a cluster-f@$% if it didn't.

It's not to say I don't think they couldn't do it eventually. I just think the thought probably rightfully terrifies them.

[Jeeqbit]

In my experience brand new engine doesn't mean starting from scratch. It's mostly a marketing thing and it means you've made sufficient changes to how the engine works you feel comfortable slapping a 2.0 or a new name on it.

The engine they used for 2.0 wasn't new, but it was not the 1.0 engine. They heavily adapted it from a single player engine to work for an MMORPG.

If it is code written in 1.0, 2.0, or later I don't think it matters to their overall situation. Tech debt is tech debt.

I'd agree more in the context that it's 2.0 and later tech debt since they denied there was any significantly still around from prior to that (or tech debt from adapting a single player engine).

I don't know if that system came from 1.0 or 2.0 as I wasn't around, and I don't feel like doing that particular research right now

From what I recall, they went to the Calamity Salvager to re-obtain items from 1.0. They also had to re-hire any retainers they had in 1.0. They have proven themselves able to do this again (for example when they removed belts or when your house gets demo).

The problem with adding the extra storage while keeping the retainers in read-only mode is that they still just doubled their storage costs.

With a big enough operation, they could probably just move it all over if they can do it in 48 hours. Or they could only unlock the "extra storage" upon login so that it doesn't increase storage considerations for inactive characters. I think in Stormblood an inventory increase they did was gated behind story progression.

there's no one developer who has a good grasp on what must be millions or tens-of-millions of lines of code

Just because a company has millions of customers doesn't mean that their code is very complicated. In a big way, this is why object-oriented programming is pushed hard by people. It's infinitely more difficult to grasp when it's not done that way.

It's also why scripts are used. Scripts were a major problem in 1.0 because they relied on them to such a point that both the server and players were taking ages to do basic operations. But they definitely still use lots of scripts, tables and shaders.

It's impossible for a human being to keep that much detail in their head, even extraordinary ones.

One game I worked with wasn't object oriented. It took me months to grasp the different functions illogically put in different files and map them in my head. But eventually, I did. If they've been working on this game for years, they should have it mapped out and know their way around it by now.

[Ancalagon_Blacktalon]

Just because a company has millions of customers doesn't mean that their code is very complicated. In a big way, this is why object-oriented programming is pushed hard by people. It's infinitely more difficult to grasp when it's not done that way.

oh I would bet it is currently very complicated due to two aspects of their particular tech debt burden:

- Them having to rush all the changes to get ARR out and working at all, which is an environment that tends to lead to less-elegant solutions for complex systems. On top of this, technology was a bit different a decade ago than it was today, so they could've also been having to write stuff around technical limitations that aren't in effect any more, which makes it harder to read/parse/change.

- Time. The issue with all the time passes is that now you not only have spaghetti code originally written at the time, but now they have 10 years of fixes and changes layered on top of it which makes it even harder to change things without breaking other things. On top of this, it is pretty likely that they lack the knowledge base of the game's original coders due to time passing (and as you stated, it is also impossible for a single person to have that all in their head too). If their documentation is bad, it means that anyone that needs to make changes or fixes has to guess and pray.

I had stated in another topic at some point that this kind of thing hits home for me because professionally I am currently mired in this kind of hell! :thumbsup: except in my case it's 30-year-old code running on a programming language no one teaches anymore LMAO

[Sjol]

He has stated that he understands code. He believes anyone getting into the game industry should have at least had a go at coding something, even if it's something really basic, so that they have a better understanding of how code works. It would be strange to say that if he himself did not have that understanding. Without a little experience of using it, they can have all sorts of wild and vague ideas about how coding actually works.

My point was less that he could code and more that he wasn't a developer actively working on the FFXIV codebase. Even if he was, there's no one developer who has a good grasp on what must be millions or tens-of-millions of lines of code and dozens upon dozens of systems. It's impossible for a human being to keep that much detail in their head, even extraordinary ones.

It's also possible you and I have different definitions of tech debt, but I've literally never seen a large system that didn't have it in non-trivial quantities. Smaller open-source projects can sometimes effectively excise all their tech debt, but they're on their own timetable and have the luxury to fix it.