The yin and yang of sparring/training now

[Brokkr]

The repeated assertion/implication that being able to attain mastery by NOT engaging in poor play is somehow anti-RP is preposterous.

That isn't what I am saying.  Your personal perspective seems to be coloring what I actually am saying into an interpretation that self reinforces your own perspective.

Could the system be better?  Sure.  Have we figured out a way to do it that meets both our goals and your goals, and is within the technical constraints of C?  No.  Do the suggestions in this thread do that?  Not really.

[Synthesis]

It's awfully convenient that your counterargument relies on a) a staff goal that is nebulous or frankly unstated, and therefore irrefutable and b) knowledge of the codebase that players cannot have, and is therefore irrefutable.

To me, that sounds like the last refuge of an argument that really has no legs to stand on.

[Brokkr]

a)  Goals really.  They tend to shift a bit as they are really an agglomeration of individual staff viewpoints.
b)  I didn't say codebase, I said C.  Here you go:  https://www.learn-c.org/

[Namino]

...You understand that several of your players have experience in this regard? In fact, some of them hold advanced degrees in various fields of information technology and data science, which requires proficient and frequent coding? That many of them have professional careers that include (and even are primarily focused on) writing code? So just blithely linking to a learner course of C isn't going to throw anyone off?

There is NOTHING in C that prevents you from designing a progression system as has been described in this thread. The very codebase that Armageddon is already based off of, DIKUmud, allows for such a progression. The way DIKUmud operated in this regard inspired progression based MMOs such as EverQuest. Early MMOs such as Ultima Online were written  in C (with some C++), and they had progression systems that didn't rely on failure. The way the progression system is set up in Armageddon is NOT the result of some dependency or library in C and to suggest that some hard-coded aspect of the language is restricting your hands is untrue.

The way this works in Armageddon is the result of a design decision, not a language limitation. Someone, somewhere, decided that this would be a good idea and implemented it. And then 30 years of code got dumped on top of it and now it's so badly entrenched in the system that in order to fix it would be an enormous amount of effort and likely require ripping the guts out of the system. I can only assume this is the case because of how much smoke and mirrors get thrown up about this subject.

But this issue has arisen because of Armageddon's poorly scoped implementation of an engine coded in C.

It is not because of C.

[Delirium]

This entire argument is based off the assumption that it's impossible to get past a plateau in weapon skills.

That was never my experience in the past.

If it's due to the starting offense levels of specific new classes, couldn't we just lower that?

It'd make them less powerful out of the gate, but with more potential down the road.

[Brokkr]

Have we figured out a way to do it that meets both our goals and your goals, and is within the technical constraints of C?  No.

Hey, some ideas we've had aren't really doable in C.

b) knowledge of the codebase that players cannot have, and is therefore irrefutable.

Apparently knowledge of the codebase is necessary to refute the concept that some ideas aren't that workable in C?

b)  I didn't say codebase, I said C.  Here you go:  https://www.learn-c.org/

What I said wasn't anything to do with the codebase.  Here is your obligatory snarky reply.

...You understand that several of your players have experience in this regard?

Hey!  I apparently misunderstood this whole thing!  Cause you can do lots in C and we could do what we want in C so it isn't a problem about C.  Nevermind what Brokkr was actually talking about.

[Riev]

This entire argument is based off the assumption that it's impossible to get past a plateau in weapon skills.

That was never my experience in the past.

If it's due to the starting offense levels of specific new classes, couldn't we just lower that?

It'd make them less powerful out of the gate, but with more potential down the road.

Honestly though, one of the benefits is that you DO start out more competent, if you chose to be, which allows for quicker exploration or involvement in "kill all da spidahs!" plots.

I think the high start, with the rapid advancement in offense just leaves the weapon skills stunted without some odd behavior on the part of the player. You actually advance to this "grindy area" so quickly that it frustrates some people to be at 6days played and feel that they can't codedly advance along their main goal.

[Synthesis]

This entire argument is based off the assumption that it's impossible to get past a plateau in weapon skills.

That was never my experience in the past.

If it's due to the starting offense levels of specific new classes, couldn't we just lower that?

It'd make them less powerful out of the gate, but with more potential down the road.

Nobody said it was impossible.

We said it's impossible without resorting to some specific circumstances, the vast majority of which are poor play.  And you have never (that I can recall) provided specific examples of how your seemingly unique experience worked.  You always jump in and say "you're wrong, because it didn't work like that for me," without ever providing a single bit of explanation.

