Regarding the Response to Physical/Magical Damage in Flying Text

[qazqi]

For context, iluna in the FF14 discord posted a translation of comments about this from Live Letter 60:

Q: 敵の攻撃が「物理」か「魔法」かをフライテキストで判断できると便利だと思うのですが、今後実装する予定はありますか？ バトルの難易度にも影響すると思うので、簡単に決められるものではないと思いますが・・・。
Q: I think it’d be convenient if the flying text for damage dealt by enemy attacks could indicate whether the damage is physical or magical, are there any plans for something like that in the future? It’d affect content difficulty, so I understand that it may be difficult to do so...

Kei Odagiri

可能か不可能かで言えば「可能」ですが、現時点でプレイヤーの皆さんに見える形で最終出力するUIが取得する情報に物理か魔法かどうかというデータは含まれていません。
そのため、これに対応するにはパケットの拡張などが必要になると思いますので、UIセクションとしては可能とも不可能とも言えない感じではあります。

If we’re strictly speaking about whether it’d be possible or not, it’s possible. However, the data relayed to the damage displaying UI doesn’t contain an indication of whether the damage is physical or magical. Implementing this feature would likely make the packets of data larger, so it’s hard for the UI team to determine whether it’d be possible or not.

Naoki Yoshida

パケットの通信量はやや増えるとしても、技術的には可能です。
ただし、あえて対応していない理由があります。
敵の攻撃を物理にするか魔法にするかどうかは、高難度コンテンツではパッチ公開日直前までバランス調整が続き、まれに締め切り直前で特定の方法でギミックを無視して突破できることが判明することがありました。
その場合、バランスを保つために敵の攻撃の物理／魔法を切り替えたりするのですが、この変更をフライテキストに反映するためには、QAチェックのために数日を要します。
そうなると、パッチスケジュールにも大幅に影響が出てしまうので、本件はあえて対応しないことで、安定したパッチスケジュールを担保することにしています。

Even if the packet sizes were increased, it would still be considered possible from a technical standpoint. However, there are other reasons why this sort of feature hasn’t been implemented. For high difficulty content, we’re constantly making balance adjustments up till patch release, and one aspect of that is determining whether each enemy attack will deal physical or magical damage. From time to time, we’ve had cases where a method that allowed you to ignore mechanics was discovered right before the deadline for patch release.

This is sometimes resolved by changing physical damage to magical and vice-versa, and reflecting this sort of change in the flying text would require another several days of QA testing. This would in turn affect the patch schedule, so we’ve intentionally refrained from implementing such a feature in favor of securing a more stable schedule for patch releases.

I'll preface this all by saying that my field is Software Engineering. I'm aware of the usual caveats from a post like the following one. It's also an old Q&A, but particularly relevant to current discussion.

(My response is in the next post due to length limitations.)

[qazqi]

I'll concede that packet size might need to get bigger if you have the server send the damage type along with the damage and weren't already sending that. That would probably even be the better way to do it since it's fully reliable.

As far as I can tell, the plugin that does this works by reading the static game files that are downloaded from the launcher. It gets that data via the more generic plugin framework, which uses a library for reading game files. Within this static data is a table of actions and their damage type, suitable for implementing this feature completely client-side with no server changes whatsoever.

In terms of feasibility to implement this feature the same way the plugin does, simply keeping the relevant parts of this table around in memory 24/7 is a very small increase to memory usage while the game is running, but it's not 100% reliable unless the game data itself is changed to contain 100% of the information. The plugin claims to have some cases where it cannot detect a mismatch between the type while the action is being cast vs. when the damage comes out. The static game data could potentially be changed to cover these cases.

What I really have a problem with is Yoshi P's response.

If you mean to say that you would need to change the flying text code when you change the damage type of something, this is not what anyone is asking for. You do not touch the flying text after you touch it once to add support for displaying damage in the appropriate colour. Once that support is there, all you change is the action itself, whose data will propagate through to the UI when it's time to show the flying text. Changing anything about the flying text code when you change the damage type of something would be awful software engineering.

Now you said QA specifically. If you instead mean that you require extra QA time to verify the change of damage type, that's another red flag. QA should absolutely already be checking the damage type. QA testing that the flying text displays the correct colour is a one-time thing that happens when you change the flying text, or at least until you're confident it works.

Let's examine the cases for testing that the damage type changed at the last minute:

If you have an internal debugging tool to display the damage type to the QA testers so they can verify it, then you're a hair away from implementing this feature already. It might be a quick hack right now, but can most likely be polished up into an actual feature.

If you don't have such a tool, then once you're confident in the flying text change, you've made QA's job much easier for all future damage type checking by adding this feature. Rather than whatever tedious method they were using to verify the damage type of each action, they can rely on the flying text. Perhaps you'd use a debug version that supports every damage type instead of only physical vs. magical.