1911 replies to this topic

[Nova Latios Storm]

What are we talking about guys? -sitting there eagerly listing-

[Mawai]

Karl Berg, on 09 May 2014 - 03:11 PM, said:

I have some recent numbers, this is for a single day of telemetry:

Light: 16%
Medium: 21%
Heavy: 35%
Assault: 28%

Hi Karl,

Thank you very much for these statistics ... I sincerely hope you don't get into any trouble for your communications in this thread. Your answers are an amazing breath of fresh air in what has appeared to me to be an environment with generally poor communications.

I was wondering if you could get similar telemetry data for solo vs group and the distribution of groups?

Thanks,

Mawai

[Cimarb]

Mawai, on 13 May 2014 - 06:00 AM, said:

Now ... here are the expected queue times with 3/3/3/3 assuming this distribution is representative.

(Snipped - great numbers and analysis)

So .. I think that the 3/3/3/3 paradigm is broken as currently designed and will NOT work with a real distribution of players. Expecting players to switch mechs to get a match faster will just mean folks will quit rather than play a mech they don't like.

Fundamentally, I think the matchmaker MUST respond to the mech distribution in the input queues or the design is broken.

My suggested fix for this was the following:

Monitor queue times. Set a maximum acceptable queue time (I choose 2 minutes).

When all queue times are 2 minutes or less - generate 3/3/3/3 match distributions

IF a queue goes over 2 minutes then adjust the distribution to increase the number of mechs from queues over 1 minute proportional to the number of mechs queued ... so that the long queues reduce over time ... the rate limiting step is still the class of mech with the least number in the queue. This may mean generating 1/2/5/4 or some other distribution for a while to reduce queues - it has to be adaptable - BUT the matches will all be evenly matched with the same classes and ideally tonnage on each team. Folks don't really care about 3/3/3/3 - they do care about balanced matches.

When all queues are 1 minute or less go back to generating 3/3/3/3 until a queue hits 2 minutes - rinse and repeat.

This would mean:
1) All matches are balanced for weight but there will be some variety in matches.
2) At least some fraction of matches will be 3/3/3/3 ... the closer to equal the queues are the more 3/3/3/3 matches there will be
3) The maximum wait time is 2 minutes
4) The game will not force people to play mechs they do not want to play in order to get a match in less than an hour ... this is crucial for player retention ... if I have to wait even 10 minutes for a match that only lasts 10 minutes ... I won't be playing MWO at all ... and there are probably a lot of folks in this boat.

Feel free to pass this one along Karl if it is worthwhile.

I think this is great. Even though I would prefer individual balanced (match player for player using an adjusted BV+player skill), this is a great alternative. It gives an incentive for picking a weight class that has a shorter queue time, but adjusts to fix fluctuations in population and distribution.

Mawai, on 13 May 2014 - 06:30 AM, said:

Hi Karl,

Thank you very much for these statistics ... I sincerely hope you don't get into any trouble for your communications in this thread. Your answers are an amazing breath of fresh air in what has appeared to me to be an environment with generally poor communications.

I was wondering if you could get similar telemetry data for solo vs group and the distribution of groups?

Thanks,

Mawai

I have saw a very, very large increase in the number of groups in matches lately, even when I drop solo. It is not uncommon to see at least three 3-4 man premades in each match currently. I would love to see how the 84% has changed since those numbers were released... I bet it would be significant.

[Buso Senshi Zelazny]

Rounding the percentages that Karl gave us, this is what the *average* team looks like

Assault: 3 ~25%
Heavy: 4 ~33.3%
Medium: 3 ~25%
Light: 2 ~16.7%

Not too far from off from 3/3/3/3, but enough to cause problems. I've made the suggestion in the Patch Feedback section that 3/3/3/3 be adapted so that each category would be 3 +/- 1, so a max of 4 and a min of 2 for each weight class. For this distribution, 2-4 in each category would seem to work fairly well, at the very least better than a strict 3/3/3/3 in terms of wait time. The problem is that these numbers are the average from an entire day, and most likely vary a bit from hour to hour. Another option would be to eliminate the minimum requirement and just keep the max at 4

I have also suggested in Patch Feedback that the combination of 3/3/3/3 and 1 group per team was too much for the matchmaker to handle, and that they should try activating 3/3/3/3 ONLY without the 1 group per team rule and see how the matches and wait times play out. Though I have no hard numbers to back this up, I feel that the 1 group per team rule is a much tighter bottleneck on wait times than 3/3/3/3.

