1911 replies to this topic

[Jman5]

Are you guys looking to allow players to customize their lances in the pre-launch menu for 12-man groups? Currently there are a lot of problems where you might have a single assault spawn in the farthest lance with 3 lights. Not only is he the slowest person to the front, but his light lance zooms ahead of him leaving him isolated.

Ideally I would like to see players able to pick and choose. Barring, that maybe you could weight spawn locations based on chassis. (assaults are the closest, lights spawn the farthest).

[Brian Buckton]

Wintersdark, on 13 April 2014 - 12:30 PM, said:

Mr. Buckton, thanks for joining in! It's always fun seeing you in my insomnia-fueled late night MWO sessions

If I may ask: To be clear, does this mean we'll be free to send chat messages to random players in drops, and they'll receive them post drop? In both group chat and direct messages?

Also: Would you consider adding some more visible or perhaps audible alert when you get a new chat message/invite?

Its very easy to miss that little blinking (with moderately low contrast) indicator, particularly at high resolutions. A little notification "ding" when new messages are received while your social window is closed would be immensely helpful.

Heya Wintersdark, I've seen you in my drops before.

You won't be able to send messages to random people who are not on your friends list. What I mean exactly about the chat fixes: Imagine you're talking to your good buddy Player B from your friends list, and his group drops into a match. You can keep sending him messages and when Player B returns, they will be able to read what you said. The same goes users in your drop. Scenario 2: Players A, B & and C are grouped, and Player A invites you. You take your time to accept the invite, and in the meantime they drop into a game. After accepting the invite, you can send messages to the group chat, and when they return from the game, they will be able to read your messages in the group chat.

I'm always thinking about ways to improve the social interface and user experience and I would consider adding extra alert indicators, it's something that's been bugging me as well

[SilentWolff]

Not to sound like a broken record, but the ELO mess and social issues would all be a non issue with a true lobby system. I know the launch module is coming, but from the limited info I've seen so far, it doesnt look like it will address any of the above issues, or the previous issues I mentioned.

[Roadbeer]

Brian Buckton, on 13 April 2014 - 12:24 PM, said:

There's some big social fixes coming in the next patch. here are a couple issues that have been addressed:
- Chat history not being retrieved properly after returning from a drop, which directly fixes chat messages received while you're currently in a drop.
- Group launch button throwing up an error when everyone is ready. We now ensure the server gets the message first before switching your state on screen; however, In the next patch you may see a small delay of about ~1 second when clicking ready. I do have another fix to speed up that 1s delay, but it did not meet the patch deadline, so that will have to be deferred till the 29th patch.

This thread just keeps piling on the Awesome!

Thanks Brian for the update,

I think the ~1 second delay is more than acceptable when it takes several seconds to close the error, re-select the mode then launch again. A minuscule delay, less clicking, FULL OF WIN! And the fact that there is a follow-up to speed that up is just icing on the cake. One of the things I've noticed about it is, when I'm group lead is that if I don't give a good 5 count after selecting ready and before attempting to launch is when I get it most often.

Also great news about the chat fixes. It has been a long running problem (since way before UI 2) and that it can finally be addressed and functional... I'm so happy

Since you're here, is there anyway that we could get an override for whatever main screen you were visiting when the social tab is in front, and you're waiting to launch (can't think of a better way to phrase that, so let me give you an example)

Say you were looking at achievements, you open the social tab and you're unable to select ready because you WERE looking at achievements. Now you have to close the social tab, go back to the main screen, re-open the social tab and ready for launch.
In UI 1.5, as long as you weren't in a "transaction" (I use the term transaction as, you weren't actively in Mechlab or unlocking pilot skills) you could be launched regardless of what screen you were on.

I see the value in it to prevent a Customer Service issue, I'm just not sure if that's intended or not.

Anyway, thanks again for your reply Brian. I'm loving all this communication.

[Wintersdark]

Brian Buckton, on 13 April 2014 - 12:52 PM, said:

Heya Wintersdark, I've seen you in my drops before.

You won't be able to send messages to random people who are not on your friends list. What I mean exactly about the chat fixes: Imagine you're talking to your good buddy Player B from your friends list, and his group drops into a match. You can keep sending him messages and when Player B returns, they will be able to read what you said. The same goes users in your drop. Scenario 2: Players A, B & and C are grouped, and Player A invites you. You take your time to accept the invite, and in the meantime they drop into a game. After accepting the invite, you can send messages to the group chat, and when they return from the game, they will be able to read your messages in the group chat.

This is exactly what I was hoping for, awesome!

Quote

I'm always thinking about ways to improve the social interface and user experience and I would consider adding extra alert indicators, it's something that's been bugging me as well

It'd be wonderful. I know I miss that little blinking indicator a lot, then often wonder how long it's been there for later. A little ding would go a long way to preventing that. Something more visual would be great too, but I don't have any easy ideas there.

[Project Dark Fox]

Wintersdark, on 13 April 2014 - 01:35 PM, said:

It'd be wonderful. I know I miss that little blinking indicator a lot, then often wonder how long it's been there for later. A little ding would go a long way to preventing that. Something more visual would be great too, but I don't have any easy ideas there.

Have an orange message above or beside the social button flash up when you get a new message saying "You have [x] new message(s)." Have it pulsing between yellow and orange, but not in too obnoxious of a way.

Edited by Project Dark Fox, 13 April 2014 - 01:40 PM.

[Rasc4l]

Brian Buckton, on 13 April 2014 - 12:52 PM, said:

I'm always thinking about ways to improve the social interface and user experience and I would consider adding extra alert indicators, it's something that's been bugging me as well

Hello Brian and thanks for the answers.

While you're tweaking the social interphase and if it's not too much trouble, maybe you can add a little chat-bubble with the blinking when the blinking is due to someoneone chatting and different icons for friend request and people joining groups?