[Synthesis]

Have we figured out a way to do it that meets both our goals and your goals, and is within the technical constraints of C?  No.

Hey, some ideas we've had aren't really doable in C.

b) knowledge of the codebase that players cannot have, and is therefore irrefutable.

Apparently knowledge of the codebase is necessary to refute the concept that some ideas aren't that workable in C?

b)  I didn't say codebase, I said C.  Here you go:  https://www.learn-c.org/

What I said wasn't anything to do with the codebase.  Here is your obligatory snarky reply.

...You understand that several of your players have experience in this regard?

Hey!  I apparently misunderstood this whole thing!  Cause you can do lots in C and we could do what we want in C so it isn't a problem about C.  Nevermind what Brokkr was actually talking about.

Once again, you're entirely missing the point because of some bizarre fixation on semantics.  You realize that the English language is both denotative and connotative, right?  That you have to allow for a bit of fuzziness and overlap in meaning when attempting to interpret what other people are saying?  Because they're coming from a possibly different linguistic milieu where the intent of their words may not have the explicit meaning that you're most familiar with?

In other words: English is not a coding language, and trying to interpret and argue with it as such makes you seem obtuse.

[Namino]

Well, what in the Seven Hells are you actually talking about? Because half of that post was totally incomprehensible to me. What idea have you had that is impossible in C? Because you never produce ideas in these threads. You just show up, play missile command against all of the concepts and brainstorming the players are collaboratively discussing, and then traipse off again and wait for the next time the same topic gets brought up (3 days, +/- twelve hours) so you can shoot things down again.

But you don't ever reveal even one iota of any solution or alteration or twinkle-in-the-eye you might have to address the issue, let alone why you think C can't be manhandled to solve it. All of your posturing is always done from a position of "we're not interested in changing it" or "your ideas don't do what we want them to". Yet when you get pinned into a corner by Synthesis' valid arguments about making claims that are irrefutable due to lack of transparency, you start throwing smokescreen about coding languages and that I totally have ideas I promise but they won't work and no I won't tell you what they are or why they don't work just trust me.

[Brokkr]

I'd like to steer the conversation to something productive, but sort of hard when folks like to take the negative interpretation of what you say.  And then we end up at places like this.