So now for my questions. Has there been any discussion/testing on possibly decoupling 3/3/3/3 from the 1 group per team rule to see which has the largest impact on wait times? Would design be willing to bend the 3/3/3/3 rule, keeping that as the ideal target, but allowing teams to have up to 4 from a single weight class? Or have you guys possibly sorted out the issues from the last two patches and will have the solution out shortly?

Thank you Karl for all of the feedback and insight that you've given us so far. This thread has rejuvenated my will to keep playing this game.

[Redshift2k5]

Keep it up Karl, every post you make gets my myomers hot and bothered.

[Mawai]

Buso Senshi Zelazny, on 13 May 2014 - 07:15 AM, said:

Rounding the percentages that Karl gave us, this is what the *average* team looks like

Assault: 3 ~25%
Heavy: 4 ~33.3%
Medium: 3 ~25%
Light: 2 ~16.7%

Not too far from off from 3/3/3/3, but enough to cause problems. I've made the suggestion in the Patch Feedback section that 3/3/3/3 be adapted so that each category would be 3 +/- 1, so a max of 4 and a min of 2 for each weight class. For this distribution, 2-4 in each category would seem to work fairly well, at the very least better than a strict 3/3/3/3 in terms of wait time. The problem is that these numbers are the average from an entire day, and most likely vary a bit from hour to hour. Another option would be to eliminate the minimum requirement and just keep the max at 4

I have also suggested in Patch Feedback that the combination of 3/3/3/3 and 1 group per team was too much for the matchmaker to handle, and that they should try activating 3/3/3/3 ONLY without the 1 group per team rule and see how the matches and wait times play out. Though I have no hard numbers to back this up, I feel that the 1 group per team rule is a much tighter bottleneck on wait times than 3/3/3/3.

So now for my questions. Has there been any discussion/testing on possibly decoupling 3/3/3/3 from the 1 group per team rule to see which has the largest impact on wait times? Would design be willing to bend the 3/3/3/3 rule, keeping that as the ideal target, but allowing teams to have up to 4 from a single weight class? Or have you guys possibly sorted out the issues from the last two patches and will have the solution out shortly?

Thank you Karl for all of the feedback and insight that you've given us so far. This thread has rejuvenated my will to keep playing this game.

Actually ... I was asking Karl for data on groups so we could come up with an estimate on group queue times - the math is pretty similar to what is described above for individuals. Basically the 1 group/side capped at 4 mechs has an absolute cap of 1/3 of players dropping in groups before queues start forming. However that assumes all 4 person groups which we know is not the case ... if they are all two person groups then the cap is at 16% of the players dropping in groups before queues start forming. So the actual number of players dropping in groups is capped between 16% and 33% of the player base (depending on group distribution before queues form) ... and group queues can get very long very fast. For example ... 50% of players dropping in groups gives immense queues very quickly.

So the matchmaker needs to be able to adapt to group queue sizes as well as mech class queues.

The only issue with capping the distribution at 2-4 mechs in each weight class is the edge cases where at some times of day you might get even more lopsided mech class distributions than the full day average cited in Karl's numbers. For example, if the light mechs drop to 8% at some time during the day just as a part of normal statistical variation then you won't believe how fast the queues will grow with 3/3/3/3 AND ... a 2-4 scheme will just not be sufficient to keep the queue lengths short.

I agree that once 3/3/3/3 stops working due to long queues then a 2/2/4/4 type distribution is preferable if it will shorten the relevant queues ... however, if that is NOT sufficient then the matchmaker has to be able to go to even greater extremes (e.g. 1/2/5/4 or 0/2/6/4 or more) since, in my opinion, the priority has to be queue management to optimize the player gaming experience combined with solid balanced team making ... for any mech distribution in the incoming queues.

To me the key is to "optimize the player gaming experience" since that will keep folks playing and spending money ... and that is accomplished with reasonable queue times and reasonably balanced matches.


.

Edited by Mawai, 13 May 2014 - 08:02 AM.

[TheCaptainJZ]

It seems to me, with the current MM, that whatever weight class you drop in, there is a greater chance of there being more of them in your match. If you drop in a light, you are more likely to see other lights in your matches, higher than the percentages above. If you drop in a heavy, though, you will see a lot fewer lights on the field. That has been my experience anyway and I don't have any hard data on it. Perhaps, if you had guarenteed slots on your team that were reserved for a specific weight class, say 2/2/2/2 with the remainder random so long as each team gets the same class distribution, it would acheive the same results. This would make it so players aren't forced to pick a weight class just to drop faster. I realize, we are trying to skew the mechs on the field more towards the lighter classes but that should be more natural not artificial. I.E. people would play mediums if there was a better reason to over a heavy mech.

