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

[Sjol]

Better animations instead of just clicking and getting a loading bar, such as pulling down a lever to make a lift work, climbing a ladder properly, pushing a door open with your hands. Characters talking with you while you fight and walk. In the FF16 event, they made use of the dodging system from FF16. In the nier raids, we hang onto something and slide down. Even in the FF15 event, we used the thing that pulls you to different objects.

Those all seemed to be variations on things we can already do. We already have jumps and hidden buffs (dodge = teleport move + hidden invuln buff on a short timer)

Engine being what it is capable of. Gameplay being what they decided to do with the engine.

FF16, as far as we know is based on the FF14 engine. So what does that tell you? They could be doing anything you see in FF16, in the FF14 engine, but they decide not to.

They have also shown, in unique fights and crossovers, that they can do all sorts of things, and have really cool animations like E4S giant titan, different styles of fight like Rathalos, yet continually revert back to the old style of game after it which involves clicking and loading.

Based on and forked years ago doesn't mean that it's the same. Also, could be doing anything that they were doing in FFXVI ignores a lot of differences between how FFXIV and FFXVI work. Certainly, they don't need to load 50 customizable outfits dynamically based on anything. And with respect to the engine, we're probably also only talking about pieces of it -- certainly not inventory management or any of the networking stuff. Rathalos was interesting, and he did introduce a couple of new ideas, but ones that don't seem too outside what is already possible in their combat system -- ignoring enmity and blocking healing.
m

So the point is that if they wanted to make this better, they absolutely could go to FF16 and copy and paste some things. And maybe even to a degree, they might do so with the graphics update. But it's all self-imposed limitations, where they worry about how people's PCs will handle it due to other players, rather than engine limitations, otherwise we wouldn't have FF16.

Visual fidelity requires GPU, but I've seen some neat ideas on older games with much lower processing requirements. I'm not looking for amazing graphics. Graphics aren't gameplay. Mostly, I think the problem is they have is around AI, including pathing (where are my wandering monsters), and secondary systems like inventory management and asset management.

[Jeeqbit]

Those all seemed to be variations on things we can already do. We already have jumps and hidden buffs (dodge = teleport move + hidden invuln buff on a short timer)

You could even break down FF16 to be using a lot of things that FF14 can do. The FF16 event even shows the contrast well. They just overtelegraph everything in FF14 and give you a lot of time to react compared to a single player game. It's clearly a deliberate decision, rather than an engine thing.

Based on and forked years ago doesn't mean that it's the same.

Similar enough that if they did make changes, they could go to their team members in the FF16 office next door and ask to copy some of their code over or make a work based upon it... it also feels like they did do this for the burger eating stuff.

Also, could be doing anything that they were doing in FFXVI ignores a lot of differences between how FFXIV and FFXVI work. Certainly, they don't need to load 50 customizable outfits dynamically based on anything.

That's their reasoning for a lot of the reduced quality.

But I think some of it is just that they were trying to copy the "target, click, loading bar" concept MMORPGs at the time had, and now find themselves with competition that is far more realistic than that.

And with respect to the engine, we're probably also only talking about pieces of it -- certainly not inventory management or any of the networking stuff.

Well networking isn't relevant and the inventory in FF14 involves networking as a core part of it, so they would have to be different.

Rathalos was interesting, and he did introduce a couple of new ideas, but ones that don't seem too outside what is already possible in their combat system -- ignoring enmity and blocking healing.

That's sort of my point. A fight like Rathalos has always been possible in the current engine (and even gets done in Stone Vigil HM), they just decide to do it differently most of the time. These are decisions, rather than engine limitations tbh.

Mostly, I think the problem is they have is around AI, including pathing (where are my wandering monsters)

They actually use the standard "walk in a random direction every few seconds" system that many games have used. I always hated it and felt, as someone who can code this sort of stuff, that it could be done in a more ambitious and realistic way. And even if automating it runs into issues there can be pre-determined pathing like there is for NPCs in the city states.

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

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