Also, when you add the sound effect for social effects, which is great, please have the option to turn that sound off (even event specifically; wouldn't want the beep on chat but would highly appreciate the beep on friend requests and group activity).

[aniviron]

Wintersdark, on 13 April 2014 - 12:30 PM, said:

Also: Would you consider adding some more visible or perhaps audible alert when you get a new chat message/invite?

Its very easy to miss that little blinking (with moderately low contrast) indicator, particularly at high resolutions. A little notification "ding" when new messages are received while your social window is closed would be immensely helpful.

This in particular! I would guess that upwards of 80% of the time, I don't see group invites or chat messages until it's too late; I tend to drop solo, but have enough friends who still play that every now and then I get someone who wants to group up. It seems crazy to me that mousing over an engine makes a noise to alert you of what just happened, but getting a chat message does not!

p.s. Buckton! I haven't dropped with you in forever. Still running that Spider?

[Cimarb]

Egomane, on 13 April 2014 - 09:05 AM, said:

It's not that easy. There are literally thousends of ideas floating around on the forum (most in feature suggestion where they belong), and every day we get dozens more. Every idea has to be filtered, if it is being forwarded. Those that are forwarded, will again be filtered in various categories. Those categories will be brought up in meetings and again be filtered. If an idea gets an approval in such a meeting, it will get a detailed report, containing points like effort needed to create, compatibility, usability and many more. Each point has the ability to shoot the idea down once more. And even if the idea gets past all this, it can still be canceled during production, because it comes into conflict with another component (maybe from another idea).*

*At least that's the way it is in the development studios I know and have inside contacts to.

So until the developers get to the point of "we can't do that because of {this}", a lot of time has already past. Also, responding to every idea with a detailed explanation on why it can't be implemented, can take a lot of time away from development.

I definitely appreciate they explanation. It is still hard to put the effort into a detailed solution and have it disappear into dead space, but at least I know that dead space is being watched.

Responding to ideas and proposals, like Karl did today, makes a huge difference and can help the community many ways. Most importantly, if an idea is given a reasoning why it CAN'T be done, it will eliminate further discussion and tons of duplicate threads because of that.

Karl Berg, on 13 April 2014 - 09:20 AM, said:

I'm not an expert on the weapons systems, but I think this might be a bit troublesome. Alex is also hugely supportive of this model for AC's, as it's actually much closer to lore.

Here's the gotchas: The highly rapid-fire weapons, like machine guns, act as trace-fire weapons similar to lasers. The AC's all simulate with somewhat more physical accuracy, they spawn an actual projectile which has velocity, simulates over time, is affected by gravity, etc..

So while we could shoot off a pile of rapid-fire projectiles, that would have knock-ons that would require additional investigation at the very least. Increases in network traffic, increases in processing time and collision detection costs. Or, we might consider turning AC's into trace-fire at the cost of simulation fidelity. The shells would then fire with effective infinite velocity, no longer have gravity falloff, etc.. That's not necessarily a tradeoff we would like to make.

Oh my goodness, this made my month! If I hadn't already bought the Clan pack I'd be one of those guys saying, "I'm going to go buy it now!" Thank you for answering it, as this will help focus all of the numerous threads we are debating the issue in lately.

For clarification, where would the line in the sand be? I most definitely don't want autocannons to be trace/hitscan (is there actually a difference?), but if the AC2 can fire with a 0.52 cooldown, can we not have the rest of the autocannons at least have cool downs as far down as that? Or is it more of a load issue where the system just couldn't handle it if everyone was using a full load of AC2s on every mech?

For instance, the latest nerf to AC2s will bring their DPS at least closer in line with the other classes of ACs (I think they should have left the longer range but brought the DPS down to about 2.5, personally). Now that they are almost normalized, can you not make the AC2 stay as is, the AC5 fire at the same rate but do 3 damage per shell, the AC10 same rate but 4 damage per shell, and the AC20 same rate but 5 damage per shell?

Then, those baseline numbers could also be used to make other variations, where you may have larger damage per shell, but slower rates (double the above damage but half rate). This could be done innumerable ways (as the post in my signature) details. Btw, did you see StJobe's post about the (easy) XML changes that would allow ACs to be burst-fire (instead of continuous like they are now)? If not, I'll search for the link again and post it.

Modo44, on 13 April 2014 - 09:42 AM, said:

Hitscan ACs would be a sad system. MWO's distinctly not point-and-click gameplay is very appealing. Here's hoping you can find a way to model burst fire within the server/network constrains.

I agree, not wanting hitscan/trace.

[Ilithi Dragon]

Oh Sweet Baby Raptor Jesus, this is the best thread I have read in a very, very long time. Thank you very much, Karl, for your input and responses, they are very much appreciated. Here's my two cents (adjusted for inflation):


First, a question and suggestion on how all missile damage is applied.

As I understand it, the way all missiles apply damage is that the missile applies its full damage value to whatever component it hits, and then applies up to 40% additional damage to any component within its designated blast radius. As I understand it, this was the cause of the LRMageddon last year, when the blast radius for all missiles was significantly increased, causing massive overlap with that 40% additional damage sphere. Is this correct?

My suggestion, as an ideal way to implement all missile damage, would be to remove any direct damage effect from hitting a component, and make the weapon purely splash-damage. Damage would be applied to any component within the area of effect, based on the percentage of exposed surface area to the explosion. For example, a missile directly hits a very broad target, say the CT of an Atlas. 50% of all of the damage of that missile is directed away from the Atlas, doing no direct damage (but possibly damaging nearby mechs if the blast radius is sufficient), and of the remaining 50%, say, 20% of the damage is absorbed by the CT, 10% by each ST, and some small percentage by the Head, with the remainder absorbed by the arms or lost to empty space.

I do not know how viable this would be to implement, and it would certainly have its own balancing challenges, but in my opinion it is the best way to implement missile damage. It would also allow for large missile blast radii, giving some actual justification for the LRM minimum arming distance, and add an extra element of fun for SRMs, since getting TOO close (i.e. "leg-humping", etc.) and using them could cause self-damage.


Second, a suggestion regarding projectile weapon physics.

Currently, as implemented, MWO does not add a mech's velocity to its weapons' velocity. This means that, no matter how fast I am moving or what direction I am moving in, if I fire a PPC, an AC/10, a Large Laser, and an AC/5 at the same time, they will all hit in exactly the same spot, just with slightly different travel times.

This is VERY significant, more significant than a lot of people I talk to about it really understand. This is a core underlying reason behind almost every weapon synergy problem that PGI has had, and it is a significant contributing factor to why poptarts and all snipers are still a powerful meta.

The way things work in the real world, and the way things have worked in past Mechwarrior titles, is quite different. IRL and in previous Mech games, if you are moving and you fire anything other than a beam of light, your velocity is added to your projectile. This means that if I am running 70kph perpendicular to my target, and I fire a Large Laser, a PPC, an AC/5, and an AC/10, even at a stationary target, none of my weapons are going to hit the same spot, because they are all going to be traveling 70kph to the right of my target, and because they all have different travel times, they will all spend different amounts of time moving to the right of my target at 70kph, or about 19.5 m/s. If my target is, say, 700 meters away, my Large Laser will hit exactly where I am aiming. My PPC, traveling at 1500 m/s, will hit about 9.1 meters to the right of where I am aiming. My AC/5, traveling at 1300 m/s, will hit about 10.5 meters to the right of my target, and my AC/10, traveling at 950 m/s, will hit about 14.4 meters to the right of my target.

This will make ALL long-range builds more difficult to play, because the player will have to account for their own movement as well as their target's movement, and it will force players running sniper builds to choose between staying mobile, and making themselves a harder target, at the cost of accuracy, or stopping, and making themselves an easier target, to have an easier shot themselves.

This further breaks up synergy between various weapon types, meaning that PPCs and AC/10s or AC/5s, or PPCs and Gauss will be much more difficult to use paired together as long-range weapons, because they will lose their synergy.

This will cause snipers to transition to builds that are able to mount multiple weapons of the same type, to maximize weapon synergy, but this already has its limitations - ACs are heavy and come at great cost for mounting many together, and PPCs are high-heat weapons. There are also very few chassis that can effectively mount multiple long-range weapons of the same type. This will cause those chassis to become extra-popular, but I have another suggestion to help mitigate that.

Lastly, and I say this as a PPC-loving poptart *****, this will most significantly effect poptart snipers, because not only will poptarts now have to account for their own LATERAL movement, like all other direct-fire ranged builds, they will now also have to account for their own VERTICAL movement, which adds a level of difficulty and skill necessary to perform well to poptarting that MWO has, to this point, been severely lacking. Players will be able to adapt and compensate for this, but it will take great skill to do very well.

Poptarting will always be a great tactic, because it maximizes the use of the greatest armor of all - not getting hit in the first place, and combines it with the best way to shoot the enemy - before they can shoot you back. However, simply adding a mech's velocity to its weapons velocity will go a very long way to making the poptarting strategy one that is highly effective when performed well, but also one that requires very significant skill to do so.


My third suggestion aims to further that objective, to make poptarting something that is powerful when done effectively but difficult to do effectively, and also to prevent mechs like the Jager and Cataphract and Stalker from becoming the mech-of-choice for snipers for their ability to mount multiple weapons of the same type, a problem that is already prevalent.

One of the other significant problems with ranged builds, a problem that I am far from the first person to point out, is weapon convergence. When you take a Cataphract-4X or a Jagermech with four AC/5s, or a Victor with a mix of PPCs and AC/10s, and fire at a target, all of the weapons converge on exactly the same point. This is the true balance problem with high-alpha builds in general, and high-alpha sniper builds in particular - that pin-point damage. Ghost Heat is a band-aid that treats a symptom, without addressing the underlying problem. The real problem was not putting 6 PPCs on a Stalker (well, okay, 6 PPCs on a Stalker was a bit ridiculous, but that particular problem was entirely specific to PPCs being buffed to compensate for latency issues long before HSR, and never having been debuffed after HSR was introduced), the real problem was the fact that all of those PPCs were hitting in exactly the same spot. All weapons converge to exactly the same point, automatically adjusting for range.

The solution is to remove this. Not all weapons should converge. Make weapons mounted in a mech's torso fixed, so that they cannot converge at all - they fire straight ahead, and will always hit off of the crosshair's center. Arm weapons may converge, BUT, not all arms are created equal. Some mechs have arms that allow full convergence, like the Cataphract or the Atlas, but other mechs, like the Jagermech or the Stalker, don't have arms that move side-to-side. Those mechs should either have no arm convergence at all, or have only very limited arm convergence (and this could be balanced by mech variant in the same way that torso and arm twist angles and speeds are used). This alone will kill most of the pinpoint-alpha meta, because most mechs just simply will not be able to have a pinpoint, high-damage alpha strike, and it will also help to reduce the effectiveness of various "cheese" builds, because they won't be able to pinpoint their damage.

In combination with adding mech velocity to weapon velocity, this will cause a major balance shift in favor of Light and Medium mechs, because Lights will become much more viable builds, as they will be very hard for many of the classic 'cheese' builds to hit - many of the big mechs will have significant problems hitting the small little mechs effectively, because of their new lack of weapon convergence, and the snipers and poptarts will also have a harder time of hitting the fast mechs (their true bane), because of having to account for their own movement as well as their target's. As Lights become more prevalent and popular, so, too, will fast harasser Medium mechs and Light-killer builds, something I have not seen a large prevalence of since Closed Beta. The whole battlefield will become more diverse.

And that's my two cents (adjusted for inflation).



Also, I have it on good authority that Karl shits rainbow poptart kittens.

[Chronojam]

Karl Berg, on 13 April 2014 - 10:20 AM, said:

Good thoughts. I'm not sure I 100% understand your approach, so apologies if I've misinterpreted something (and correct me please if I have misunderstood!).

It definitely better reflects the biases that can impact player skill than our simple per-weight class system we currently have. However, here are some issues that would need to be considered with pair-wise tracking of Elo:

This is N^2 in memory cost on number of players. We currently have around 1.6 million player accounts or so. Not all are active, but an enormous percentage are or were active at some point, have played games, and have stats and ELO values associated with their account.

A non-sparse matrix of Elo's would then cost around 2.5 trillion entries worst case. Would this is be a symmetric matrix of Elos? Would player A's Elo when playing with player B be the same as player B playing with player A? If so storage costs could be cut in half.

For the 3 player group case now, we have many Elo's being tracked: A-B, B-C, C-A, and potentially the inverse cases B-A, C-B, and A-C.

For the 4 player group case we have A-B, A-C, A-D, B-C, B-D, and C-D, and potentially the inverse cases.

I think this works out to N choose 2 for the general case, so 1/2(N)(N-1); and so a 12 player group (worse case) costs 66 or 132 additional stat writes. That could definitely cause us issues with additional write-pressure at end of game.

Furthermore I'm not certain this is a true general solution, consider a case where players A and B perform *very* well when teamed with C due to C's leadership abilities; but terribly with D. So the pairwise Elo between A and B would heavily depend on the presence of C or D in their group.

To fully generalize using specific Elo tracking I think might require a separate Elo for every single group playing the game. Instead of a 2-D matrix of pairwise Elo's this takes it to an N-dimensional matrix. Definitely outside the realm of feasibility in terms of storage and data tracking costs.

There's another problem with highly fractured Elo's. We see it a bit with the 4 Elo categories we already have in fact, as players switch weight classes and find wildly different match qualities as a result. The more categories of Elo's we store and track, the more Elo's in our system are not seeded or updated correctly for that player. Here is one example with pairwise tracking. A played with B a few times back in closed beta, and B decides to take a long break. A continues playing and becomes very skilled indeed. If B returns and A and B decide to play again, A's archived pairwise Elo with B has him categorized as a new player!

For these reasons I would really love to explore the options we have with tracking just a few Elo's only. Say a solo and grouped Elo only, and examine other emergent properties of teamplay to infer other sources of bias, and this is where I would really want to pull in a data-mining / statistics expert to assist with. Are there correlations with group size? Are there correlations with Mech tonnage? Are there correlations with kill/death ratios? Are there correlations with # of games played? Do these correlations correlate between themselves, so combinations of group size combined with play count? We certainly have the terabytes of data required to curve fit or otherwise experiment with. I realize we won't be able to take this all the way to perfect, but I'm not sure that's a reasonable goal to set out with in the first place. The cool thing is this is one of the places where we can actually run controlled experimentation. We would, on launch of an updated system, be able to say with confidence, 'this new system is X% better at predicting group player skill'.

All that, plus Elo doesn't know how to account for the fact that you're boating LRMs and my whole team has ECM! And we're on Forest Colony, and probably going to try capping you out.

Elo's just not a great fit for dynamic circumstances where the playing field and pieces aren't fixed in capability and rules. Although you've got me thinking about a sort of weighted social web to determine pseudo-groups, to then generate a score for a team given a particular map start position for a given pool of players within a reasonable "play distance" of each other instead of hard and fast player1-player2-player3-player4 relational rankings. Still hard to make a team loadout archetype (LRM boat, brawler, sniper, anklebiters, ECM?) computed effectively enough to not still run into bad guesswork.

"This rough group of players as brawlers starting high city has a rating of 1234 against fast ecm. This rough group as fast ecm, starting at low city, has a rating of 456 against brawlers." This could be fun to work on, but it would be serious research, and it won't look anything like Elo's methods taken as a whole.

[Catamount]

Ilithi Dragon, on 13 April 2014 - 07:18 PM, said:

Spoiler

Oh Sweet Baby Raptor Jesus, this is the best thread I have read in a very, very long time. Thank you very much, Karl, for your input and responses, they are very much appreciated. Here's my two cents (adjusted for inflation):


First, a question and suggestion on how all missile damage is applied.

As I understand it, the way all missiles apply damage is that the missile applies its full damage value to whatever component it hits, and then applies up to 40% additional damage to any component within its designated blast radius. As I understand it, this was the cause of the LRMageddon last year, when the blast radius for all missiles was significantly increased, causing massive overlap with that 40% additional damage sphere. Is this correct?

My suggestion, as an ideal way to implement all missile damage, would be to remove any direct damage effect from hitting a component, and make the weapon purely splash-damage. Damage would be applied to any component within the area of effect, based on the percentage of exposed surface area to the explosion. For example, a missile directly hits a very broad target, say the CT of an Atlas. 50% of all of the damage of that missile is directed away from the Atlas, doing no direct damage (but possibly damaging nearby mechs if the blast radius is sufficient), and of the remaining 50%, say, 20% of the damage is absorbed by the CT, 10% by each ST, and some small percentage by the Head, with the remainder absorbed by the arms or lost to empty space.

I do not know how viable this would be to implement, and it would certainly have its own balancing challenges, but in my opinion it is the best way to implement missile damage. It would also allow for large missile blast radii, giving some actual justification for the LRM minimum arming distance, and add an extra element of fun for SRMs, since getting TOO close (i.e. "leg-humping", etc.) and using them could cause self-damage.


Second, a suggestion regarding projectile weapon physics.

Currently, as implemented, MWO does not add a mech's velocity to its weapons' velocity. This means that, no matter how fast I am moving or what direction I am moving in, if I fire a PPC, an AC/10, a Large Laser, and an AC/5 at the same time, they will all hit in exactly the same spot, just with slightly different travel times.

This is VERY significant, more significant than a lot of people I talk to about it really understand. This is a core underlying reason behind almost every weapon synergy problem that PGI has had, and it is a significant contributing factor to why poptarts and all snipers are still a powerful meta.

The way things work in the real world, and the way things have worked in past Mechwarrior titles, is quite different. IRL and in previous Mech games, if you are moving and you fire anything other than a beam of light, your velocity is added to your projectile. This means that if I am running 70kph perpendicular to my target, and I fire a Large Laser, a PPC, an AC/5, and an AC/10, even at a stationary target, none of my weapons are going to hit the same spot, because they are all going to be traveling 70kph to the right of my target, and because they all have different travel times, they will all spend different amounts of time moving to the right of my target at 70kph, or about 19.5 m/s. If my target is, say, 700 meters away, my Large Laser will hit exactly where I am aiming. My PPC, traveling at 1500 m/s, will hit about 9.1 meters to the right of where I am aiming. My AC/5, traveling at 1300 m/s, will hit about 10.5 meters to the right of my target, and my AC/10, traveling at 950 m/s, will hit about 14.4 meters to the right of my target.

This will make ALL long-range builds more difficult to play, because the player will have to account for their own movement as well as their target's movement, and it will force players running sniper builds to choose between staying mobile, and making themselves a harder target, at the cost of accuracy, or stopping, and making themselves an easier target, to have an easier shot themselves.

This further breaks up synergy between various weapon types, meaning that PPCs and AC/10s or AC/5s, or PPCs and Gauss will be much more difficult to use paired together as long-range weapons, because they will lose their synergy.

This will cause snipers to transition to builds that are able to mount multiple weapons of the same type, to maximize weapon synergy, but this already has its limitations - ACs are heavy and come at great cost for mounting many together, and PPCs are high-heat weapons. There are also very few chassis that can effectively mount multiple long-range weapons of the same type. This will cause those chassis to become extra-popular, but I have another suggestion to help mitigate that.

Lastly, and I say this as a PPC-loving poptart *****, this will most significantly effect poptart snipers, because not only will poptarts now have to account for their own LATERAL movement, like all other direct-fire ranged builds, they will now also have to account for their own VERTICAL movement, which adds a level of difficulty and skill necessary to perform well to poptarting that MWO has, to this point, been severely lacking. Players will be able to adapt and compensate for this, but it will take great skill to do very well.

Poptarting will always be a great tactic, because it maximizes the use of the greatest armor of all - not getting hit in the first place, and combines it with the best way to shoot the enemy - before they can shoot you back. However, simply adding a mech's velocity to its weapons velocity will go a very long way to making the poptarting strategy one that is highly effective when performed well, but also one that requires very significant skill to do so.


My third suggestion aims to further that objective, to make poptarting something that is powerful when done effectively but difficult to do effectively, and also to prevent mechs like the Jager and Cataphract and Stalker from becoming the mech-of-choice for snipers for their ability to mount multiple weapons of the same type, a problem that is already prevalent.

One of the other significant problems with ranged builds, a problem that I am far from the first person to point out, is weapon convergence. When you take a Cataphract-4X or a Jagermech with four AC/5s, or a Victor with a mix of PPCs and AC/10s, and fire at a target, all of the weapons converge on exactly the same point. This is the true balance problem with high-alpha builds in general, and high-alpha sniper builds in particular - that pin-point damage. Ghost Heat is a band-aid that treats a symptom, without addressing the underlying problem. The real problem was not putting 6 PPCs on a Stalker (well, okay, 6 PPCs on a Stalker was a bit ridiculous, but that particular problem was entirely specific to PPCs being buffed to compensate for latency issues long before HSR, and never having been debuffed after HSR was introduced), the real problem was the fact that all of those PPCs were hitting in exactly the same spot. All weapons converge to exactly the same point, automatically adjusting for range.

The solution is to remove this. Not all weapons should converge. Make weapons mounted in a mech's torso fixed, so that they cannot converge at all - they fire straight ahead, and will always hit off of the crosshair's center. Arm weapons may converge, BUT, not all arms are created equal. Some mechs have arms that allow full convergence, like the Cataphract or the Atlas, but other mechs, like the Jagermech or the Stalker, don't have arms that move side-to-side. Those mechs should either have no arm convergence at all, or have only very limited arm convergence (and this could be balanced by mech variant in the same way that torso and arm twist angles and speeds are used). This alone will kill most of the pinpoint-alpha meta, because most mechs just simply will not be able to have a pinpoint, high-damage alpha strike, and it will also help to reduce the effectiveness of various "cheese" builds, because they won't be able to pinpoint their damage.

In combination with adding mech velocity to weapon velocity, this will cause a major balance shift in favor of Light and Medium mechs, because Lights will become much more viable builds, as they will be very hard for many of the classic 'cheese' builds to hit - many of the big mechs will have significant problems hitting the small little mechs effectively, because of their new lack of weapon convergence, and the snipers and poptarts will also have a harder time of hitting the fast mechs (their true bane), because of having to account for their own movement as well as their target's. As Lights become more prevalent and popular, so, too, will fast harasser Medium mechs and Light-killer builds, something I have not seen a large prevalence of since Closed Beta. The whole battlefield will become more diverse.

And that's my two cents (adjusted for inflation).



Also, I have it on good authority that Karl shits rainbow poptart kittens.

I agree completely with the above two suggestions on sniper/alpha meta (no comment on the LRMs), with a caveat: pinpoint weapon convergence and lack of mech inertia for weapons is the one thing that keeps lights from being utterly broken.

ERLL lights are already borderline broken. Properly played 2xERLL Ravens are practically dominating the damage charts right now it seems, and that's pinpoint high damage. I think the thing that would have to be done to make the above suggestions fair is to rescale lights, which frankly I think should already have been done. The firestarter is about where lights should sit, volume-wise, were Ili's suggestions to be implemented. Right now I think it's actually a little underpowered due to its large size. 35 ton mechs just should not have less than half the volume of mediums, and right now they really appear to. It's a subjective judgement, but one that I think regards something so apparent, that that's sufficient here. The spider is even more ridiculous: is has like half the volume of the other lights it seems. That's why it's been hard to hit since day one, hitbox issues aside.

The current sniper meta is definitely an issue, I think, and merely buffing brawling weapons will not fix it. I say this as a happy sniper. However, killing overpowered sniping for other mechs will make long-range laser lights effectively be able to hit anything with utter impunity. Even in brawls they'd gain effective impunity. So were the above suggestions to be considered, it should be done in context of a game where broken small mechs are currently balanced against broken weapon mechanics on bigger mechs, and any changes to the two should be considered together.

Edit: got the spider's tonnage wrong; that's what I get for never running it

Edited by Catamount, 13 April 2014 - 07:48 PM.

[DevilCrayon]

http://mwomercs.com/...more-prominent/

So, yeah. This is great. I'm really loving the conversation and information going on down here and think it would be excellent if it were more visible to the rest of the forums.

[Modo44]

Chronojam, on 13 April 2014 - 07:20 PM, said:

Elo's just not a great fit for dynamic circumstances where the playing field and pieces aren't fixed in capability and rules.

Elo is like democracy -- it is not great, but really the best we have. Unlike elaborate "I had a great idea" systems that people keep proposing, Elo actually takes into account all factors. Looking at your example, playing solo in an LRM boat will include the randomness of enemy ECM in the resulting Elo.

Trying to hard-code those effects in the matchmaker is a fallacy, because it assumes that there is a simple model to follow. However, the game is in constant flux, so you will never actually know all the possible modifiers nor their weights. In addition, you would need a very elaborate tracking system, probably outside of available processing power. This brings us back to why a simple modifier for groups will likely not work, and an advanced one is not feasible (and may still not really work).

Elo skips those issues by looking purely at results, essentially auto-weighing all factors. I firmly believe it would be better with more values tracked (for solo/group play, and for chassis, as suggested earlier). While I see how having too many values would make them converge slower, they would still converge, and you would not have the issue of Elo values possibly representing a wide skill range. I see two simple solutions: 1. Slowly decay values over time. That way players returning to the game will have an easing period. 2. Seed the value for a new chassis with existing numbers for previously owned chassis of similar weight. That will not be 100% correct, obviously, but it reuses some of the earlier data to allow quicker convergence.

[MischiefSC]

Karl Berg, on 13 April 2014 - 10:20 AM, said:

Good thoughts. I'm not sure I 100% understand your approach, so apologies if I've misinterpreted something (and correct me please if I have misunderstood!).

It definitely better reflects the biases that can impact player skill than our simple per-weight class system we currently have. However, here are some issues that would need to be considered with pair-wise tracking of Elo:

This is N^2 in memory cost on number of players. We currently have around 1.6 million player accounts or so. Not all are active, but an enormous percentage are or were active at some point, have played games, and have stats and ELO values associated with their account.

A non-sparse matrix of Elo's would then cost around 2.5 trillion entries worst case. Would this is be a symmetric matrix of Elos? Would player A's Elo when playing with player B be the same as player B playing with player A? If so storage costs could be cut in half.

For the 3 player group case now, we have many Elo's being tracked: A-B, B-C, C-A, and potentially the inverse cases B-A, C-B, and A-C.

For the 4 player group case we have A-B, A-C, A-D, B-C, B-D, and C-D, and potentially the inverse cases.

I think this works out to N choose 2 for the general case, so 1/2(N)(N-1); and so a 12 player group (worse case) costs 66 or 132 additional stat writes. That could definitely cause us issues with additional write-pressure at end of game.

Furthermore I'm not certain this is a true general solution, consider a case where players A and B perform *very* well when teamed with C due to C's leadership abilities; but terribly with D. So the pairwise Elo between A and B would heavily depend on the presence of C or D in their group.

To fully generalize using specific Elo tracking I think might require a separate Elo for every single group playing the game. Instead of a 2-D matrix of pairwise Elo's this takes it to an N-dimensional matrix. Definitely outside the realm of feasibility in terms of storage and data tracking costs.

There's another problem with highly fractured Elo's. We see it a bit with the 4 Elo categories we already have in fact, as players switch weight classes and find wildly different match qualities as a result. The more categories of Elo's we store and track, the more Elo's in our system are not seeded or updated correctly for that player. Here is one example with pairwise tracking. A played with B a few times back in closed beta, and B decides to take a long break. A continues playing and becomes very skilled indeed. If B returns and A and B decide to play again, A's archived pairwise Elo with B has him categorized as a new player!

For these reasons I would really love to explore the options we have with tracking just a few Elo's only. Say a solo and grouped Elo only, and examine other emergent properties of teamplay to infer other sources of bias, and this is where I would really want to pull in a data-mining / statistics expert to assist with. Are there correlations with group size? Are there correlations with Mech tonnage? Are there correlations with kill/death ratios? Are there correlations with # of games played? Do these correlations correlate between themselves, so combinations of group size combined with play count? We certainly have the terabytes of data required to curve fit or otherwise experiment with. I realize we won't be able to take this all the way to perfect, but I'm not sure that's a reasonable goal to set out with in the first place. The cool thing is this is one of the places where we can actually run controlled experimentation. We would, on launch of an updated system, be able to say with confidence, 'this new system is X% better at predicting group player skill'.

You know we love you right? You.... you posted this on a Saturday even. You and Brian both.

You hit exactly on why I didn't think the idea was that useful. Can you solve for it? Sure - with a lot of blunt force solutions regarding tracking metric crap tons of data. It turns into even more of a mess if you ever want to look at letting players group into gatherings bigger than 4. Also any sort of lobby system that promotes semi-regular groups of almost any size. You're absolutely correct, the smart choice is is trying to find better ways of using player-specific Elo.

The real issue is 'what are you trying to accomplish'?

With the current improvements to the MM coming down the pipe all that really matters is 'does being in a group shove your average over 1000/1500?'

Are you able to separate premade from pug Elo? If you can, wouldn't it be easiest to just track premade Elo separate from pug Elo? It'll be a rough estimate but anything that doesn't involve a Big Data solution is going to be a rough estimate. Since all we're really shooting for is establishing position relative to the 1000/1500 threshold that'd probably be just fine. Seed premade Elo with existing pug Elo. In fact you can still keep them combined; you keep a single Elo for the player but they adjust for k-factor based on the average of Elos of everyone they're in a team with, not the whole 12 member team average you're dropping with. So if you're a rockstar and are babysitting a couple of newbies you're going to end up pushing your Elo when you're pugging up into a range you probably can't carry when pugging and are going to pay dearly for using a couple of nubs to drag you into the kiddy pool so you can get some roflstomp time. Conversely if you're a sandbagger tagging along with some killing machines you're not going to really gain much of any ground on your Elo - nor should you, they're pulling all the weight.

As to reflecting premade Elos and the advantage they give, I'd say just give a flat 2% bump to Elo per person in the premade, so a 4man is calculated almost like 5 peoples Elo - they're Elo is calculated 8% higher. So a 4man with an average Elo of 1600 would be counted as a 1728. Seems like a simple solution that would scale easily with changes in group size - an 11 player group with a 1600 average dropping together would count as 1952. The effort in accurately tracking team impact on individuals Elo scores seems like it would quickly suffer diminishing returns for the effort.

A more useful refinement would be an Elo modifier based on your success with specific weapon builds. There's a huge variance within a weight group between performance - being a rockstar with a Cataphract 3D in no way reflects itself in how they play in a Dragon or Orion.

Conversely a person who's good with PPCs, tracking where it's going to hit at various ranges, it's going to reflect accurately across a ERPPC Spider up to a Highlander poptart.

With 3/3/3/3 the need for a separate on weight class becomes less relevant. it's almost double-dipping the value of weight class; you're going to be fit into matches based on your weight class now anyway. Tracking your Elo in each weight class is already very general anyway for the reasons mentioned above. If you know how to land an AC20 you're going to do it in a Hunchie or an Orion or an Atlas.

In the long run I think a more accurate direction would be a single Elo score for each player that's then modified by what weapon (maybe even modules, equipment, etc. As detailed as you want to get) you're loading. In our stats you already track what my win/loss ratio is for modules. Do the same for every weapon. Have a seeding threshold of 40 matches for any piece of gear. Have a single core Elo for each player. Modify that what gear they carry.

I also recognized, while trying to figure out how to accurately weight weapons, that you need more than just a 40 match threshold - you need a threshold for USED in matches. So 40 matches the weapon was USED in. Otherwise you end up with things like MLs out-weighted for their actual performance just because someone always has one.

Crap. This is why I'm more in favor of a single Elo with the simplest possible modifiers. I'm strongly against using kills, damage or assists - the modifiers you use will drive behaviors. You drive kills more than wins you get people making stupid choices to get kills, or taking stupid loadouts to maximize damage. You want to give the biggest rewards to people who are using whatever is most likely to drive a win.

It might be best to give each weapon a modifier rating used to base its Elo modifier weighting off of. Say 4 to 1, dividing the weapons % impact on win/loss by the modifier, so something like an ML is only 1/4th the modifier that an AC20 is for example. This would be good as it self-corrects for heavier mechs, or at least stacking more weapons - so if for me a LL is equal to 28 points of Elo, if I pack 4 of them on a mech I'm going to drop with a 112 point Elo bump. Maybe a threshold penalty on that for going over ghost heat? So firing 4 LLs gives me a heat penalty of 62% for those weapons their impact on my Elo is reduced by 62%, so my Elo only goes up by 69 points for bringing 4 LLs.

Obviously I don't have the meta-data for what weapons have what impact on win/loss but in my opinion that would be a far, far more accurate modifier for Elo than trying to track it by weight class. What weapons someone brings is far more relevant to how well they carry in a match than the tonnage they bring. I carry a LOT more in a 3E with 3xAC5s and 2xPPCs than I do in a Battlemaster with 6xMLs, 2MGs and an LL. Yet my Elo in them is the same. This makes it bad for me to pilot anything except what I carry best in.

You want to drive diversity and people playing more for fun? Modify Elo by chassis and gear win/loss with a 40-match seed. Award k-factor based on modified Elo, not base Elo. You'll also only adjust base Elo based on what percentage of your modified Elo is base and what is modified; so if I'm a 1.75 in an Atlas with an AC20 and LLs and SRMs, all of which give me a big buff to my Elo, my base Elo will only tweak up and down a bit. In fact the more I drive that Atlas with the same loadout the more my returns on Elo change will diminish - which is appropriate, in that instance it's more the mech and loadout driving the wins and not any improvement in my skill.

You'll want to find a standard deviation for what the average modifier to Elo for people will be so you don't suddenly create Elo inflation and subtract that from everyones base Elo but otherwise your wins and losses modify your base or 'true' Elo, but that Elo is modified up and down by the chassis and loadout. This means that when I drop in my Banshee 3E with 3xAC5s and 2x PPCs I'm going to be playing with a harder group of folks than when I'm trying to unlock basics in the Awesome I just bought for the first time. It means that when I do drop in that Awesome I'm not looking forward to a 14 match losing streak and effectively being a burden on my team; my Elo will be inherently lower because it'll be a mech I have no history in so I won't get the chassis bonus. Though if I'm using weapons I already know how to use to good effect I'm still going to be viewed as being above 'default'.

That, and the simple changes to premade Elo calculation seems like it would more tightly and accurately define a players Elo as they change mechs, which in turn will make their premade Elo more accurate. While the initial setup might be a hassle, identifying how to quantify each weapons impact on a persons Elo, it's nice in that you set it up once and going forward adding new mechs and even clan weapons is easy - they should scale right in seamlessly. It also doesn't care if you're dropping pug or premade or game mode or whatever other variables show up.

It would also make people feel more comfortable with taking something other than top-tier. If you're not packing peak-meta then you're not going to be dropping in peak-meta Elo. In the end, isn't that really what people are looking for in the matchmaker? A feeling that it's accurately reading how they're playing and placing them according to that, not an arbitrary value based on what it thinks their weightclass should carry.

Sorry for the novel but it's a complex topic. You're absolutely correct on the value of better refined tracking of player performance metrics, but the big issue is how to use it in a way that people will appreciate. You want it to make people feel like it's giving them more freedom to play the game how they want, not herd them only into what works best.

[Chronojam]

Modo44, on 13 April 2014 - 08:17 PM, said:

Elo is like democracy -- it is not great, but really the best we have. Unlike elaborate "I had a great idea" systems that people keep proposing, Elo actually takes into account all factors. Looking at your example, playing solo in an LRM boat will include the randomness of enemy ECM in the resulting Elo.

Trying to hard-code those effects in the matchmaker is a fallacy, because it assumes that there is a simple model to follow. However, the game is in constant flux, so you will never actually know all the possible modifiers nor their weights. In addition, you would need a very elaborate tracking system, probably outside of available processing power. This brings us back to why a simple modifier for groups will likely not work, and an advanced one is not feasible (and may still not really work).

Elo skips those issues by looking purely at results, essentially auto-weighing all factors. I firmly believe it would be better with more values tracked (for solo/group play, and for chassis, as suggested earlier). While I see how having too many values would make them converge slower, they would still converge, and you would not have the issue of Elo values possibly representing a wide skill range. I see two simple solutions: 1. Slowly decay values over time. That way players returning to the game will have an easing period. 2. Seed the value for a new chassis with existing numbers for previously owned chassis of similar weight. That will not be 100% correct, obviously, but it reuses some of the earlier data to allow quicker convergence.

I'm not sure you understand. Elo is a system designed around an even, uniform board everytime with even, uniform players. Going farther from this circumstance leads to a more inapplicable scenario. Chess? Great. Pro football? Okay. A well tuned RTS? We're starting to deviate. MWO? Urgh.

We may as well look purely at how long you've been playing versus your personal kdr weighted by tonnage. The inapplicability of Elo to situations allowing for players to have uneven capability is precisely why a number of games have abandoned it. When you walk too far from even player capability, you effectively are trying to come up with a rating of equivalence for users playing two different games.

As far as MWO is concerned, you're trying to come up with a uniform score that will work if you're playing football, when the other team might be playing rugby. Or soccer. Or the "other team" is actually three different teams; one is playing football, one is playing soccer, and one is playing capture-the-flag. Eventually, you're left with a number that's just a number and trying to assign meaning after the fact.

[Kageru Ikazuchi]

While using only Elo (and weight class and tonnage) to try and make fair matches doesn't seem to be the most accurate solution, it is simple and virtually impossible (in the long run) for an individual player or group of players to "game the system". (By "in the long run", I mean after hundreds of matches.)

As I understand it, at it's most basic, your Elo score measures your likelihood to win (or lose) against another player ... if you beat the odds, your score goes up ... if you lose a game you should have won, you score goes down.

Sure, there are probably hundreds of different factors that go into how easy or hard any given match will be ... the mech you bring, the mechs your group brings, the mech your PUG team mates bring, the mechs your opponents bring, loadouts of all those mechs, the map, which side you start on, the game mode, any disconnects, time of day, how much you've had to drink, how tired you are, etc.

Also, the metrics available to measure how much impact you had on the match are similarly numerous ... kills, damage done, damage taken, components destroyed, assists, points captured, etc.

But ultimately, only one thing remains constant ... you ... and only one metric really matters ... did you win?

We've all read the arguments about how and why Elo is not the best way to make fair matches, but I really think that after the launch module comes out, along with the new rules for making matches in public games (3/3/3/3, one group per team, Elo buckets, and weight-matching), things are going to change significantly. It might be instantly better (or worse) or the change might be so subtle that we don't really notice for months.

I recommend tabling the "Elo sucks" discussion until after April 29th.

Edited by Kageru Ikazuchi, 13 April 2014 - 10:26 PM.

[Tekadept]

Shouldn't we just base ELO on the match score of an individual, and it doesn't matter if they win or lose, that way its an individual persons skill? what is the reasoning for not doing that.

Has data been tested based on current statistics gathered and proven that the W/L match up using an individual ELO is way beyond 50% chance of a W/L for a team?

Can't it be based on what is considered an average "match score" based on the match score metric of the opposing team, if you do over that, your elo raises or lowers by a %, you could even throw in some math to factor in the teams win or loss, but it still comes down to the individual performance?

I understand back when ELO was introduced, there were less Match score earning "opportunities" but more and more things with assists etc. have been coded in so it should be a much more reliable metric to use now.

Why do we even need to strive to make it a dead on 50% chance of W/L for a team? its kinda like school sports events, they give out 6th place ribbons now, thanks for coming have a ribbon.

Edited by Tekadept, 13 April 2014 - 10:33 PM.

[Modo44]

Tekadept, on 13 April 2014 - 10:31 PM, said:

Shouldn't we just base ELO on the match score of an individual, and it doesn't matter if they win or lose, that way its an individual persons skill?

No, because the match score is an arbitrary system that obviously does not track many skills that lead to winning. For example, it ignores things like capping points or tanking damage. This illustrates why Elo -- while not perfect -- is easily the better skill tracking system.

Edited by Modo44, 13 April 2014 - 10:51 PM.

[Tekadept]

Modo44, on 13 April 2014 - 10:48 PM, said:

No, because the match score is an arbitrary system that obviously does not track many skills that lead to winning. For example, it ignores things like capping points or tanking damage. This illustrates why Elo -- while not perfect -- is easily the better skill tracking system.

But my point is, the current ELO system doesnt seem like it would track any kind of individual skill whatsoever, unlike Match Score which has some basis on individual skill ( I know its not as comprehensive as it could be)?
A person can join a match, rush in and die in the first 30 seconds and his team wins. so his ELO would go up if it was determined so. That person did absolutely nothing, yet his ELO goes up just for appearing in that drop and doing a suicide charge?

An example would be in a unit, have 3 experience players, a 4th guy new to the game drops in, the dirty premade 4's team keeps roflstomping the enemy, as this person is new he is pretty bad and doesn't contribute much as he is still trying to learn the ropes, Yet this new persons ELO keeps going up and up if the matchmaker determined it should? that's the understanding I have. This person then drops solo and is thrown in the deep end because his ELO got inflated from playing with the experienced guys.

Edited by Tekadept, 13 April 2014 - 11:43 PM.