115 replies to this topic

[Roland]

IceSerpent, on 11 March 2014 - 07:32 AM, said:

I think it's not quite that bad - there are two kinds of equipment:

1. discreet (has PPC / doesn't have PPC). In this case set is {0,1}, so you can get BDA and Sigma from there, just like you do for the mech variants.

2. Continuous (speed, armor, etc.). In this case BDA and Sigma can be calculated as:





where definite integrals have range from min (speed, armor, etc.) to max (speed, armor, etc.)

p(x) is probability density, for normal distribution it is



Once you get BDA and Sigma for each piece of equipment, you can just plug those into the rest of your equations.

Well, if you think you can do this math and it'll work, I'd encourage you to set it up in a spreadsheet and see if you can put together a system that actually arrives at reasonable values. I'm quite skeptical as to whether you can just use the "takes one of these weapons vs. doesn't" as a frequency measure for the equipment.

I'm also not totally sure about how you are choosing to calculate the value associated with things like speed or armor etc. But I'm intrigued by it. I'd suggest you throw the data into a google spreadsheet and see if you can work out the details. That's how I put together the system for mech frequency.

Quote

I understand that, but this considerably limits the usefulness of the system - premades can always agree on "house rules" as a workaround, PUG queue doesn't have this luxury and has to rely on MM for doing the "balancing".

Well, here we're not talking about a 12 man queue and a PUG queue.. we're talking about a single unrestricted queue where teams are made of solo players as well as groups of various sizes. So you can't really just deal with "house rules" in that case.

In terms of MM, it would generally be something that lies on top of the BV restrictions.

Quote

That other guy is affecting the match outcome, and there's no control mechanism to affect that. I can't ask him to drop in a certain mech because he is not in the group, and MM can't ensure a proper match for him on the other team because MM has no idea that not all Victors are created equal, so to say.

But the matchmaker isn't doing matches based on BV. And some guy who is dropping separately from your group, who gets put on your team, isn't affecting your BV allocation at all.

[Cimarb]

Roland, on 11 March 2014 - 09:16 AM, said:

That's why the model doesn't really apply well to individual pieces of equipment, because the cost can't really be correlated simply to frequency.

However, with mechs, it works because each pilot is consistently making a single selection of which mech to drive for whatever he wants to do.

It can be correlated the same way. You have a percentage of tonnage that you are allocating to a particular item, be it engine size (speed), armor, heat sinks, weapons or addons (ECM, Artemis, etc). It is quite inaccurate still, but more accurate than your chassis version, which could be a meta-build or have nothing but an engine and 10 heat sinks equipped.

[Roland]

Cimarb, on 11 March 2014 - 11:13 AM, said:

It can be correlated the same way. You have a percentage of tonnage that you are allocating to a particular item, be it engine size (speed), armor, heat sinks, weapons or addons (ECM, Artemis, etc). It is quite inaccurate still, but more accurate than your chassis version, which could be a meta-build or have nothing but an engine and 10 heat sinks equipped.

Feel free to try and do the math if you think it's the same. That's all I can offer at this point.

Also, no one drops mechs with an engine and 10 heat sinks. It's not important to have the system account for cases which are not actually going to exist with any frequency.

[Cimarb]

Roland, on 11 March 2014 - 11:39 AM, said:

Feel free to try and do the math if you think it's the same. That's all I can offer at this point.

Also, no one drops mechs with an engine and 10 heat sinks. It's not important to have the system account for cases which are not actually going to exist with any frequency.

But it is possible and just an example regardless. Whether it is an engine and 10 heat sinks, the technical bare minimum to launch, or four small lasers, the point is that you can have a perfect "meta" build or an almost unusable build and your system values both of them exactly the same. A ballistic hardpoint with a MG is hardly the same value as one with an AC20.

[Roland]

Cimarb, on 11 March 2014 - 12:34 PM, said:

But it is possible and just an example regardless. Whether it is an engine and 10 heat sinks, the technical bare minimum to launch, or four small lasers, the point is that you can have a perfect "meta" build or an almost unusable build and your system values both of them exactly the same. A ballistic hardpoint with a MG is hardly the same value as one with an AC20.

But it doesn't matter.

The fact that you could potentially try to make a terrible build has no impact on anything, because it will not occur with enough frequency to impact anything at all.

There's no need to try and deal with edge cases which occur with a trivial frequency.

[Cimarb]

Roland, on 11 March 2014 - 12:52 PM, said:

But it doesn't matter.

The fact that you could potentially try to make a terrible build has no impact on anything, because it will not occur with enough frequency to impact anything at all.

There's no need to try and deal with edge cases which occur with a trivial frequency.

The example is an edge case to show what can be done, while the frequently poor builds you WILL run into DO matter when you are "balancing" teams.

[Roland]

Cimarb, on 11 March 2014 - 01:55 PM, said:

The example is an edge case to show what can be done, while the frequently poor builds you WILL run into DO matter when you are "balancing" teams.

But this isn't a matchmaking algorithm.

What this is, is similar to a tonnage limiting system... akin to the limiting system being put in place by PGI currently that uses mech classes.

Only this is superior to that, because it doesn't preclude the usage of the "bad' mechs in each mech class. It encourages people to use the full spectrum of mech variants that are available in game.

[TrentTheWanderer]

I think adding extra functions in order to accomplish something other than the goal highlighted in the original posts is a bit beside the point of the thread.

If people have a good plan for setting up an ad-hoc build evaluation and balancing system perhaps they should create it and provide some form of demonstration here for us?

[Koshnar]

Well I hope PGI isn't going to reneg on the 5-11 group idea, but if thats the case then I'm leaving the game... just can't stand playing this team game without a team any longer. I'm not good enough to play with the 12 man teams but still sick and tied of matching up with 8 players who are not of my standard, not on comms and not true mechwarriors. ( x COD players and the like who only care about their KD ratio )

My son asked me a few days back why online games always turn bad. My reply was this. " Son its a Developers job to make a very good game and then over a period of time stuff it up so you don't want to play it anymore."

[Roland]

Honestly, PGI hasn't even addressed the 75 page thread of folks complaining about their plans for a launch module... There was ONE post in there, on the first page, by Paul making a statement that didn't make any sense... And then silence. So I'm guessing they're just not gonna do anything about any of those things.

Oh well, putting together this system was kind of a fun exercise on its own, even if PGI has no intention of even looking at it.

[no one]

Hey Roland, don't feel bad man. There really were some good ideas in it. Even though I don't agree with you entirely here, people really turned out for your thread, and gave it a good discussion. It gave me ideas and inspired me to do a few suggestion threads. Even though I imagine they'll be fruitless efforts, and some of them went largely unnoticed, it was fun debating with people. If there was a "consistently posts good ideas and should be listened to by PGI" award we could nominate people for, you'd be a top candidate.

[Prezimonto]

Roland, on 05 March 2014 - 12:04 PM, said:

Really, you don't. The variant itself encapsulates its hardpoints, which effectively encapsulates the weapons it can bring.

Up to a point this is true, but what it will do is punish players looking to try less than optimum builds on even moderate variants.

Though because you can always drop solo with anything, I'm not so sure I care. It just implies that if you want to mess around with builds you do it on your own time.

The other issue I have is that it assumes parity between all mechs in terms BV_base, is the intent to leave that at parity, or should a locust's base value actually be represented as smaller than a Highlander or Atlas? The system contains the ability to shift the base value, though I'm not overly sure how well that will interact with frequency. A large chunk of your premise is that drop rate will balance all, but I'm not quite convinced it's enough to really balance teams. I suspect we'd quickly see waves of mechs month to month with the trend being, "find the heaviest mech with lowest BV this month".

[Roland]

I don't think you will really need to have different base values, as the locusts price will eventually automatically end up lower if it is a worse mech than a highlander.

In terms of using less optimal mechs, I would argue that you are running those configurations because you believe they actually may be optimal.

[WandiXXL]

Jake Hendricks, on 05 March 2014 - 11:25 AM, said:

Could be interesting to use but BV needs to account for several factors to balance:

• Mech & Equipment
  
• Pilot Skill in mech / class of mechs for example.
  
• A variable based on build / weapon groups. A single AC20 is decent but twin AC20's should be higher than 2 x AC20 value for example.
  
• A value based on being in a group / depending on group size.

For the determination of Pilot Skill you should use the following formular : (Mech Kills + Kill Assists)/Damage Dealt) before destruction

