231 replies to this topic

[Monky]

Thanks for taking the time to post Matt.

[PEEFsmash]

1 sentence?

Bad players being exceedingly loud, pretending like their low-level play means anything to balance discussion, while suffocating the input of top-level players who, (like they do in every other competitive game), put real imbalances on display, while dispelling the perceived imbalances of the low-level masses.

[Dimento Graven]

PEEFsmash, on 12 September 2013 - 10:39 AM, said:

1 sentence?

Bad players being exceedingly loud, pretending like their low-level play means anything to balance discussion, while suffocating the input of top-level players who, (like they do in every other competitive game), put real imbalances on display, while dispelling the perceived imbalances of the low-level masses.

Wow... Just... Wow...

[Screech]

PEEFsmash, on 12 September 2013 - 10:39 AM, said:

1 sentence?

Bad players being exceedingly loud, pretending like their low-level play means anything to balance discussion, while suffocating the input of top-level players who, (like they do in every other competitive game), put real imbalances on display, while dispelling the perceived imbalances of the low-level masses.

Can you diagram this sentence please.

[Wolfways]

Ghost heat, ECM, the heat system in general, and PGI's strange belief that they are constantly balancing things by nerfing other things that aren't related.

[scJazz]

Alistair Winter, on 12 September 2013 - 08:52 AM, said:

Not that I really like pretending that the current movement penalties are working as intended, but we already have movement penalties for terrain. Apart from the fact that the maps are completely ruining a rather good idea by having random angles and tiny impassable rocks, this suggests that the same could be done based on a mech's heat. In regards to aiming penalties, I don't see why it would be so difficult to adjust the arm aiming speed, convergence or torso twisting speed, considering that this is adjusted easily and automatically through piloting skills.

I don't suppose I could just get away with saying something like... I have 30 years experience with Programming, Networking, and being a Geek in general and just call it a day?

No huh?

Alright... I knew I wasn't going to get away with it in the previous post either.

To the part about Aiming... honestly I hadn't considered Torso twist and Arm Traversal. I was stuck on stupid thinking about Convergence. Before we begin though it is worth noting that Pinpoint and Fast Fire are dead skills. They don't do anything at all. Convergence isn't possible because network latency and server time slicing cause random appearing behavior Client Side. Shots that you, the Client, think are at perfect Convergence, because you waited for heat to dissipate, end up being Cone of Fire because the Server is positive that you are still in heat penalty. Again we are dealing with a Server Authoritative Architecture so it doesn't matter what the Client thinks! The Server is always right This is why they removed the Convergence timer during Closed Beta (to the best of my knowledge). As for arm and torso movement... OK you got me there as the effect might be far less jarring. Might! I have to think about that one awhile. Still one thing jumps out immediately... LRMs and Streaks wouldn't be penalized necessarily or the penalty would be far less "apparent".

The Movement penalty doesn't have any clean solution. -1 movement @ 5 heat on the Heat Scale is what the TT rules state.
Just to make things easier that means the top speed of a mech in MWO slows by 16.2kph unless it has Speed Tweak in which case it is 17.82kph. See this already sounds complicated. OK great, hit 5 heat on the TT which for a Mech with 10 DSHS means hitting means getting to 25 points in MWO or hitting 50% (not counting Heat Containment) and then your Mech's speed gets whacked. Now that we have gotten all of that out of the way we run face first into a Boundary Condition. Cross the line bad stuff happens, cross it the other way and no more bad stuff! What happens to a Mech that hits 26 heat (with no Basic, no Speed Tweak, with 10 DSHS)? For 1 second the mech tries to slow down and then speed up again generating a crazy Delta V assuming it manages to slow down to new max speed and then accelerate back up to normal. Add in the fact that MWO doesn't calculate heat as an Integer but instead uses floats. Great so 25.00 heat means penalty and 24.99 no more penalty and this happens in a fraction of a second, 5 milliseconds to be specific or about 1/10th of my typically 50ish PING. CHAOS!

Can some sort of horribly complicated Movement Heat Penalty be created? Sure, it is just math after all. But the resultant kludge would end up having no resemblance to the TT Movement Heat Penalty. Worse the effects would be incredibly jarring to the Client and the Server would have to do a whole bunch of extra Maths.

