Kilsin said:
There are a ton of equations, stats, multiplications, calculations, variables from base stats, multiplying stats, buffs stats, gear/weapon stats etc that all factor into this, it is extremely hard to get it spot on, even with testing but I can promise you that we will try our very best to get it right the first time
I can tell you that it is an EXTREMELY easy task provided that one designs a test program.
I have experience with designing and testing catalytic cracking towers in industrial facilities. This depends on infinitely more parameters than an RPG and is much more difficult because the parameters are continuous (pressures, temperatures, densities etc) instead of discrete numbers like in an RPG.
Yet when the test program is written and executed, you can bet that the engineers get it right (e.g 99,9% of problems are detected) the first time.
We don't want sharp, hot steel flying all around us , do we ?
I could take up a challenge designing a test program of every single class and every single level and I can assure you that I would do it alone in less than 4 months. Not really large ressources or complex maths needed.
Just an example how this would look for a warrior level L if he was a catalytic cracking tower :) :
1) DAMAGE delivered measured by net DPS against a mob type M
- weapons statistics (see Warrior level L available weapon design specifications)
- principal damage statistics (Force + any that applies - see character statistics design specifications)
- weapon speed or damage enhancing spells (see speed and damage buff design specifications)
- auxiliary damage by buffs like damage shields (see auxiliary damage buff design specifications)
- mob's AC (see AC design specification by type and level)
- mob's statistics (DEX + AGI + ? - see mob's defensive statistics design specifications)
- mob's damage decreasing buffs like shields etc (see available damage decreasing buffs for mobs)
- mob's slowing buffs like stuns etc (see slowing buff spécifications for mobs)
This gives us 8 dimensions what is really very few especially that some are only on/off.
Now I construct an 8 dimensional matrix which gives the frame of the test design. Rince and repeat for every level and every class. As low levels are very easy to test, it simplifies farther.
2) DAMAGE received measured by net DPS received against a mob type M
Same method like above but inverted - now the mob plays the role of the warrior and the warrior the one of the mob (e.g his defensive stats matter here).
3) Average time necessary to kill the mob M or to die to it - this allows to calibrate the type M mob's HP
4) I don't guarantee 99,9% efficiency but surely 90% efficiency. And the 10 % that get through will be by definition small fine tuning problems that won't need the "nerfing" that was hated on this thread.
So doing it right is not difficult and it doesn't even take so much time once the test protocol is properly designed.
@Deadshade - exactly.
I turn business and process rules into code for a living. With a collection of data, which is nothing more than the trials you suggest, and even a cheapo database and someone who knows analytics, none of the interactions between the classes, the mobs, the environments, etc should be a surprise. And given enough randomly generated trials, you could easily give predictive results within a few sigma confidence interval.
And really, one small set of functions can run the entire set of trials, considering mobs, players and environments all share the same parameters that only differ in numeric values. I can easily see, across any number of scenarios, how classes will perform individually, in any possible group combination, vs any mob/group/zone/etc. I can then dial in the various numeric parameters and rules to achieve my game's preferred level of challenge.
With 14 classes and a full group size of 6, you have ~7.53 million possible group combos. While that sounds like a lot, it isn't to a computer, and you can conjure thousands of trials, and break the results down by group makeup (assigning each class a role and percentage of that role, like warrior = tank, crusader = 90% tank, etc) and you can test content, mobs, combos etc.
If I am making it sound easy, it's because it is. Sure, tedious and time consuming, but not difficult by any stretch. And it does not require a major staff, it requires (as Deadshade suggests and I concur) one person with access to the rules/parameters, any modern database product, and a couple months to write code and generate the analytics.
And the thing is, all of this can be happening from even before the first polygon is laid down, first line of quest dialogue is written, or even the name for the game is figured out. The graphic/world engine is totally independent of the gameplay interactions between player, mob and environmental parameters. If warrior AC = 100, and mob DPS = 50, and blah and blah, then I can write like 10 lines of code to test a few bazillion fights between that warrior and that mob, before I every see even the first sketch of what either the warrior or mob should like. I can know down to an absurd number of decimal places what to expect out of that fight between that warrior and that mob given their respective input parameters.
I am not suggesting that VRI is not already doing this, but I am reiterating why nerfs and hotfix balancings are a major peeve among most players. It should have already been figured out, so post-release nerfs and re-balancing should not be required beyond a tweak here and there. I am figuring that since P:RotF is not Brad's first rodeo, and because this isn't first game forum that has seen Aradune posting and people like Venjenz harping on this stuff, that we can safely assume these things are being given proper consideration.