Why?

A lot of players these days simply wait until the match is almost over before striking, in fear of ruining the useless stats. So they have a high K/D- Ratio but that ain't skill. And a lot of players do a lot of damage and then someone "steals" the kill So they should add ALL Kills and Assists and divide it through the actuall damage dealt.

Edited by WandiXXL, 27 March 2014 - 10:06 PM.

[Prezimonto]

Roland, on 27 March 2014 - 03:14 PM, said:

I don't think you will really need to have different base values, as the locusts price will eventually automatically end up lower if it is a worse mech than a highlander.

In terms of using less optimal mechs, I would argue that you are running those configurations because you believe they actually may be optimal.

I don't know about you, but I try stuff a lot that I don't think it going to be better, mostly becuase I'm bored with the game and there's not much fun left to derive from it that play around with mech building. Oh yeah, except the new UI also killed much of my enjoyment of that as well over the last month.
...........................
I might suggest segregating a portion of the BV into a short run and long run Tw fractions. Some thing like if the base is 1000, only 200 is open for change on a patch to patch or month to month basis, and the other 800 is open to change every 6 months.

This sets your initial seed data as a baseline, and would help control artificial short run spikes due to balance changes or trial mechs or hero/new mechs being released.

Edited by Prezimonto, 28 March 2014 - 08:54 AM.