So, technically (see Synthesis post on semantics) you can do most things in C.  Some things are just Ugh. In a perfect world, we could compare your entire combat history vs the combat histories of all other folks to determine a relative soft cap for you.  Weight overall world values to make it sticky, but not impossible, to gain beyond a midpoint, weighted in stickiness by number of folks beyond that midpoint (or alternatively, an number of points past which gains become stickier and stickier).  Meanwhile taking into account all of your other combat values that determine combat in the particular scenario you are in, to weight towards stickiness the more effective you are in combat based on all the other factors that relate back to your skillsheet.  Make it so that when you look at your skillsheet it is dynamic to point in time you type skills such that it searches through all PCs, alive and dead, to determine the word to put on your skillsheet in comparison to all those other PCs (so like, if you are within top 10% of pc's in a skill, you see "master", bottom 20% then "novice") for each skill, rather than based on which range in the total possible range you are in.

[Gracchus]

The failure system is fine, feels a bit like I'm playing Morrowind or the Burning Wheel, it's enjoyable. What doesn't feel good is that to attain even basic competence (and god forbid I get good) in weapons skills I have to subject myself to a grind so slow and tedious it's like I'm working an irl job, only to have those gains eliminated in the blink of an eye because it's a permadeath game. Which means now I have to do it again. It's frankly disrespectful of my time.

Even very simple bootstraps solutions recommended in this thread, like making parries count for skilling up. could alleviate this. I don't want an overhaul I just want to be able to get good without dedicating real life days to it.

[Namino]

Good. This is productive.

My understanding is that you're working on the backend right now to move the data management of the game into an SQL server, is that correct? Are values associated with active characters planned to be stored in this database? If so, I think the easiest way to produce something such as what you've described, Brokkr, is to manually set coefficients for combat skills. No, it's not empirical, but for the sake of efficiency, empiricism may have to go and it's a definite improvement.

So you look at the combat skills overall and determine subjectively what they're relative impacts are. For example, a skill like parry is very important, so it likely should have a 1.3 weight coefficient, while a skill like kick is very situational (unmounted combat, high str, ect) and may have a value of .7. The calculation would look like:



Where each skill is weighted by a coefficient that we think represents how much that skill plays a part and averaged, and then added to a separate function where the total number of combat skills a character has is multiplied by another coefficient, so that someone with 2 out of 2 combat skills at master isn't more proficient than someone with 10 / 12 combat skills at master. Then each character has a value for how overall proficient they are. C can handle all of this math without trouble.

I don't know how the SQL database is going to interface with the game, though. If it's possible, I would simply have a column for proficiency of active characters with more than 5 days played (more on this later), then have a rolling average of that column set the point of proficiency after which combat skills begin to slow down, preferably something like (((mean proficiency/maximum proficiency) * 1.2) * maximum proficiency). This can get over 100% of course but it requires a mean proficiency of like 85 at which point it seems fair that the whole playerbase can just progress to 100 without a massive slog.

Having your skills show up as relative can also be handled by the SQL database if possible, but it will require an entry for each combat skill which might become difficult, then simply divide the character's skill by the mean skill level and set your breakpoints from there (ie, >.5 < 1 = jman). Again, without knowledge of how the SQL database is planned and what values are going to be stored there, it's somewhat hard to sketch that part out. But to implement what you're describing, I think the SQL database will have to get involved.

[Delirium]

It seems more straightforward to let parries, blocks, and armor-blocked blows be considered failures.

I don't know how simple that would be to code, but as a solution to sparring woes, it seems to have merit.

[Brytta Léofa]

Consider decreasing the chance of skillgain as skill level increases (while providing more opportunities for skillgain, as parry, block, etc.).

[Namino]

Yes, that would solve the situation in a simpler way but I think the concern there is that it turns into a skill catapult, and it could be argued that skills thereby become too easy to increase indefinitely as being parried is very common, so I think it's valuable to see if there isn't a way to solve things more elegantly, even if the process is a bit painful.

[Brytta Léofa]

On the codebase front, {C++, extern "C", -fno_exceptions} is a pretty damn gigantic gain in expressive power at no cost.  (no_exceptions is weird but perfectly viable.)

(As an aside to whatever this discussion is. )

[Brokkr]

A different sort of tack than what I was talking about.  First, it is essentially static.  I think you'd end up with a bunch of really, really skilled folks under that system assuming folks lived long. Whereas I am talking about a system where folks end up pretty much where they are now in terms of combat effectiveness.  For this example, lets say that is middle of the scale, at 50 in a 0 to 100 scale.  It then decreases likelihood that you can increase past that point, but it isn't tied only to your static scores, but your entire history of combat vs the entire history of combat (at that point) of all people who have ever surpassed the point you are at.  Based on that, maybe someone at 65 is a master, but two years later, maybe someone at 60 is at master.

[Brokkr]

It seems more straightforward to let parries, blocks, and armor-blocked blows be considered failures.

I don't know how simple that would be to code, but as a solution to sparring woes, it seems to have merit.

I am not sure we are defining the problem the same.  The problem isn't how to allow people to progress and essentially turn it into a function of time spent.  Or rather, that may be the problem from your perspective, it isn't from ours.

The problem is how to get most folks over time to competence, but only have a very few of those that take on more challenges to move significantly beyond that.

[Krath]

It seems more straightforward to let parries, blocks, and armor-blocked blows be considered failures.

I don't know how simple that would be to code, but as a solution to sparring woes, it seems to have merit.

I hate agreeing with Delirium..Seriously and here I go endorsing this idea. +100 to this.

[Synthesis]

Yeah, the fancy relative-to-other-PCs-dynamic-weighting-skillgain-percentage business seems way, way too complicated.

Part of the system "working" is that players can a) understand it and b) be able to make ballpark predictions about how it's going to impact their character.  Frustration occurs because either a) you look at the grind, and the mountain is so tall that you question whether it's even worth it to begin or b) when you (reasonably) expect a certain result that doesn't materialize or c) the method of the grind is fundamentally at odds with the theme of the game.  If advancement is predicated on factors that you, the player, cannot reasonably predict (e.g. the skill levels of other players, the number of other skilled active players), it's going to be just as frustrating as the current system.

Beyond that, the problem with "relative-to-other-PCs" gating is that you introduce a Highlander or crab-barrel mentality.

Overall, I think the best method is to a) make parries and blocks count as failures and b) gate the final steps to mastery behind longevity.

