Enmity System Explanation and Planned Adjustments

[Camate]

Greetings everyone! As promised, Producer Akihiko Matsui has written up a rather lengthy post about the current state of the enmity system, insight into the inner-workings of the system, and planned adjustments.

Apologies that we couldn’t post this up right away, as we were out of the office yesterday for President's Day! (And the whole team recently just came back after a weeklong business trip!)

So without further ado…

Matsui here. Sorry to keep you all waiting so long.

I'd like to take a moment to explain about the workings of the enmity system, which will include some numbers. Furthermore, I would like to touch on the aspects we are trying to adjust.

Before I get into it, I'd like you all to understand that we will not be revealing all of the formulas and inner workings moving forward. Since we are dealing with the adjustment of the enmity system, which is very large, I feel it necessary to know the fundamentals and where we are coming from, and have decided to make a special exception this time.

Due to this, writing up this post was a bit tricky and there is quite a bit of text. However, in order to deepen the discussion related to enmity, please take a moment and read over the post.
--

• The Enmity System
  
  • Quantification
    The enmity system is such that a monster will attack the player that is threatening them the most. In order to determine which player is the most threatening, the parameter known as enmity is used to make it possible to measure and compare the amount of threat.
    
    
  • Purpose
    The enmity system is not in place to make monster AI more intelligent. It's more of a stronger significance for securing battle strategy elements by giving players a means of controlling the monster's target (to some extent).
    
    
  • Types of Enmity (Classification by the method of enmity decay)
    Depending on the method of decay, enmity in FFXI is separated into two groups and logged.
    
    • Time-volatile Enmity
      Enmity which decays over time.
      
      
    • Damage-volatile Enmity
      Enmity which decays when players take damage.
    
    Due to the fact that multiple players are generating enmity against a monster, the work of recording enmity is accomplished by creating a list for the characters. (Though I use the term “enmity list” here, this will not be popping up again in this post.) Based on this list, the monster will target (auto-attack target) the player with the highest value of combined time-volatile enmity and damage-volatile enmity.
    
    
  • Enmity related data embedded in actions (commands, magic, etc.)
    
    • Classification based on how it influences enmity (direct, indirect, none)
      Ignoring the type of actions that have no influence towards enmity, actions are classified into two groups based on how they influence enmity.
      
      
      • Direct
        Players perform enmity generating actions towards a monster, and the monster’s enmity for the player increases. This mainly consists of damage and enfeebling type commands.
        
        
      • Indirect
        A player performs an action towards another player that already has enmity from a monster, and enmity increases towards the player performing the action. This mainly consists of healing and enhancing type commands.
      
      
    • Classification based on how enmity increases are calculated (fixed, effect dependent)
      
      • Fixed
        A set value is added to time-volatile enmity and damage-volatile enmity when an action is successful. This is applies to enhancements and enfeebles that generally do not have numerical results.
        
        
      • Effect Dependent
        A set calculation is added to time-volatile enmity and damage-volatile enmity proportional to the amount of damage dealt or the amount of HP healed