You bring up the Movement system as it relates to terrain. At first glance it appears to be similar. It isn't. The terrain is a fixed known value. Both the Server and the Client know you can't go up the mountain side so there is no opportunity for a desync. Still you can see the strangeness of the Movement system and imagine what it would feel like if you try to do a TT Style movement penalty. Just play a bunch of games in Caustic Valley. At some point you'll see a mech, probably a big fast medium, run across those little grooves along the sides of the hills and the caldera at an angle. You'll see it stutter across as it speeds up and slows down rapidly over the course of a fraction of a second. You will think it is a network latency problem, imagining that the Player has a really bad ping. He doesn't

NOTE: This is the short version. There is a hell of a lot more I could write but I'm not going to do it. The day after I started MWO I said to myself what the heck!!??!? No Heat Penalty for movement and stuff!?!? I went and did the dishes while thinking about it (spent 15 minutes daydreaming) and said to myself... oohhhhhhh yeah... not really something that can be done in a way that isn't totally insane. PGI certainly thought about this stuff when they started writing the code and came to the same conclusion.

tl;dr There isn't one. At least this version avoided doing seriously huge amounts of math.

[PEEFsmash]

PEEFsmash, on 12 September 2013 - 10:39 AM, said:

1 sentence?

Bad players being exceedingly loud, pretending like their low-level play means anything to balance discussion, while suffocating the input of top-level players who, (like they do in every other competitive game), put real imbalances on display, while dispelling the perceived imbalances of the low-level masses.

Screech, on 12 September 2013 - 10:47 AM, said:

Can you diagram this sentence please.

Edited by PEEFsmash, 12 September 2013 - 11:11 AM.

[Alistair Winter]

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

Users with poor connections can still disconnect during the launch phase or at any time during the game itself, and its very difficult to counter players who actively try to cable pull to avoid losing. Thankfully in this respect MWO works pretty well as your Mech remains in game to be blown up even if your pilot goes inactive.

As others have commented, the ability to reconnect and still be in the match would be great. I don't see any way it could be abused, but it would help a lot, particularly for people who disconnect during the start of the match (and I imagine 90% of all dc's happen during the start)

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

Something that has been considered is upon detecting a disconnect shifting the reward balance for the outnumbered team such that there are greater c-bill rewards for the team down a man, this is potentially something we could do if the community agreed it was a good option.

Sounds good to me. Does this actually depend on the agreement of the community? It would certainly be nice if that were the case.

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

With regards to the match maker matching up too broad a range of skilled players; as stated in my last technical update we're addressing this and the changes are coming in the next patch. The range that the match maker pulls from for weight class and Elo are tightening up significantly which should make it much harder to get a game with too wide a range of Mech weights or pilot skills, the downside may be slightly longer wait times, we'll see when the patch goes live.

I for one would glady wait longer to be guaranteed teammates and opponents at my own skill level. This is great news. Particularly since you're already supposedly looking at ways to make matches last longer, which means the increase in wait times is negated by longer matches.

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

On a general note there is little that the community points out that is wrong with the game that we aren't well aware of, be it technical bugs, gameplay balance, or missing features. We generally just have to make daily trade-offs about what issues we address next i.e. we can't do everything at once. If there is something you think we're not aware of just file a support ticket its still the best way of ensuring we're aware of all issues and as always were grateful for your patience while we get around to the various issues.

And on that general note, I think a lot of the people in this thread (not counting the ones who believe this game is coded by a hundred monkeys on typewriters) acknowledge that you're aware of the major issues. The disagreement and criticism mostly comes from what your priorities are, both in terms of what your programmers are working on and in terms of how many people you have working on different areas of the game. In short, we know you know we know.

I would also say that while I didn't really dare to think any PGI employees would read this thread, I did nevertheless intend for it to be constructive, just in case, and I hope you've had some benefit from reading it. Thanks for posting.

[Tom Sawyer]

Leaving Beta before this game is fully cooked.

[Pirate2Ninja]

Players not accepting the fact they are playing a Beta game.