[East Indy]

Mawai, on 13 May 2014 - 06:00 AM, said:

0.16 * nLaunch/3 matches are formed in one hour since the light mechs are the limiting factor
0.16 * nLaunch mechs in each class will get a match in the time frame - the rest are queued

Are you sure it's 0.16, and not 0.64 (0.16/0.25)? If by some coincidence players in an ELO tier queued in a perfect 25%-per distribution, all criteria would be met instantly, and teams would form as quickly as players became available, yet your formula suggests only a quarter would be seated.

There are some assumptions about class play reflecting current conditions. We don't know that:

1. Players dislike lights outright
2. Players will not play lights when guaranteed they will not significantly under-ton their team
3. Some players aren't in heavies and assaults because of average weight pressure
4. Players won't adjust to play faster, especially if given "traffic" reports

[Featherwood]

Hello Karl,
I won't ask my questions this time, since a lot of them have been asked during the weekend, I'll wait for another opportunity Let me sincerely thank you for your work done in this thread, it makes you a credit and gives us a chance to see another face of PGI - I think you are really helping your employer to overcome reputation damage done by Russ and Paul, though I still doubt if it's fixable. They own you more than a mug of ale

I have a question to moderators: why this topic is not pinned yet))? Topic's name change could be also useful, something like "Karl Berg delivers - competent PGI developers' show".

edit: typos

Edited by Featherwood, 13 May 2014 - 09:15 AM.

[dangerzone]

Egomane, on 12 May 2014 - 10:06 AM, said:

Please remember that Karl has a life.

Considering we just had a weekend since his last post, it's absolutly possible that he simply wanted to spend some time with his family, friends or hobbies, instead of answering questions about work. Don't you agree?

Woah woah take it easy there, friend D:

I was just making a simple joke. I'm sure that Karl is very busy and was not killed in a dark alley way or anything.....right? lol. I'm sure he is happy as can be coding away and living the life of a programmer

[Heffay]

dangerzone, on 13 May 2014 - 10:13 AM, said:

Woah woah take it easy there, friend D:

I was just making a simple joke. I'm sure that Karl is very busy and was not killed in a dark alley way or anything.....right? lol. I'm sure he is happy as can be coding away and living the life of a programmer

dangerzone, on 13 May 2014 - 10:13 AM, said:

Woah woah take it easy there, friend D:

I was just making a simple joke. I'm sure that Karl is very busy and was not killed in a dark alley way or anything.....right? lol. I'm sure he is happy as can be coding away and living the life of a programmer

When you love what you do, you'll never work another day in your life. And I get the feeling that Karl really loves what he does.

[Mawai]

East Indy, on 13 May 2014 - 09:08 AM, said:

Are you sure it's 0.16, and not 0.64 (0.16/0.25)? If by some coincidence players in an ELO tier queued in a perfect 25%-per distribution, all criteria would be met instantly, and teams would form as quickly as players became available, yet your formula suggests only a quarter would be seated.

There are some assumptions about class play reflecting current conditions. We don't know that:

1. Players dislike lights outright
2. Players will not play lights when guaranteed they will not significantly under-ton their team
3. Some players aren't in heavies and assaults because of average weight pressure
4. Players won't adjust to play faster, especially if given "traffic" reports

No. If every thing is perfectly balanced then there are 0.25 nLaunch of each class every hour.

0.25 nLaunch - 0.25 nLaunch (limiting class) = 0.0 = no queue.

The lowest number of mechs limits the number of the other classes than can launch if you insist on perfect balance.

If the numbers were 0.2, 0.25, 0.25 and 0.3 then the numbers are

0.2 -0.2 = 0 = no queue
0.25-0.2 = 0.05/0.2 = 15 minute queue
0.3-0.2 = 0.1/0.2 = 30 minute queue

The number of mechs launched is limited by the number in the smallest weight class.

The rate limiting mech class always has no queue.

-----------

As for whether the player base will adjust ... who knows. I have about 37 mech bays with multiple mechs in every weight class ... I have at least 5 mastered light mechs, 3 mediums, 7 heavies and 3 assaults ... but at the moment I enjoy playing my Jager JM6-S and Catapult Jester the most.

I am probably not the only one to feel this way. I do like my Jenners and I am working on Firestarters but if I feel like playing a heavy that is what I will play ... and if I have to queue for 20 minutes or an hour to do it ... I won't play.

So ... no ... I don't think the player base will in any way sufficiently adapt to 3/3/3/3 to significantly reduce the queue times. That is just my opinion ... but if PGI decides large queues are ok ... it will be a lifetime limiting move for the game.