[Roland]

Consider though, that those times when you are just trying junk out is a small percentage of the overall market. It would eventually be lost in the noise.

[Prezimonto]

I don't disagree.

What do you think of the other idea in my last post about segregating some BV into a long an short Tw? That was meant as an aside not a complement to the junk builds comment.

[Roland]

It could be a useful addition, if we saw undue sudden shifts in price. I'm not sure it would be necessary, but it would certainly be possible to add in such buffering factors if necessary. I'd probably start without it, and keep it in my back pocket as a tweak if needed.

[Nik Van Rhijn]

I just wish that this would be considered, it makes much more sense than a "simple" 3 3 3 3.

[rattlehead]

I know this thread is a few weeks dead, but I wanted to chime in and say that I think this is a great idea!

Initially, I was thinking that the TT BV system could be used, and then tweaked to better represent the actual value in MWO since the two systems are inherently different. However, after having read through this entire thread, I am convinced that Roland is right and such a system would be a nightmare to keep adjusted.

If I were to attempt a TL:DR version of Roland's system, it would be something like this:
1. Balancing a match based on weight classes simply can't work.
2. Tabletop BV and similar systems will be broken and exploited by the hive-mind of the player base.
3. Roland's system doesn't fight the hive-mind. Instead, it puts the hive-mind to work and uses it to set floating BV costs that actually work.

As I came around to the idea, I was also one of those who thought that the idea lacked needed precision by not taking into account actual weapon and equipment loadouts. However, I am now convinced that just going with individual chassis variants is sufficient. If the customization system in MWO was as it is in the TT game, it might be different. But, what I'm gathering from this thread indicates that it is far more limited and just tracking variants is sufficient to reliably set BV. Granted, I haven't explored that part of the game yet, but it seems that way based on what I know so far.

Like actual real-world economics, no matter how much historical evidence and solid facts you throw at them, there will always be those who think tinkering with the levers is the only way to go. But, attempting to control such a system is impossible and will always result in ruin and failure.

Roland's system is elegant, self-correcting, and effective. So, how do we convince the devs that this needs to be a part of their system?