Not that I don't have issues with how Beta has been implemented, or that we'll still see same problems after launch, but that game we play now has been for the purpose of tweaking and balancing a system with more complicated mechanics than many first person shooters and needs the telemetry of thousands and thousands of players and a lot of time to find the middle ground. Players screaming because there are bugs and balancing issues or because something changes slow down the process.

Edited by Pirate2Ninja, 12 September 2013 - 11:58 AM.

[scJazz]

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

*WORDS FROM A DEV*

Excellent stuff!

And yes... I would like the whole player discos and your team gets a bonus! Still I don't want to derail the thread!

[Dimento Graven]

scJazz, on 12 September 2013 - 10:59 AM, said:

I don't suppose I could just get away with saying something like... I have 30 years experience with Programming, Networking, and being a Geek in general and just call it a day?

No huh?

No, because you're not the only one of you out there...

Quote

...To the part about Aiming... honestly I hadn't considered Torso twist and Arm Traversal. I was stuck on stupid thinking about Convergence...

Yes, one of the things I learned FIRST in my earliest days as a programmer is to always look at what's already there and how you can use/modify it to do what you want. One of the best C programmers I know states flatly that there's not been a "new" line of code written since 1998, everyone has just been recycling everyone else's code.

Quote

Convergence isn't possible because network latency and server time slicing cause random appearing behavior Client Side. Shots that you, the Client, think are at perfect Convergence, because you waited for heat to dissipate, end up being Cone of Fire because the Server is positive that you are still in heat penalty. Again we are dealing with a Server Authoritative Architecture so it doesn't matter what the Client thinks! The Server is always right This is why they removed the Convergence timer during Closed Beta (to the best of my knowledge).

But the mechanism is still there and can be adapted for "deconvergence" upon x% heat. As far as SAA causing issues, or perceived issues with heat dissipation, that's a constant rate based on the load out of the 'mech so I believe that there would be very little noticeable issues with that as one second on the server is one second on a PC, they're both the same amount of time, it's an issue of 'when' that one second began and ended on both systems.

Quote

As for arm and torso movement... OK you got me there as the effect might be far less jarring. Might! I have to think about that one awhile. Still one thing jumps out immediately... LRMs and Streaks wouldn't be penalized necessarily or the penalty would be far less "apparent."

The heat affects for LRM and streaks could be different however, disabling of artemis, and/or extending the amount of time necessary for lock, or under high heat situations, loss of lock requiring lock reacquisition.

Quote

The Movement penalty doesn't have any clean solution. -1 movement @ 5 heat on the Heat Scale is what the TT rules state.
Just to make things easier that means the top speed of a mech in MWO slows by 16.2kph unless it has Speed Tweak in which case it is 17.82kph. See this already sounds complicated. OK great, hit 5 heat on the TT which for a Mech with 10 DSHS means hitting means getting to 25 points in MWO or hitting 50% (not counting Heat Containment) and then your Mech's speed gets whacked. Now that we have gotten all of that out of the way we run face first into a Boundary Condition. Cross the line bad stuff happens, cross it the other way and no more bad stuff! What happens to a Mech that hits 26 heat (with no Basic, no Speed Tweak, with 10 DSHS)? For 1 second the mech tries to slow down and then speed up again generating a crazy Delta V assuming it manages to slow down to new max speed and then accelerate back up to normal. Add in the fact that MWO doesn't calculate heat as an Integer but instead uses floats. Great so 25.00 heat means penalty and 24.99 no more penalty and this happens in a fraction of a second, 5 milliseconds to be specific or about 1/10th of my typically 50ish PING. CHAOS!

Can some sort of horribly complicated Movement Heat Penalty be created? Sure, it is just math after all. But the resultant kludge would end up having no resemblance to the TT Movement Heat Penalty. Worse the effects would be incredibly jarring to the Client and the Server would have to do a whole bunch of extra Maths.

I don't think so. How is the system handling the rough terrain of Tourmaline or Canyon where you get minor but severe terrain angle differences that result in speed changes of the 'mech? Tourmaline has them all over the place, I'm pretty sure Canyon has the junkyard where it happens. I see no chaos, so the netcode must be handling that situation fine to me, when I see it happen it appears to be 'averaging' the differences over time.

Besides, 'Maths' is what computers is best at...

Quote