Edited by Mawai, 13 May 2014 - 10:59 AM.

[Cimarb]

I have a feeling that this matchmaker discussion is exactly the reason he has not been as able to post as previously. I know during the latest podcast he kept getting distracted because they were actively working on it, so he likely just hasn't had the "idle time" he would like lately.

[Karl Berg]

Hey guys, sorry for the lapse. As a few of you have gathered, we're in a bit of a crunch to get 3's out ASAP, as well as keep up with the clan release schedule. I'll try and get through all the new posts today if I can.

DarkonFullPower, on 09 May 2014 - 05:19 PM, said:

Thanks for the reply before. I have an odd one here brought about from confusion. This is the post that started this:

http://mwomercs.com/...transfer-to-ct/

tl;dr: Someone from MWO support said that C.A.S.E. limits ammo explosions to 1 ton, and does nothing to keep the damage from spreading to the Center Torso. This is completely different from what the in game description says.

Is the above true or false? If it is true (or even if it's false, if you have the time), can you explain in a post how the game handles ammo explosions from the ground up. This way, if anyone else asks, we can just quote you and end any further confusion.

I'm not familiar with these behaviours off the top of my head. I'll ask gameplay/design if they can post specific rules regarding C.A.S.E.

[Karl Berg]

Tekadept, on 10 May 2014 - 06:19 AM, said:

I know its probably too hard, but I wonder what % of those % are just bringing meta

I don't have good telem in place for the specific loadout being brought into matches. In this case, it's not enough to simply reference a users mechid in the telemetry. Since that mech can be reconfigured or sold at any time we need to snapshot config information into the telem system instead.

We do know the mech variant, and any weapons that were fired by that variant in a match if we do some fancy data mining. That doesn't necessarily give me a way to say 'x% of these mechs are meta mechs'.

[Karl Berg]

9erRed, on 10 May 2014 - 02:24 PM, said:

Greetings all,

Question for Karl about network and our current engine:

Q: Without going into too much depth could you expand on some of the issues concerning objects in the MWO environment being destructible, and where PGI is in relation to having some level of this brought into the various maps.

I understand object destructibility is mixed within and through out numerous fields for the PGI team, but are there specific limitations with the engine that may be slowing down implementation?

Thanks,
9erRed

There are several complications here. From the engineering side, it depends heavily on the amount of interactivity that dynamic terrain is expected to bring to the game. If you could shoot out bridges that other players were standing on for instance, that results in very difficult to resolve latency issues with the game simulation. It also results in very high rewind costs, as the set of rewindable entities has now grown to include these destructible objects. If the destruction is purely visual, then the engineering concerns are much smaller.

On the level design side, interactive destructible environments mean that sight lines and movement paths can change. The map designers would have to be very conscious of those dynamic differences, and ensure that no combination of destroyed assets results in negative gameplay mechanics. Purely visual destruction also mitigates these risks.

For the artists, they would need to build all of the destructible assets to be put in-game. I've been told that this is a monumental amount of work..

[Buso Senshi Zelazny]

Mawai, on 13 May 2014 - 08:00 AM, said:

[snip]
Basically the 1 group/side capped at 4 mechs has an absolute cap of 1/3 of players dropping in groups before queues start forming. However that assumes all 4 person groups which we know is not the case ... if they are all two person groups then the cap is at 16% of the players dropping in groups before queues start forming. So the actual number of players dropping in groups is capped between 16% and 33% of the player base (depending on group distribution before queues form) ... and group queues can get very long very fast. For example ... 50% of players dropping in groups gives immense queues very quickly.

So the matchmaker needs to be able to adapt to group queue sizes as well as mech class queues.
[/snip]
.

This is a good point, as it shows just how limiting the 1 group rule is. This is why for now, I feel the devs should not implement this rule, and just put in 3/3/3/3 or a variation to see how that alone impacts wait times for everyone before trying to add any group balancing on top of that.

Mawai, on 13 May 2014 - 08:00 AM, said:

[snip]

The only issue with capping the distribution at 2-4 mechs in each weight class is the edge cases where at some times of day you might get even more lopsided mech class distributions than the full day average cited in Karl's numbers. For example, if the light mechs drop to 8% at some time during the day just as a part of normal statistical variation then you won't believe how fast the queues will grow with 3/3/3/3 AND ... a 2-4 scheme will just not be sufficient to keep the queue lengths short.

I agree that once 3/3/3/3 stops working due to long queues then a 2/2/4/4 type distribution is preferable if it will shorten the relevant queues ... however, if that is NOT sufficient then the matchmaker has to be able to go to even greater extremes (e.g. 1/2/5/4 or 0/2/6/4 or more) since, in my opinion, the priority has to be queue management to optimize the player gaming experience combined with solid balanced team making ... for any mech distribution in the incoming queues.

To me the key is to "optimize the player gaming experience" since that will keep folks playing and spending money ... and that is accomplished with reasonable queue times and reasonably balanced matches.

[/snip]
.

You're right, a lower limit is probably still too strict for the current player population/distribution, and it should definitely be flexible as to minimize wait times. I hope you understand that my suggestion is not for each match to have the same mech distribution, that instead one match could be 3/4/3/2 and another could be 4/2/2/4, or even 4/4/4/0 with no minimum requirement.

Having balanced matches while minimizing queue wait times is definitely the overall objective. I think that in order to keep the matches balanced, you are going to need some sort of cap on the maximum number of chassis in a given weight class. Figuring out whether that number is 3,4,5 or whatever while still keeping waiting times do acceptable levels is the million dollar question, and I hope that the devs are at least considering bending the rules on 3/3/3/3.

[Karl Berg]

evilC, on 11 May 2014 - 04:54 AM, said:

I recently saw a thread where players were asked for information that would help fixing of stick controls.
My response to this thread was that keyboard / mouse do not work properly yet, so why were they they bothering with the fluff? I mean, hell, I own a TIR and want head tracker support as much as the next man, but there are more fundamental issues to be solved first...

Hi evilC,

On the subject of TrackIR and armlock, it was a little over a month ago now, so I'm not 100% certain. I believe holding the arm-lock control resulted in head-tracking arm mounted weapons or something similar.

As for breaking of mouse wheel binding; I seem to recall someone here talking about that recently. I'll see if I can track down who it was and if they're still working on it. There have been a few other issues that have been brought to my attention regarding input handling, like chat bindings interrupting movement controls. It sounds like the whole system could benefit from a cleanup pass.

[Karl Berg]

Krinkov, on 11 May 2014 - 03:57 PM, said:

I'm playing the game with an AMD Fx8120 and I get a 20% to 30% performance boost by turning off cores 1,3,5 and 7. Another member of the clan achieved similar performance gains with his 8 core processor as well. He believes it is because the game is attempting to perform floating point calculations on the extra four cores which are not designed to do floating point ops. Could you shed some light on this? Is his theory correct?

Took a quick look at the processor specs, and indeed there is a shared FPU unit between any two specific cores on this processor. In this sense, it's somewhat similar to a hyperthreaded model; although it seems there are independent dispatch and integer units available to each physical core.

This is unfortunate for our game, because we do heavily utilize the SSE instruction set for all floating point work. I would need to carefully profile a Bulldozer based system to get a good sense for why performance is dropping so dramatically for you; but it's certainly possible there is some kind of penalty being paid for swapping between cores. Whether this is due to thread context switching, L1/L2 cache thrashing behaviour, CPU pipeline stalls, or some other mechanism is really difficult for me to predict.

Butane9000, on 11 May 2014 - 07:31 AM, said:

Karl,

I understand from reading this thread your not too involved in the actual design philosophy of system but their implementation. If possible can you pass this idea along to those who design the systems. This has been posted numerous times across the forums for fixing certain issues but they've never got a fully in depth response before.

Yup, I can pass this on to the relevant developers.

[Karl Berg]

Shlkt, on 12 May 2014 - 04:45 AM, said:

The discrepancy between lights and heavies highlights the importance of estimated wait times when 3/3/3/3 finally arrives. Right now we've got 119% more heavies in the queue than lights; if player preferences did not change for 3/3/3/3 then the wait time for heavy mech drops would be at least 119% of the average game length. That's what... 10 minutes? Too long by far. Players can and will balance the queue if wait data is presented to them; you'll still get longer wait times for the big guys, but if players can know beforehand that their Jager will wait an extra 4-5 minutes then they've at least mentally prepared themselves for the wait. Known wait times are less likely to induce rage. Finally, notice that most players had been assuming that medium mechs would be in higher demand. Without live wait data you'd have tons of guys waiting in the heavies and assaults, getting frustrated, and then trying to drop in mediums to speed things up! It wouldn't actually speed things up, though, because the light 'mechs would have been the bottleneck. Just another reason why live wait times are important - players can't balance the queue or their own expectations without the correct data. [EDIT: yes, wait times can differ by Elo; that certainly complicates the problem, but I still think the data is very important to keeping the players happy]

We have indeed had several suggestions for how to present queue behaviour to the players. Production and design definitely understand that this could potentially help wait times, and have this on their radar.