Then there are multiple ways to implement a longevity gate:
1) Single hard gate:  If master is skill level 80, you can get to 79 as fast as you can possibly do it, but you will never get that skill bump to 80 until you pass the longevity gate.  Worst-case scenario, you start at 79 at chargen, and never get a skillbump until you hit 20 days (or whatever the gate is).  Worst-case scenario, you mudsex for 19 days and suddenly become a master at 20 days 1 hour when you suddenly begin training.

2) Skillgain timer gate:  Your skillgain timer for each weapon/style skill is set at chargen, based on your starting skill and the skill level at which mastery occurs.  If you start at jman (e.g. 40) slashing because of a skill boost, and mastery occurs at 80, that's a difference of 40 skill points.  If the skillgain gate is set to 20 days played, the fastest you can get to mastery is 40 points in 20 days, so your skill timer for slashing is set for 12 hours of logged-in time.  You can get a skillgain to slashing weapons every 12 hours played, so it will be -at least- 20 days before you progress to master slashing.

3) Multiple-step longevity gating:  There are four "steps" on the way to master (apprentice, journeyman, advanced, master).  Each of these steps is longevity-gated.  It's not necessary for them to be proportional, but for simplicity of explanation, they'll be proportional for this discussion.  20 days divided by 4 steps is 5 days apiece.  You can't achieve apprentice before 5 days.  You can't achieve jman before 10 days.  You can't achieve advanced before 15 days.  You can't achieve master before 20 days.  If you start at jman out of chargen, it will still be 15 days before you can hit advanced.

4) RL-time gating:  replace each of the above scenarios with real-life time as the metric instead of logged-in time.  This prevents padding the login clock by idling.

I think the longevity gate will work better for clan sparring, because once you hit the gate, you know that it's pointless to grind for yourself at a certain point.  (I'd argue that the best "location" for the gate is right -after- the word-based-metric.  E.g. you technically can hit advanced before 15 days, but it will be locked in at minimum advanced.  This way, you know you hit the wall, and that it's pointless to grind until you hit 15 days.) Back to the point:  if you know grinding for yourself is not going to be effective, you now have two options open 1) help your clannies grind, by being a good sparring buddy (much easier to do if you aren't worried about your own gains); or 2) go out and get into some shit instead of worrying about losing time not sparring.

It seems more straightforward to let parries, blocks, and armor-blocked blows be considered failures.

I don't know how simple that would be to code, but as a solution to sparring woes, it seems to have merit.

I am not sure we are defining the problem the same.  The problem isn't how to allow people to progress and essentially turn it into a function of time spent.  Or rather, that may be the problem from your perspective, it isn't from ours.

The problem is how to get most folks over time to competence, but only have a very few of those that take on more challenges to move significantly beyond that.

Defining "challenge" in a meaningful way is going to be an impossible task, I'm telling you that right now.  Longevity gating isn't perfect, but in general it gets it right, because most PCs just don't live that long.  There is the downside that it somewhat rewards being risk-averse, but the current system frankly rewards being a complete dipshit.  I have to go out and fight things that I really could give two shits about, and invent fig-leaf excuses as to why I'm doing it...and I'm doing that instead of being involved with other players, on the promise that once I reach the skill level I want, I'll be able to get involved.  I mean...I feel like that's way worse than being a master swordsman in the AoD who's really only ever sparred.  It's too easy to get lost in the cons of a proposed system and lose sight of how much the current system really sucks.

[Namino]

A different sort of tack than what I was talking about.  First, it is essentially static.  I think you'd end up with a bunch of really, really skilled folks under that system assuming folks lived long. Whereas I am talking about a system where folks end up pretty much where they are now in terms of combat effectiveness.  For this example, lets say that is middle of the scale, at 50 in a 0 to 100 scale.  It then decreases likelihood that you can increase past that point, but it isn't tied only to your static scores, but your entire history of combat vs the entire history of combat (at that point) of all people who have ever surpassed the point you are at.  Based on that, maybe someone at 65 is a master, but two years later, maybe someone at 60 is at master.

