Thread: Job Balancing 6.08 (still needs work)

Originally Posted by Gruntler

Or put differently 'By imposing a sample bias against the skill floor of a job, you exclude the skill differential as a part of balance consideration.'

As you should so long as you are balancing a kit, rather than attempting to force equity from varying forms of mistake.

The answer to, in any data analysis, for any reason, 'which percentile should I focus on' is never 'only one percentile' unless the question is, and only is, 'what is that percentile's value?'

I literally said as much. I have never advocated for caring only about a single percentile. The post at the start of this conversation asks that we consider what can be done to tighten gaps elsewhere. The difference is merely that I'm not willing to condemn diversity in job complexity or learning curves, which act to increase the zone of attraction available to players so that there's a higher chance of someone having something they enjoy at their present level (which is not limited to aesthetic, performance, or even playflow, alone) to achieve the same tightness for every span of player. It's (A) impossible, and (B) horribly constraining to job design.

I've used the 90th percentile only to point out at what degree of skill relative to others using one's job within the first couple weeks of progression where, given what I consider a good balance in design philosophy between job diversity and equity, I'd expect job performance to be tightest.

But that's the problem. "Optimized run." is an 'invalid metric.'

Optimized use is what determines what X is at best capable of. I have repeatedly now said that such is not the be all and end all of tuning.

You would choose that other information.

When, per the premise you're following her, the value of the utility in any other run is nil, then that leaves you with only two options: (A) to make that utility perfectly free, overtuning it for any party who knows how to put it to use, or (B) remove the utility, favoring equity over identity, available depth, etc.

I'd look at the Y who haven't yet defeated it, and I'd look to see if the comparison between X and Y is a number that is considered reasonable. That will tell me if a job is struggling or not, in a more direct way than FFLogs.

Why assume that the devs couldn't possibly have access to those numbers? I've already noted

You have people in the community who don't understand the concept of 'data validity' and so they come up with very long, elaborate justification why they can use the x percentile. This is easy. It's also lazy.

Then perhaps... give something yourself, beyond 'everything should be balanced everywhere from everyone' as if such had no destructive implications on job design philosophy?

Game balance isn't about raw potential, it's about difficulty, and raw potential's not a measure of access to potential in pre-mastery learning, which is where the game balance lives.

Which is exactly why I mentioned changes across percentiles...

I don't know why you're acting like I want to balance things only for perfectly theorycrafted, perfectly executed robotic performances. I don't. But until you have at least some rough line in the sand, you're as likely to overbuff all but the easiest few options, leaving jobs like Machinist crippled once its competitors move more than a few baby steps towards mastery. I am merely being mindful of both this and the impact that having diverse kits and thereby learning kits, something I do not want to give up, will have upon job equity at different points in players' learning of those jobs.