• Finally, the formula
  
  • Defining 1 enmity
    When we were revamping the enmity system for FFXIV I explained a bit about this, but we start out by calculating 1 enmity= 1 damage. Also, system-wise enmity will not decay.
    
    For FFXI on the other hand, while there is quite a bit of management work for dividing the enmity system into time-volatile enmity and damage-volatile enmity, since this isn't sufficient for the amount of damage of NM battles and such, we adopted a method of using a formula for scaling effect dependent type enmity to fixed type enmity, as well as the use of a decay system.
    
    With that said, 1 enmity has been set based on the principle that the amount of time-volatile enmity that decays in a single second is equal to 60 (Since the developers first began making the game on PS2, this was adopted due to the fact that the smallest unit of frame rate measurement was 1/60 seconds.). For example (I'm hesitant to give numbers, but whatevs), the job command “Provoke” is a fixed-type action, and has 1800 time-volatile enmity. This means that this amount of enmity will decay completely in 30 seconds.
    
    
  • Enmity calculation for effect variations
    For each level there is data known as standard damage which is used for enmity calculation.
    *This value was made to be almost the same damage value as the baseline value when weapon data is created (240 attack delay sword).
    
    

    The below is how enmity is calculated at the time of dealing “d” damage:
    Time-volatile enmity = 240*d/standard damage
    Damage-volatile enmity= 80*d/standard damage
    (Standard damage is obtained based on the level of the monster)
    In other words, if you are dealing standard damage every 4 seconds, time-volatile enmity is repeatedly decaying from 240 to 0. Also, damage-volatile enmity is 1/3 of the time-volatile enmity (25% of total enmity), and the coefficient value is 80.
    
    Currently the amount of fire power is much higher than the initially set standard, so I feel we need to rectify the situation where it is easy to reach the cap for volatile enmity by revamping the standard damage used for enmity calculations.
    
    
  • Calculation for the amount of decay of damage-volatile enmity
    When a player takes “d” damage from a monster, the damage-volatile enmity of a monster towards a player decreases.
    
    

    Damage-volatile enmity = 1800*d/player's max HP
    In other words, when a player takes the same amount of damage as their max HP, enmity decays by 1800 (one Provoke).
    
    *This amount can be modified by the effect of Sentinel.
    *1800 might feel a bit rough from the perspective of backline jobs.
    If we were to make this value larger, it would make it easier to get rid of enmity by damage taken, but it would make it difficult for tanks to maintain their target when they take damage. If we make adjustments to this, it will be necessary to look into setting up a special rule of sorts.
    *For healing magic, the value is half of the above calculation.
  
  
• Other
  
  • Enmity increase from resting
    By distancing yourself from the targeted monster at a set distance, it's possible to make the amount of enmity generated from resting zero. The distance is approximately half the distance in which spells can be executed.
    
    
  • Enmity cap
    The enmity limit is common for all jobs and the same is true for time-volatile and damage-volatile enmity. As to whether increasing this cap will make it so players don’t get stuck at the enmity cap, since it is only possible work size-wise for us to raise the value approximately three times of what it is currently, this is not an effective way to go.
    
    While there were suggestions to change the cap values for each job, assuming that the suggestions were based on getting stuck at the cap, if this situation were to arise, it would ultimately boil down to whether you can or cannot maintain the target, so for the current conditions we are currently looking at pairing this with something else.
  
  
• First step for adjustments
  
  • Standard damage (time-volatile)
    First, we are planning to make adjustments to the standard damage. Since we are able to set the standard damage for each level, it will be possible to only adjust this for high levels without affecting other levels.
    
    
  • Damage-volatile enmity
    After adjusting the standard damage, we will make adjustments to damage-volatile enmity.
    The ratio of time-volatile enmity and damage-volatile enmity when dealing damage or curing, as well as the amount of enmity decay when a player takes damage will be adjusted.
    
    
  • Individual commands and abilities
    If there are problems with fixed-type data we will make adjustments.
    
    
  • Content
    The time it takes to defeat a monster with double HP that takes double damage is the same as the amount of time it takes to defeat a monster with 50% HP that takes 50% damage; however, enmity-wise there are large differences. If the damage taken by a monster is suppressed too much, it becomes possible to generate a lot more enmity with actions that have fixed-type enmity as opposed to those that have effect dependent enmity. We will need to check content to see if monster parameters have been set properly with an understanding of these systems.
    

[Dreamin]

the question is when will this be available on the test server for us to have a look at how the actual changes will feel. might even need to do some organized run against some harder NMs since it appears that the planned changes will be done according to mobs/NMs level.

[Tamarsamar]

Your proposed solution is admittedly quite clever; players are reaching the enmity cap too fast? Simply slow down the rate at which they accrue enmity! Brilliant!

However, I cannot "Like" the post for the following reasons.

Before I get into it, I'd like you all to understand that we will not be revealing all of the formulas and inner workings moving forward. Since we are dealing with the adjustment of the enmity system, which is very large, I feel it necessary to know the fundamentals and where we are coming from, and have decided to make a special exception this time.

. . .

With that said, 1 enmity has been set based on the principle that the amount of time-volatile enmity that decays in a single second is equal to 60 (Since the developers first began making the game on PS2, this was adopted due to the fact that the smallest unit of frame rate measurement was 1/60 seconds.). For example (I'm hesitant to give numbers, but whatevs), the job command “Provoke” is a fixed-type action, and has 1800 time-volatile enmity. This means that this amount of enmity will decay completely in 30 seconds.

The above bolded statements offend me. Has SE learned nothing over the past decade of FFXI as well as the past couple years of failure for FFXIV? Obscurity is the least effective form of security; FFXI's players have only suffered from you withholding the meaning of vital game statistics from them, such as Enmity and the Attack/Defense Ratio.

If you all weren't so stubbornly tight-lipped and more freely shared information in general, then maybe it wouldn't take a decade for you to receive feedback on how poorly implemented certain in-game systems are. I don't think you have any reason to doubt the validity of that statement, given that the implementation of the test server is basically the logical conclusion thereof.

So why do you nonetheless continue with the hush-hush attitude? I would certainly hope that this isn't a matter of immature and stubborn pride, and not wanting to hear that a poor implementation was implemented poorly.

[Economizer]

If you all weren't so stubbornly tight-lipped and more freely shared information in general

This was especially frustrating when it came to finding the Cure Formula Changes.

Now don't get me wrong, I'm not asking them to release every little secret on how new monsters or armor works, maybe the game has some aspects of discovery as a matter of the design. But something so common as cures and we can't even get numbers at the time you're asking for feedback on major tweaks?

We know exactly how they work, we knew before they were implemented to the official servers... but did you have to waste our valuable time reverse engineering some numbers just so we could give you some feedback on it?

I don't even think they listened to any feedback we gave on the new cure formula at all to be blunt, especially since it took us some time to disseminate the information to the Japanese players so they could give feedback as well. When a group of English speaking players are a better source of information on something so banal as how cures work then the development team that speaks the same language, you know you have a major problem.

[RushLynx]

Your proposed solution is admittedly quite clever; players are reaching the enmity cap too fast? Simply slow down the rate at which they accrue enmity! Brilliant!

However, I cannot "Like" the post for the following reasons.



The above bolded statements offend me. Has SE learned nothing over the past decade of FFXI as well as the past couple years of failure for FFXIV? Obscurity is the least effective form of security; FFXI's players have only suffered from you withholding the meaning of vital game statistics from them, such as Enmity and the Attack/Defense Ratio.

If you all weren't so stubbornly tight-lipped and more freely shared information in general, then maybe it wouldn't take a decade for you to receive feedback on how poorly implemented certain in-game systems are. I don't think you have any reason to doubt the validity of that statement, given that the implementation of the test server is basically the logical conclusion thereof.

So why do you nonetheless continue with the hush-hush attitude? I would certainly hope that this isn't a matter of immature and stubborn pride, and not wanting to hear that a poor implementation was implemented poorly.

They don't want to give out specific formulas and values because it would make the game infinitely easier and more predictable... People already do plenty of calculations on their own ahead of time... I can open a spreadsheet on my desktop right now and tell you all about my cure amounts, magic damage, damage taken, DA/TA rates, TP/hit supposing various haste and spell effects, etc supposing I were to go obtain or buy various pieces of equipment... It makes it very easy for people to prove/conclude what is the "best" setup for various situations... No one wants that to happen, it completely ruins the game. And yet it's only natural that people continuously experiment and try to derive these formulas on their own, thus there are tons of wiki pages and forums scattered around on collective input and data analysis trying to figure this stuff out... there's still a limit to the amount of data you can divulge through experimentation as a player, and they want to keep it that way... I want them to keep it that way too, because I hate elitists who insist on having the best of the best and the most optimal setup all the time...

People already use Windower to automate their battles... let's say the complete details of the enmity system were given here... What's stopping anyone from making a Windower plugin that would just completely automate a whole battle dual-boxed such that enmity would be perfectly balanced at all times? Suddenly the whole game is just watching a program exploit another program..? Yay... what fun... short of this everyone will just have their alliances exact enmity values constantly displayed beside their names like they already do TP and MP... no wait, don't cast that cure, wait a few seconds for his voke, his enmity isn't high enough yet... LAME.

[Economizer]

there's still a limit to the amount of data you can divulge through experimentation as a player

Yes and no, but for the purposes of your views, no.

We knew everything there was to know about enmity with the exception of specific job abilities or spells nobody bothered to test (the only reason this has changed - very temporarily - is because there was an update). We know everything about how nuking damage is calculated, and have specific numbers for the majority of nukes players can cast. We know just about everything about Cure spells and Curaga spells, even the obscure way they act as nukes.

We know enough that we often have to correct the Community Representatives or puzzle at why they're approaching something we've known for with extreme caution.

If there is something we don't know, it is because we haven't tried hard enough, or it is something that actually is hard to test (the overwhelming majority of which begins and ends with Treasure Hunter, and occasionally the way obscure mobs are spawned).

And if you think that revealing how the game works in detail would make FFXI less of a game, I counter that we knew exactly how much enmity was being dealt out and how it was decaying, we knew how much our cures would cure for, we knew how much the damage dealer would hit the mob for, we knew exactly how the mob's special abilities worked and when it would use them... but did this make us use bots? ...did this make us use one defined setup no matter what? ... did this make us not argue about which macro sets were the best for our job abilities (e.g. should I be going for recast reduction or enmity reduction on my cures)?

The answer to all of those is no, because your premise is wrong, knowing more about the game does not make it inferior, in part because that wasn't the case before, but also because if the game was bad while knowing everything about the mechanics it would be bad even if we didn't know the mechanics.

You can know everything about the rules of Chess, but that does not diminish the game. Players aren't even asking SE to tell them everything about every little mob in the game (the real puzzles), they're just asking for some straightforward answers to straightforward questions about basic game mechanics.

[RushLynx]

... but did this make us use bots?

Where were you in, idk, 2005... when it was impossible to claim an NM without the use of a specialized mule with altered game files and provoke to bot claim for your LS? You know, the issue that was so huge that they had to make a new system, still in place today, for spawns whereby you can't claim for a randomized amount of time after it spawns? When that didn't completely work they made lots of drops rare/ex and moved their previous trade-able versions to BCNMs, where they still exist today? What about when position and speed hacking was popular? And Fish-botting? The issue that was so huge they had to completely redo fishing so that it was more difficult to bot?

Players aren't even asking SE to tell them everything about every little mob in the game (the real puzzles), they're just asking for some straightforward answers to straightforward questions about basic game mechanics.

Part of my quote, which was the bolded quote from the OP, was excluded... but most of my post was regarding his objection to the OP's reluctance to provide specific values for things such as Provoke... Admit it, if we knew these things there would already be a windower plugin that displayed exact enmity values for everyone in the alliance... We automate our macros to adjust for things such as day and weather effects without having to do anything special, why wouldn't we automate it to delay spell casting until the necessary enmity values were present?

Your post seems to insinuate that SE is unaware that we've figured a lot of these things out... like they don't know about our wiki pages and forums... like they have no idea that we conduct this extensive research into finding these sorts of things out... They do know, and obviously they recognize that we are missing some pieces... In fact, in FFXIV's redesign they are encouraging this sort of discussion by designing the new Lodestone to support player-created wikis and discussions of this sort... in the most recent update they mentioned making a mobile app so people could access such content while playing on the PS3/4... They want us to talk about these sorts of things, but they don't want to hand us every little detail because that's when people start exploiting things...

[Economizer]

it was impossible to claim an NM without the use of a specialized mule with altered game files and provoke to bot claim for your LS?

That has nothing to do with understanding game mechanics at all.

but most of my post was regarding his objection to the OP's reluctance to provide specific values for things such as Provoke... Admit it, if we knew these things there would already be a windower plugin that displayed exact enmity values for everyone in the alliance...

I don't use third party tools since they're against the terms of service, but I keep myself aware of their functions. As such I'd like to give a bit of an explanation of how such third party tools function from a fairly academic standpoint to better serve this conversation.

Basically, the third party tool that you're referring to has a feature known as plug-ins (one I would hope SE emulates to some extent with the revamped UI they have planned). These plug-ins allow the player to add functionality to the base of the third party tools. These plug-ins are limited to the information the player's game client has access to and any information from non-SE sources (such as the databases that the websites FFXIAH and Guildwork use).

In this way there is a plug-in that shows TP of party and alliance members. Now, there are two ways this could theoretically be done. One could be to calculate how much Store TP and total delay each player has and count each hit they perform, however this is impossible for party members since you cannot know how much Store TP they have at any given moment, and parsing the chat log to determine hits is not always ideal. Keep in mind that self-calculating this number is impossible, this will come back in a minute. The second method that could theoretically be possible is if the client was sent information about party and alliance member's TP already but it isn't shown. This is the case and this is roughly how the plug-in in question performs its function.

Now, keeping in mind that self-calculating TP build of other party members is impossible due to Store TP not being something you could realistically check in real time, try to imagine Enmity as being perfectly solved - you still wouldn't know because you can't check how much enmity gear any particular player is wearing. From there we have to wonder about if the number is sent to the client, however I don't believe this is the case.

So even if we knew the formula down to each Provoke, we wouldn't be able to have a third party tool keep track of enmity unless the data was already being provided to the client. But let's go deeper, did we know how much enmity a Provoke gave before the sparse numbers they gave us?

We knew.

Note the date on that. We've known exact numbers with certainty for over five years. It has been incredibly public knowledge and we modeled the enmity model and knew everything about it short of new spells and job abilities we never bothered to test after the level cap increase, not that it would have been particularly hard to figure things out. Even now it is only a matter of someone actually doing the testing to figure out the new values.

And there is nothing SE can realistically do about it to stop us from figuring it out again.

Your post seems to insinuate that SE is unaware that we've figured a lot of these things out...

It does not. We wouldn't puzzle over why they restrict information to us that we already know if we thought they shouldn't know we know. It isn't like they can't read plain English.

but they don't want to hand us every little detail because that's when people start exploiting things...

If the game mechanics are exploitable in undesirable ways then whether or not we know about it explicitly is moot, players will eventually exploit it. Wouldn't it be better to have a system that isn't exploitable in an undesired manner regardless of if the players understand how to play the game or not?

[Genoxd]

The enmity value of provoke was figured out long ago...
Do the devs not realize that we actually have enmity values for many (if not most) of the spells/abilities in the game?