Can you quantify what you mean by 'history of combat'? What values or actions would contribute to that? Every time a person swings a weapon? Every killing blow they land? A variable could increment with either (both, or additive to many other things) and then the SQL database approach would work if you just show the top 10% of the column as master. Essentially you can build a distribution of the SQL values in the column from all player characters alive or dead and base people's current skill rankings off where they sit in the distribution before returning the value to the character. The distribution will naturally shift up and down as characters become more 'experienced in combat' (right shift) and new characters are spawned into the world (left shift) but I think the first step is to determine what factors of a character's existence or history you feel should contribute to their 'history of combat'. In my example the proficiency score is simply a function of weighted combat skills but it could be used to build this distribution. Based on your reply it feels like you think there's more to one's 'history of combat' than just skill. The formula could simply be altered to include as many factors as you like, ranging from number of killing blows to amount of HP damage received throughout one's lifecourse. It'd simply be a new variable * weight coefficient in the formula.

[mansa]

Part of the system "working" is that players can a) understand it and b) be able to make ballpark predictions about how it's going to impact their character.  Frustration occurs because either a) you look at the grind, and the mountain is so tall that you question whether it's even worth it to begin or b) when you (reasonably) expect a certain result that doesn't materialize or c) the method of the grind is fundamentally at odds with the theme of the game.  If advancement is predicated on factors that you, the player, cannot reasonably predict (e.g. the skill levels of other players, the number of other skilled active players), it's going to be just as frustrating as the current system.
...
Overall, I think the best method is to a) make parries and blocks count as failures and b) gate the final steps to mastery behind longevity.

Then there are multiple ways to implement a longevity gate:
1) Single hard gate:  If master is skill level 80, you can get to 79 as fast as you can possibly do it, but you will never get that skill bump to 80 until you pass the longevity gate.  Worst-case scenario, you start at 79 at chargen, and never get a skillbump until you hit 20 days (or whatever the gate is).  Worst-case scenario, you mudsex for 19 days and suddenly become a master at 20 days 1 hour when you suddenly begin training.

2) Skillgain timer gate:  Your skillgain timer for each weapon/style skill is set at chargen, based on your starting skill and the skill level at which mastery occurs.  If you start at jman (e.g. 40) slashing because of a skill boost, and mastery occurs at 80, that's a difference of 40 skill points.  If the skillgain gate is set to 20 days played, the fastest you can get to mastery is 40 points in 20 days, so your skill timer for slashing is set for 12 hours of logged-in time.  You can get a skillgain to slashing weapons every 12 hours played, so it will be -at least- 20 days before you progress to master slashing.

3) Multiple-step longevity gating:  There are four "steps" on the way to master (apprentice, journeyman, advanced, master).  Each of these steps is longevity-gated.  It's not necessary for them to be proportional, but for simplicity of explanation, they'll be proportional for this discussion.  20 days divided by 4 steps is 5 days apiece.  You can't achieve apprentice before 5 days.  You can't achieve jman before 10 days.  You can't achieve advanced before 15 days.  You can't achieve master before 20 days.  If you start at jman out of chargen, it will still be 15 days before you can hit advanced.

4) RL-time gating:  replace each of the above scenarios with real-life time as the metric instead of logged-in time.  This prevents padding the login clock by idling.

I think the longevity gate will work better for clan sparring, because once you hit the gate, you know that it's pointless to grind for yourself at a certain point.  (I'd argue that the best "location" for the gate is right -after- the word-based-metric.  E.g. you technically can hit advanced before 15 days, but it will be locked in at minimum advanced.  This way, you know you hit the wall, and that it's pointless to grind until you hit 15 days.) Back to the point:  if you know grinding for yourself is not going to be effective, you now have two options open 1) help your clannies grind, by being a good sparring buddy (much easier to do if you aren't worried about your own gains); or 2) go out and get into some shit instead of worrying about losing time not sparring.

...

Defining "challenge" in a meaningful way is going to be an impossible task, I'm telling you that right now.  Longevity gating isn't perfect, but in general it gets it right, because most PCs just don't live that long.  There is the downside that it somewhat rewards being risk-averse, but the current system frankly rewards being a complete dipshit.  I have to go out and fight things that I really could give two shits about, and invent fig-leaf excuses as to why I'm doing it...and I'm doing that instead of being involved with other players, on the promise that once I reach the skill level I want, I'll be able to get involved.  I mean...I feel like that's way worse than being a master swordsman in the AoD who's really only ever sparred.  It's too easy to get lost in the cons of a proposed system and lose sight of how much the current system really sucks.

I like the time gate advancement as long as
a) the gates are public knowledge   
b) a combination of time played and real life time advancement.