You bring up the Movement system as it relates to terrain. At first glance it appears to be similar. It isn't. The terrain is a fixed known value. Both the Server and the Client know you can't go up the mountain side so there is no opportunity for a desync. Still you can see the strangeness of the Movement system and imagine what it would feel like if you try to do a TT Style movement penalty. Just play a bunch of games in Caustic Valley. At some point you'll see a mech, probably a big fast medium, run across those little grooves along the sides of the hills and the caldera at an angle. You'll see it stutter across as it speeds up and slows down rapidly over the course of a fraction of a second. You will think it is a network latency problem, imagining that the Player has a really bad ping. He doesn't

Sorry that doesn't wash, again where your computer thinks you are vs. where the server thinks you are doesn't always sync up either, and only under extreme conditions do we get any noticeable affects (rubber banding and random teleports), so I really believe you're being overly pessimistic on this.

Quote

NOTE: This is the short version. There is a hell of a lot more I could write but I'm not going to do it. The day after I started MWO I said to myself what the heck!!??!? No Heat Penalty for movement and stuff!?!? I went and did the dishes while thinking about it (spent 15 minutes daydreaming) and said to myself... oohhhhhhh yeah... not really something that can be done in a way that isn't totally insane. PGI certainly thought about this stuff when they started writing the code and came to the same conclusion.

tl;dr There isn't one. At least this version avoided doing seriously huge amounts of math.

Yet, the ol' GEnie MechWarrior had a heat based movement penalties without issue, and this was in the days of 56.6kbps (at best) modems. I have no idea about their thought process at PGI, they've made a lot of bone head moves when simpler, more elegant solutions were available (hello ghost heat and gauss delays), even IF it was as bad as you're assuming it to be, simple things like averaging speed affects over time and adding rot rates to heat affects, not expecting EVERY affect to immediately switch on and off at specific trigger points could go a long way to alleviating any supposed server load.

Ultimately saying "it can't be done", or "if they do it, it breaks everything" is silly. All the pieces are there it's just a matter of assembling them correctly, instead of making a really bad decision worse by following it up with lots of compromises...

[scJazz]

The number one balancing problem in this game is Scale.

Not just the size of the mechs although it is from this Scale problem that all other scale problems derive.

The scale of the Mechs are not varied enough because PGI started by using values established in TT. Which gives us a range of awful since TT canon scaling is so bad as to be unimaginable. This gives us Trebuchets as tall as Atlai. Things would have been much better if PGI just said the hell with it and made the Atlas 25m (whatever) tall the Locust 5m (whatever) and then filled in the range.

Once that initial screw up was made the Artists made Tourmaline desert with Crystal Spires 1km tall whose Collision Mesh can totally obsure a light mech.

[Heretic379]

The biggest problems lie in pinpoint aiming and instant convergence, then the numerous convoluted systems such as ghost heat which are utilized to mitigate the symptoms without addressing the underlying problems.

[MasterErrant]

ac2 and 5 {ultra} fl;ash bang effect makes them over powered combined with very high fire rate. and cheating.

[Homeless Bill]

The biggest problem with MWO is this:

Matthew Craig, on 12 September 2013 - 09:16 AM, said:

On a general note there is little that the community points out that is wrong with the game that we aren't well aware of, be it technical bugs, gameplay balance, or missing features. We generally just have to make daily trade-offs about what issues we address next i.e. we can't do everything at once. If there is something you think we're not aware of just file a support ticket its still the best way of ensuring we're aware of all issues and as always were grateful for your patience while we get around to the various issues.

"Making games is hard."

PGI/IGP have made their share of poor decisions and messed up plenty of things, but most people don't give them credit where credit is due. Game development is a *****, nothing ever goes as planned, everything takes longer than expected, and these guys are a pretty green studio for a project this ambitious. As much as I'm disappointed with a lot of things, they've still far exceeded my expectations (I decided not to be a Founder simply because I looked at the studio and said, "Nope").

[Applejack]

My shots don't land.

[TOGSolid]

That this pack of cheese is exceedingly hard to open.

Seriously Kroger, what the hell?

[Angel of Annihilation]

Too much reinventing the wheel, too little following established guidlines that have been around and working for 30 years.

[Chemie]

CW vaporware