If it was public knowledge what is expected of the combat players (eg journeyman is expected after 300 hours OR 3 months, advanced at 1000 hours OR 10 months, mastery at 2000 hours OR 20 months) then players have a goal to reach, and have reasonable expectations of their play time.

That could work in conjunction with increasing the "things to do in combat that can increase your weapon skills"

[Synthesis]

A different sort of tack than what I was talking about.  First, it is essentially static.  I think you'd end up with a bunch of really, really skilled folks under that system assuming folks lived long. Whereas I am talking about a system where folks end up pretty much where they are now in terms of combat effectiveness.  For this example, lets say that is middle of the scale, at 50 in a 0 to 100 scale.  It then decreases likelihood that you can increase past that point, but it isn't tied only to your static scores, but your entire history of combat vs the entire history of combat (at that point) of all people who have ever surpassed the point you are at.  Based on that, maybe someone at 65 is a master, but two years later, maybe someone at 60 is at master.

Can you quantify what you mean by 'history of combat'? What values or actions would contribute to that? Every time a person swings a weapon? Every killing blow they land? A variable could increment with either (both, or additive to many other things) and then the SQL database approach would work if you just show the top 10% of the column as master. Essentially you can build a distribution of the SQL values in the column from all player characters alive or dead and base people's current skill rankings off where they sit in the distribution before returning the value to the character. The distribution will naturally shift up and down as characters become more 'experienced in combat' (right shift) and new characters are spawned into the world (left shift) but I think the first step is to determine what factors of a character's existence or history you feel should contribute to their 'history of combat'. In my example the proficiency score is simply a function of weighted combat skills but it could be used to build this distribution. Based on your reply it feels like you think there's more to one's 'history of combat' than just skill. The formula could simply be altered to include as many factors as you like, ranging from number of killing blows to amount of HP damage received throughout one's lifecourse. It'd simply be a new variable * weight coefficient in the formula.

Making it relative on any "scores" from a "lifetime of the MUD" database will introduce an infinity grind:  every player to reach the magic top 10% makes the grind that much more difficult for players coming behind them.

Making it relative on scores from a "current PC" database introduces a Highlander/crab-barrel mechanic.

I think these are worse than the "too many skilled PCs" problem that you're attempting to prevent.

[Namino]

A different sort of tack than what I was talking about.  First, it is essentially static.  I think you'd end up with a bunch of really, really skilled folks under that system assuming folks lived long. Whereas I am talking about a system where folks end up pretty much where they are now in terms of combat effectiveness.  For this example, lets say that is middle of the scale, at 50 in a 0 to 100 scale.  It then decreases likelihood that you can increase past that point, but it isn't tied only to your static scores, but your entire history of combat vs the entire history of combat (at that point) of all people who have ever surpassed the point you are at.  Based on that, maybe someone at 65 is a master, but two years later, maybe someone at 60 is at master.

Can you quantify what you mean by 'history of combat'? What values or actions would contribute to that? Every time a person swings a weapon? Every killing blow they land? A variable could increment with either (both, or additive to many other things) and then the SQL database approach would work if you just show the top 10% of the column as master. Essentially you can build a distribution of the SQL values in the column from all player characters alive or dead and base people's current skill rankings off where they sit in the distribution before returning the value to the character. The distribution will naturally shift up and down as characters become more 'experienced in combat' (right shift) and new characters are spawned into the world (left shift) but I think the first step is to determine what factors of a character's existence or history you feel should contribute to their 'history of combat'. In my example the proficiency score is simply a function of weighted combat skills but it could be used to build this distribution. Based on your reply it feels like you think there's more to one's 'history of combat' than just skill. The formula could simply be altered to include as many factors as you like, ranging from number of killing blows to amount of HP damage received throughout one's lifecourse. It'd simply be a new variable * weight coefficient in the formula.

Making it relative on any "scores" from a "lifetime of the MUD" database will introduce an infinity grind:  every player to reach the magic top 10% makes the grind that much more difficult for players coming behind them.

Not necessarily. For example, for every person who hits master, there are two characters created who either never train, or die before they hit apprentice. The left shifting overpowers the right shifting in that example. Your fear is only realized if we limit the people contributing to distribution to those who achieve mastery. If we draw the distribution from ALL players, then master reaches a stable state equilibrium between newly created characters pulling the distribution back and highly skilled, longevity characters pulling it up.

It's not necessarily the way I personally would handle bracketing skillgain, but I'm working inside the bounds of the stated idea of the current administration.