619 K2

Homeless Bill’s Comprehensive Balance Solution to Alphas, Boats, Convergence, and Clans

, , ,  

Introduction

This is an ambitious and comprehensive balance proposal that is meant to be read in full; that said, this is a serious read and there is a TL;DR for those of you lacking the willpower. The thread that developed into this article has garnered nearly 150 likes and a considerable amount of positive feedback in the MechWarrior: Online forums, and I encourage you to spam the developers with this proposal if you support it. I strongly believe that this is the best (and perhaps only) solution to most of our long-standing and forthcoming balance issues, and that’s why I’ve put such an inordinate amount of time and effort into this. I would like to personally thank Tombstoner for helping solve the biggest player communication issue (weapon group reticle colors) and Phaesphoros for the terrific HUD mock-ups.

Click This

The Problem

MechWarrior: Online is my kind of ‘mech combat – it’s gritty, it’s brutal, and face-offs between skilled pilots can take minutes. Unfortunately, the introduction of host state rewind for ballistic weapons had an unintended side effect: extreme, pinpoint damage now reigns as the undisputed king. Even before the latest PPC and AC/40 craze, the Splatcat was all about putting a ridiculous alpha in a relatively small location by face-hugging. It’s a problem that has persisted all the way through Open Beta and will become exponentially worse with the introduction of the Clans.

I will be the first to acknowledge that many aspects of the game’s balance need fixing: SRM damage, LRM coring/damage, SSRM coring, pulse lasers, hit detection, etc. I also won’t deny that hardpoint restrictions, penalties for overheating, tonnage limitations, and encouraging players to run lighter ‘mechs would cut back a lot of the cheese, but none of them are sufficient to solve the largest and most systemic balance problem that MechWarrior:Online (and all of its realtime predecessors) suffers from.

The crux of the MechWarrior: Online’s major balance problems is being able to deal more than 20 or 30 points of damage to a single location in a single click. Separately, neither massive alpha strikes nor convergence is a bad thing. Together, however, they create a nasty scenario where a couple of clicks is enough to vaporize an opponent. It’s bad, both in terms of gameplay and from a Battletech lore standpoint. There’s absolutely no incentive to fire two shots at 20 damage when you could fire one for 40 damage.

The Coming Storm

Most of the solutions I see being thrown around are solutions to the current symptoms of our problem: PPCs. Heat and PPCs are being debated ad nauseum simply because they are the flavor of the month. PPC boats are a serious problem, but to ignore large ballistics is a dangerous mistake. I fear that the tunnel vision about the current metagame will result in PGI ignoring the impending problems that will be introduced by new ‘mechs and the arrival of the Clans.

Not many people think ballistics are a huge problem right now, but I’d argue that’s only because we don’t have a particularly scary ballistics platform in the game. The AC/40 Catapult has to sacrifice speed, and the AC/40 Jagermech is really squishy because of its profile and XL. They’re still cheesy and too good for their weight, but they have exploitable weaknesses. If, however, PGI decided to drop a Mauler, Devastator, or Thunderhawk on us, there would be untold amounts of whine.

That exact thing could be said for PPCs: if we didn’t have any assaults that could boat 4+ PPCs, they wouldn’t be nearly as reviled. Heavies have to make serious sacrifices to boat them and don’t have the armor to take serious punishment, just like the current scenario with ballistics. When an assault starts boating something unbalanced, it becomes immediately apparent.

The minute PGI releases a ‘mech that can mount 4xUAC/5s plus change and has the ability tank a good amount of damage, the community will be shitting its collective pants. Even if they add ridiculous heat penalties to the autocannons, the Gauss rifle will continue to dominate. 2xPPC + 2xGauss and 3xGauss builds are impossible to solve with heat.

Even more dangerous than new ballistic ‘mechs are the Clan ballistic weapons. The Clan UAC/20 is a mere 12 tons and 8 critical slots. The double-tap will be able to put 40 damage on a single spot. Now imagine a ‘mech with jumpjets that mounts two of them. You’re imagining a stock Hunchback IIC, and it’s absolutely terrifying. Something drastic must be done to prevent Clan assault ‘mechs from being able to kill an Atlas with a single alpha.

My suspicion is that PGI’s plan is to avoid any assault ‘mech that can boat large ballistics simply because they have no good way to balance them – which is a really shitty solution. There’s no reason that balance issues should prevent awesome ‘mechs like the Mauler from showing up.

And if ballistics weren’t bad enough, Clan missiles will bring a host of problems: half-tonnage, no-minimum-range LRMs will make previous LRMageddons look tame, and lightweight SSRM6 packs will make the Splatcats of yesterday a laughing matter. Though the arrival of the Clans is not an immediately pressing issue, it’s better to have a system in place now than to ignore the horrible balance problems for later.

The Solution

Disclaimers: PGI has my complete permission to use this system as-is or with any modifications they see fit. I would be happy to sign anything needed to prevent intellectual property from being an issue. Also, none of this has anything to do with the “Targeting Computer” piece of equipment.

My solution is to implement a scale that represents the load on the targeting computer (TCL). Each weapon would, similar to heat, have an associated targeting computer stress value (TCS). When a weapon (or group) is fired, the stress value of all about-to-fire weapons are added to the load on the targeting computer. The targeting computer load automatically dissipates at a constant rate of 100 per second.

When the load is between 0 and 100 (inclusive), there are no ill effects. When it goes over 100, all missile locks and Artemis functionality are lost, convergence stops working, and you begin to take an accuracy penalty (cone of fire) to any shots fired. Locking capability, Artemis, and convergence are not restored until the load on the targeting computer reaches 100 or below.

From 101 to 200, the accuracy penalty gets progressively worse (the cone of fire expands). Each weapon fires at its own accuracy offset so that weapons mounted in the same component fire in different directions. The pilot can continue to drive the targeting computer load up to a maximum of 500 by continuing to fire, but the effects of a targeting computer overload reach their worst at 200.

To clarify, you can’t get away with one free alpha strike; TCL values are added and penalties are applied before the shots are fired. My proposed TCS values for all weapons can be found in The Numbers section.

Clarification: Loss of Convergence

Convergence is the system that makes all of your weapons aim at the same spot; without it, all of your weapons fire directly forward (parallel, never crossing, out to infinity) from the place they are mounted on your ‘mech. Because all weapons fire directly forward without convergence, it has the same impact at 20m as it does at 800m. It is for this reason that I see the immediate loss of convergence as a necessary penalty – without it, snipers are the only builds affected. A PPC Stalker or AC/40 Jagermech at 100m will barely be affected by all but the most ridiculous cone of fire; the loss of convergence affects all roles and ranges equally.

Though I suggest that going over 100 immediately deactivates convergence, I would not be opposed to the gradual loss of convergence (linear interpolation between non-converged and converged) when the TCL is between 101 and 150 if the original implementation is deemed too abrupt and severe. Either way, the loss of convergence is absolutely key to this system working properly; a cone of fire simply doesn’t affect short-range combat.

Clarification: Cone of Fire

A cone of fire is a small angular offset applied to each weapon. Many first-person shooters have recoil that causes your bullets to spread more – that’s a cone of fire. The spread has a greater effect the farther away you are from your target. The cone of fire I’m proposing would be tuned for around 500m. Snipers would suffer the largest penalty, while combat closer than 200m wouldn’t see a dramatic impact.

The cone of fire is necessary for a few reasons. First, it affects chassis that can boat high damage in a single component (HGN-732 with 3xPPC in the RT). The loss of convergence alone would not affect such chassis as severely. Second, it adequately punishes those who massively overload their targeting computer. Barely going over the threshold is one thing – alpha striking six PPCs deserves a far more severe punishment. Lastly, it forces snipers to exercise fire discipline. I’m okay with brawlers continuing to fight (albeit far less effectively) with their targeting computer maxed out, but I see no reason to allow sniping with an overloaded targeting computer.

Solvency

Robust: doing it the right way instead of the lazy way

Preventative: preempting bad behavior instead of punishing it

Surgical: decoupling the problem from other numbers and game mechanics

Intuitive: ensuring minimal adjustment is required by players

Extensible: enabling tons of cool additions

Tactical: allowing pilots to make meaningful decisions

Superior: putting the beatdown on alternative solutions

The Heads Up Display

The HUD will require a few minor changes to clue the player in about what’s going on. There needs to be a meter showing the current TCL and indications for convergence loss and cone of fire. The most important thing is that the player should always know whether firing a certain weapon group will ever push him over 100% load on the targeting computer. The weapon group icons around the reticle have had their colors changed to represent the TCL value after that group is fired (blue for 100 or below, yellow for over 100, and red for over 200).

Labeled

Idle

Firing, TCL == 37.5, No Penalty

Firing, TCL == 130, Loss of Convergence, Slight Cone of Fire

Firing, TCL > 200, Loss of Convergence, Maximum Cone of Fire

The Numbers

Keep in mind that these numbers are meant to demonstrate the spirit of what I’m going for. Though I think these numbers are a pretty good indication of what relative balance would look like, it’s important not to get caught up in the minutia; this is just a starting point.

My TCS values are based primarily on two things: damage and pinpoint capability. For instance, the TCS of four medium lasers (20 damage) is equal to the TCS of a single PPC (10 damage) because lasers take more skill and effort to keep aimed at a single component; unless you and the target are still, laser damage almost always spreads. The same logic applies for SRMs and LRMs, and it’s why their TCS to damage ratio is so low. My numbers may not be perfect, but they’re a pretty damn good starting point.

Weapon Statistics

A Few Scenarios

The following are examples of how TCL would interact with various ‘mechs. They’re meant to paint a picture of how shots need to be staggered and how alpha strikes will affect different builds.

4xPPC Stalker

6xSRM6 Catapult

2xAC/20 Jagermech

1xAC/20, 3xSRM6, 2xML Atlas

9xML Hunchback

6xML Jenner

The Work Required

At this point, a lot of you are probably thinking, “This sounds like an awful lot of work…” As someone who programs video games for a living, I feel relatively qualified to speculate about how much work this would actually take to implement.

Task List:

  • HUD/Mechlab interface design (5 days – art)
  • Program TCL scale (3 days – programming)
  • Add TCS to each weapon
    • In code, adding to the TCL (2 days – programming)
    • In game data file / associated code (3 days – data/programming)
    • In the ‘mechlab UI (5 days – art)
  • Add and hook up all HUD elements (5 days – art/programming)
  • Implement convergence loss and cone of fire based on TCL (5 days – programming)
  • Random, terrible, and unforeseen things (3 days – art/programming)

All the time estimates for programming are very generous. The only possible problem I forsee is the way their firing / convergence system works. It might require some refactoring to make all weapons add their TCS to the TCL and have an accuracy penalty applied before they fire, but it’s difficult for me to imagine that would be a huge change.

The art side of things is a bit vaguer since I don’t have much first-hand knowledge. Based on my experience working with artists, I figure a week is a reasonable amount of time to get a few HUD and Mechlab icons planned out and drawn. The HUD could be an absolute disaster, but I would hope it takes less than a week to hook up a couple simple elements.

Testing would be, by far, the biggest time-suck. This clearly needs to be tested thoroughly before being released into the wild. Personally, I think this is the perfect candidate for the upcoming test server.

Worst-case scenario, we’re talking about three weeks for two programmers and two artists. If everything goes smoothly, it should only take one programmer and one artist a single week. Knowing what I know about game development, the worst-case scenario is probably more realistic. Regardless of how long it takes, you simply can’t put a man-hour price on game balance.

TL;DR

  • The Problem: Most of our gameplay imbalances result from the combination of high damage and weapon convergence. Convergence is not a bad thing on its own and neither is high damage, but together, they’re killing game balance. Battletech was balanced with random hit locations, while a first person shooter needs reliable and meaningful aiming.
  • The Solution: Implement a second scale (targeting computer load or TCL) to limit extreme, pinpoint damage. Each weapon fired raises the TCL, and it dissipates rapidly (100/second). If it goes over 100, convergence is lost, you take an increasing cone of fire penalty, locks are lost, and Artemis stops working. TCL penalties are applied before the shot is fired. You can do extreme, inaccurate damage all at once or you can do stagger your fire to remain accurate.
  • The Numbers: The goal is to limit pinpoint damage to about 20 damage per second. You’ll see the penalties are less severe for weapons that tend to spread damage. Examples of what you’ll be able to fire simultaneously with no accuracy penalty: 2xPPCs, 1xAC/20, 1xGauss+Change, 8xMedium Lasers, SRM24, LRM40. See The Numbers section for more.
  • The Good: Balances extreme alphas of all kinds (particularly pinpoint), it solves ballistics (unlike a heat penalty), retains (and increases) the value of aiming skill, improves combat pacing, keeps heat untouched, adds an interesting tactical choice, and goes a long way towards balancing Clan technology.
  • The Bad: Added complexity and some work for PGI.
  • Why It’s Worth It: A new system is needed to bridge the gap between tabletop balancing and the precision aim of a shooter. I believe my solution adds a believable layer of tactical depth to the game while solving a host of current and future balance issues better than any other alternative.
  • Hang on Just a Minute: If you have reservations, disagreements (particularly if you believe this solution is too complex), or an alternative that you think works better, I highly encourage you to check out the Rebuttal sections below. I have exhaustively addressed every issue and alternate solution I’ve seen, and it will help to get a much better understanding of why I’ve come to this solution.

Rebuttals I: Disagreements

In this section, I have done my best to answer every possible concern about the TCL scale. If you have lingering doubts, they are probably addressed below. Feel free to disagree, but I challenge you to present a better alternative.

The Accuracy Penalties Are a Nerf to Skill / Aim

It Introduces New Balance Issues

It's Too Complex for Players

It's Too Complex and Arbitrary in General

It's Too Much Work to Implement

It Penalizes Legitimate Builds

Missiles Should Be Exempt

Missiles Should Increase Spread Instead of Losing Lock

Forget about Loss of Convergence

Forget about Cone of Fire

The Cone of Fire Should Happen before Loss of Convergence

The Loss of Convergence is Overly Harsh for Barely Exceeding 100%

Consequences Applied before Firing a Shot is Bad

The Targeting Computer Is a Bad Explanation

It Would Be Cooler if You Added X

Rebuttals II: Alternatives

In this section, I offer rebuttals to every alternative system I’ve seen presented. If you think you have something that would work better to solve our current problems, chances are extremely high that I found it inferior for one reason or another. Even if you disagree, you’ll know why I stand where I do.

Apply Heat Penalties for Firing Multiple Weapons Simultaneously

Lower the Heat Cap (and Increase Dissipation)

Implement Hardpoint / Customization Restrictions

Make All Weapons Behave Like Lasers

Apply Accuracy Penalties for Movement

Apply Accuracy Penalties for Running Hot

Lock and Acquire Convergence

Remove Group Fire

Chain-Fire Always Works; Apply Accuracy Penalties to Group Fire (or Numerical Weapon Limit)

Remove Convergence

Remove Convergence for Non-Arm-Actuated Weapons

Implement Fixed Convergence

Matchmaking Fixes (BV, Tonnage Limits, Etc.)

Implement Recoil for Ballistics

Remove Zoom

Increase the Speed of All 'Mechs by a Flat Percentage

Implement Tabletop Weapon Recycle Rates

Tabletop Values for Everything

 

35 comments

  1. scJazz - June 24, 2013 12:30 pm

    hey Bill… scJazz here… one thing you should make perfectly clear to PGI is this… “PLEASE STEAL THIS IDEA!” no copyright, blah blah… u know what I’m saying!

    ALSO WTG U ROCK I<3 this plan!

    Reply
  2. Brothergrimm - June 24, 2013 5:14 pm

    I agree that you are on to the root problem, but I still am not a fan of that solution, mostly from the complexity and fiction standpoints. Any targeting computer work is done continuously while aiming, pulling a trigger doesn’t suddenly make aiming harder.

    I’d prefer various similar but distinct solutions, including the removal of convergence entirely. Despite your critique of it, I think it is easy to communicate to the player. The reticles become a three-pip reticle for the torso, and a two-pip for the arms, and work as projected textures instead of a HUD element. It would engender a natural 1-2 timing as people try to torso twist to bring weapon systems to bear alternately across their mechs which I think would be fun its own right. Small added bonus: makes sense of the Summoner alternate-arm shooting in the legendary Mechwarrior 2 intro trailer.

    Alternatively, if you want to go the computer route, I think mimicking a second-by-second heat-like scale is confusing and hard to suspend disbelief for. Alternatively, have a computational load per weapon, and a total capacity for a mech. Excess of the rated capacity leads to decreased convergence speed and cone of fire penalty multiplier. A convergence timer can be added near the reticle in game, and the CPU limit stuff added to the mechlab. Mechanically this would be more like “soft” hardpoint restrictions.

    Thus people could still be a sniper boat if they really wanted to, but they will need a long time to line up that shot, and will penalized more than they are now by missing, presumably granting an opportunity to brawlers that tend to carry more distributed weapon systems (and thus fit better under the compute cap)

    Reply
  3. Autofire - June 24, 2013 11:19 pm

    This is a very well thought out solution to game-breaking problem. I whole-heartedly support this. I’m not sure if this would be a major positive side-effect to the plan but something like this may also allow people to play less popular variants that they might not run due to the fact that “cheese” builds make a nightmare to run. In general, this is easily one of the best solutions to a problem that has gone on far too long and I hope PGI seriously considers this. Good job!

    Reply
  4. ignatz22 - June 27, 2013 7:58 am

    Sirs;
    As a Noob, I can only say this is no more confusing than alpha-striking a spyder and him not evaporating, but rather turning, firing, and running off seemingly unscathed. I pug. When alpha-strike assassin-snipers take out multiple mechs, we Noobs get frustrated and stop playing for a while. ANY modification which puts a penalty on alpha-death is welcome to the Noobs.

    -ignatz22
    Noob

    Reply
  5. Silverlance - July 2, 2013 1:26 am

    Awesome. Simply. I love it. Well done and bravo.

    Reply
  6. Spirit of the Wolf - July 3, 2013 3:15 pm

    Hrm.
    I’d like this as an idea, but for some reason none of the images are displaying. Either I’m missing something obvious (which I’m guessing is probably the case) or your images are gone somehow.

    Reply
    • Valder - July 3, 2013 7:26 pm

      I don’t believe there are any images in the article. Just ‘spoiler’ dropdowns to show talking points.

      Reply
      • Spirit of the Wolf - July 3, 2013 8:38 pm

        Well whatever they are, they aren’t dropping down for me when I click on the arrows.

        Reply
      • Spirit of the Wolf - July 4, 2013 3:15 pm

        Weird.
        Now they are.

        Reply
  7. James - July 6, 2013 8:50 am

    I’ll use the Jaegarboom for example. You fire both AC20’s together, and the target computer overloads. But the problem would be that you would retain 100% accuracy for the first alpha… does that make sense?

    Reply
    • Brothergrimm - July 6, 2013 11:52 am

      Under his scheme the fist shot would be penalized. Consider the computer overload as “retroactive” to the fired shot. You may have been an unwitting demonstrator of how this is not intuitive for all people, however.

      Reply
  8. Footupyazz - July 7, 2013 1:14 am

    like a lot

    Reply
  9. vaughan - July 7, 2013 12:10 pm

    Sounds like a well thought out proposal.
    I would append your programming credentials somewhere so people know the wherefore of what you say in the super programing timetable perhaps in a dropdown or a link to your linkedin etc.
    Can this be moved onto a MWO forum rather than linked to inprove the number of people peer reviewing it?
    Another strength is I can’t think of one standard design that will be effected and as the tripple PPC Awesome is seldom a trial Mech starting/new players will not have to worry about it untill they have 20 or so matches and can afford a minmaxed mech.
    this would leave an explanation of this too the advanced training groung demo saving rewrighting time there

    Reply
  10. Typhoon - July 10, 2013 2:43 am

    Interesting article. I disagree with the targeting computer idea and that shooting would raise it’s ‘confusion’. Completely unnecessary.

    Just have the arm weapons converge slowly. If you point your weapons in the sky and then at the ground, the arm weapons would need maybe 2 seconds to converge. Disable torso weapon convergency completely. Torso weapons do not move at all. Voila, the solution. Sniping would become slow and dangerous.

    It is canon, it is lore, it is realistic…every battle in the novels had pilots who would fire prematurely, before the mech can aim properly and miss with several weapons.

    Reply
  11. xenoglyph - July 15, 2013 3:42 am

    What a pimp you are

    Reply
  12. Geddon - July 18, 2013 9:36 am

    Hello,

    I read the article and thought about it. First I liked the idea. But then I realized something else, which makes the whole concept described above obsolete. Maybe there is something I don’t get and I am happy to be enlightend. Here is what I think:

    I own a Highlander with 3 PPC and 1 Gauss. 45 Damage, every time I hit fire. I have only once killed a fresh enemy on the first shot. All the other times I had to fire pretty often until the armor and underlying structure were destroyed and the enemy killed.

    The thing is, even though I fire all weapons at the same time, I don’t hit the enemy at the same spot every time. So if he doesn’t die instantly, I do 45 dmg here, and 45 dmg there. So where’s the difference to do half the damage twice as often all over the enemy?

    If he is not moving I would hit the same spot twice in a row, if i had to split my alpha strike. He would just live 1 second longer.

    1 second is all the difference, the above system will do, so I believe.

    Before I read this, I was wondering myself, if I should put all my weapons on 1 or split them on 1 and 2. And I realized that it doesn’t matter. The only difference is that there is a tiny chance to hit the head. And in that case I would get the instant kill. This is why I put all 4 guns on 1.

    This happened once, and it was fun. I also got headshotted ;-) with one shot, too, but that also happend only once. It happens so rarely that is is just funny, when it happens and if you are the one having the luck, it’s a great time.

    So please help me, because I must have missed something really important.

    Reply
    • Homeless Bill - July 18, 2013 3:30 pm

      Though you may not hit the enemy in the same spot with every shot, snipers generally do a pretty damn good job of hitting the torso. Even if you only get one shot on the enemy, at 45 damage, it’s often enough to condemn them to death (even if it didn’t kill them, people always shoot at heavily damaged components).

      Forcing each snipers to space shots a second apart will do three things:
      1. It will allow time for torso-twist and evasion. Though it may not seem like a lot of time, a second is plenty for a player to get a non-vital component like a shield arm turned towards the sniper. Often, a second is the difference between being out in the open and having safe cover. Scooting between two close pieces of cover wouldn’t require a short prayer – you’d get shot, but not with a soul-crushing 45 points of damage.
      2. It will force snipers to be more consistently accurate with their shots. I typically wait to line up a perfect shot before I fire. I know that I can get away with firing once and being directly back behind cover. If I could only put half of my weapons on target in a single click, waiting for that perfect moment seems more like a risk than a good idea. Even if you spread your damage currently, you’re still primarily hitting the vital components (torsos); under my system, you’d have to take a lot more sub-optimal shots.
      3. It forces snipers to be exposed to take those shots. 45 points of damage for one second of exposure is a really good deal. Usually, no one has time to get a beat on you before you back down. Two seconds, on the other hand, is more than enough time (but not an excessive amount) for someone to train their guns towards your ‘mech.

      Though some weapons need tweaking, overall, you’d see things play out much better. The 4xPPC Stalker would still be around, and it would still be deadly in the hands of those that know how to use it. But it wouldn’t be a win button. It would be a legitimate sniper build that doesn’t make you sad to use.

      Additionally, it would prevent jump-snipers from being overly effective. Ridge-humping has at least some danger – a good jumpsniper moving laterally is much harder to hit.

      Though initially it seems like it wouldn’t make a difference, if you analyze the second-by-second gameplay, you’ll see what a huge impact that bit of extra time would make. It’s even what the heat penalty attempts to do (albeit poorly).

      Reply
      • Geddon - July 19, 2013 12:47 am

        Thank you for your answer. I can see now that snipers, who shoot and go back to cover again, had to stick out their heads out twice as often with your system. Which sounds nice.

        If the sniper is a small agile mech, he has to come out often anyways, because smaller mechs carry less damage-weapons. And the stalkers I have seen so far are slow and steady. Either standing still or moving one direction. They don’t stick their heads out, shoot and dive back into cover. The Highlander, I own, could do it with his jumpjet. But chances are high to miss with the entire shot, while jumpjet sniping.

        But I’m sure there are some evil sniper builds that can ruin your game. That’s what sipers do in every game, for instance in Battlefield. They come out, wait (not very long) for the perfect shot – and you are dead. At leat at the second shot. But nevertheless they don’t seem to be overly good in any game. And no one would seriously propose to take the sniper rifles out of the war game fps.

        I experience most battles in mechwarroir to be be intense, chaotic close quater fights, where hiding behind cover only saves you for the moment until the fast ones catch up with the hiders.

        The endless rain of LRM at the beginning of each fight, is what I find most disturbing. But if that is the mechwarrior style, I pack in my LRM10 and thankfully appreciate the many kill assists it provides so easily.

        So what I want to say is that you got a point and you provided a truly elaborated and well thought solution. I just have not experienced it to be that big of a deal. Maybe I will, when the clans are released in the way you described above.

        Best Regards

        Reply
  13. vjcvkl - July 18, 2013 3:20 pm

    Yeah, they should spend the next 6 months coding this instead of CW! Then we can NEVER do anything but deathmatch, like god intended!!

    Or, you know, they could spend 10 minutes and just make ppcs produce more heat.

    Reply
  14. Tomcat0815 - July 19, 2013 3:50 am

    Wow, what a long read. I see the problem. I like the idea.
    I want to add: One could modify chain fire in a way that the next weapon is automatically fired late enough to not anger the targetting computer.

    The problem is this: No one without a degree in engineering will be willing to understand that concept, especially the total immediate loss of convergence _before_ firing the given salvo.

    Reply
  15. TheBaron - July 20, 2013 1:08 pm

    It’s a workable system, and certainly many times better than PGI’s max alpha nonsense, but I definitely agree that even this system is, as you’ve admitted, “Too Complex and Arbitrary in General.” The biggest problem is the addition of yet another statistic. While it’s far less arbitrary than the max alpha statistic, it’s still yet another value to learn and yet another system to occupy the players’ thoughts, rather than an extension or evolution of systems already in use. I don’t want yet another gauge on my screen, or a set of numbers to memorize. I would prefer it over what we have, but I would really like to see a solution that would add no additional statistics, but instead interact with the statistics already present. It should confer increasing penalties the more weapons you add to a group fire so that firing even 2 weapons at once penalizes you more than a single weapon at a time, but the penalties scale exponentially to the heat and/or damage of the weapon so that 2 PPCs are penalized more than 2 MLs, without creating a loophole for mechs like the swayback to alpha 4+ MLs (which generate the same heat as too regular PPCs).

    With that goal in mind, I made a system of my own. The post is shorter than yours, but there are no new weapon statistics that need to be outlined, only what new functions current statistics would gain to create weaknesses that counterbalance the strengths of group fire mode.

    http://mwomercs.com/forums/topic/127951-better-heat-scaling-ideas-and-other-alpha-nerfing-mechanics/page__p__2576118#entry2576118
    I’d love to hear your feedback.

    Reply
  16. Kalgram - July 21, 2013 1:18 am

    Homeless Bill, I think your idea is excellent but could use polish. My reasoning for this argument is that battletech lore is heavily placed within the real world of physics.

    After my first read through, I see two issues:

    1) A computer which is running continuous processes is not going to experience a finite jump discontinuity in performance due to a mechanical mechanism which takes before the system must to be reintegrated using new approximations.

    2) I believe your targeting computer is scaling too fast. The way you have proposed this currently suggests that the computational load scales linearly but the cone of fire scales exponentially. Why? If anything, the accuracy should deviate due to shifts away from the least squares regression calculated during in-field weapon calibration.

    Being more concise what do you think about these modifications?

    1) Still use a targeting computer, but have it’s first engagement (the first shot or set of shots such as an alpha) be dependent on 2 variables:

    Reply
  17. Kalgram - July 21, 2013 1:33 am

    1) Still use a targeting computer, but have it’s first engagement (the first shot or set of shots such as an alpha) be dependent on 2 variables: Range (precision) and number of weapons (accuracy spread). Increasing either incrementally also incrementally increases the cone of fire due to both computational load and error due to propagating errors beyond calibration.

    2) Weapon and ‘Mech heat and weapon vibration is an important factor in accuracy. Firing large weapons will cause either significant heat increases, significant mechanical vibrations at range or both. Firing small weapons, such as ac5 ultras only becomes a problem if fired continuously over and over which builds up weapon vibrations (significant effect at range).

    3) Overheating and subsequent shutting down is penalized: if your mech overheats and has to shut down, the targeting computer becomes discombobulated for 3-7 seconds AFTER restart due to restart procedures and successive re-calibrations. You may also need to fire your weapon once to re-calibrate it fully.

    Reply
  18. Kalgram - July 21, 2013 1:40 am

    I believe this would be an effective method because it can be implemented behind the scenes without much player thought. They only need to know how big is the reticule. Also, this discourages the boating of certain weapons. PPCs will overheat too quickly, AC20’s cause too much vibration unless used at close range (where the ‘Mechs can be obliterated) and et cetera.

    This may seem like a far too complicated process, but this is a virtual game. we don’t have to account for weapon vibrations and such…just an accuracy penalty that would happen. For example, IF the vibrations actually existed. I don’t think it would be hard to code, it would just be an additional degree of freedom per weapon which needs to be balanced.

    Anyway, I’ve spent a good ~35 minutes reading your article and another 30 minutes replying. I want to see a game mechanic change and I definitely think your idea is in the right direction.
    I care about your ideas, so I would be most appreciative if you would take some time to reply as well! Please ask for clarification if you need any.

    Reply
    • Kalgram - July 21, 2013 1:45 am

      Sorry, I meant ac40’s, not ac20s.

      Reply
    • Bacl - July 24, 2013 2:12 pm

      I actualy think both of you have the solution.

      Like in World of tanks, accuracy is decreasing while on the move but a sitting still tank have the 100% accuracy for the next shot. Same system would fit in MWO.

      Fore fast firing ballistic weapons like AC/2/5 or any combinations, that vibration system could move your mech like in chromehounds; shooting the weapons from on the right arm would slowly turn your torso in that direction ( was thinking just the arm but for this to occur both arms would need to be independant…) + the aiming cone idea while on the move. The bigger the caliber the bigger the recoil so we would have to balancethe emplacements of our ballistics carefully.

      For the energy side however i have my own idea to add on yours. The firing cone while moving and the decay time after the first shot i approve by 100%, but think about it. Energy weapons do require energy from a nuclear powered reactor, if you shoot 1 laser or 1 ppc it recharges as intended but if you shoot 4, the reactor have to give more energy to recharge all of them at once occuring in a small realoading time penality depending on how many weapons (energy) you shot at the same time. Also like SRMs i would see PPC with a split second “charging time” before firing. I do play 4 PPc stalker but thats something that would make it fair.

      Ballistic: heavy, requires ammo and create vibrations affecting your mech’s positioning.

      Energy: heat generation, small charging time before firing (ER/PPC), and reloading penality depending on how many weapons been shot at once.

      Reply
  19. Pingback: Fixing the Mechwarrior Online Heat Scale | Farp's Noodle Hut

  20. John Ludlam Jr. - July 30, 2013 8:16 am

    Absolutely fantastic and well thought out. This is the kind of thing I have been thinking about for a long while now and have never had the grace, poise, and knowledge on how to implement this. Get PGI to start seeing this and do it NOW!

    Reply
  21. adrunis84 - July 31, 2013 7:12 pm

    Hey Bill, epic write up – it is clear you are passionate about the game.. ..lets hope the developers change tack and listen for a change!!

    Reply
  22. antarius1000 - August 10, 2013 4:27 pm

    Nice idea, but dont like it… but its to much overhead in my opinion.

    I disagree with your disagreements:
    i would say a combi of a cone of fire, depending on the weapon, plus a lowered heatcap plus a harder penalty for overheating should solve this problem faster, easier and less confusing.

    Reply
    • antarius1000 - August 10, 2013 4:27 pm

      1)standart cone of fire would be unpopular in the first place, of course, but every FPS has it. (every weapon should have its own)
      Cancels the pinpoint problems, which is one of the two major problems. Should be enough (because of different values for all weapons) for big-ballistic-assaults.

      2)the lower heatcap should help with some out of balance weapons (6ppc stalker) which would have been senseless in TT and should be senseless in MWO too. Should push the meta a bit away from alpha only. (alphas shouldnt disapire, but shouldnt be the standard attack type for all the time)

      3)the heatpanalty should kick in earlier but not such severe at the start and going higher with more “overheat”.
      first visual effe effectss, than greater cone of fire and movement penalties and than autoshutdown and damage of massiv overheat.
      Wouldnt be the problematic with newbes because of a sequence of indicators.

      Reply
  23. Infrasound - August 28, 2013 10:18 pm

    I can still wub on my stalker :> Very thorough and a good read :>

    Reply
  24. C4RNAGE - January 6, 2014 1:45 pm

    interesting now You can make your own game :).

    -Is too complicated this mechanics of yours.
    -The game will loose the taste.
    -Need simpler solution NO DOUBLE AC20 in funy mechs.
    -All balistic weapons shuld have recoil system impemented.
    -Seperate crosshair for every balistic weapon mounted in mech.(from close distance 100 m maybe u can hit single location)

    Reply
  25. Cipher - January 29, 2014 1:55 am

    Hi, i see only one problem here.
    There would be a delay between the actual click on the button, and the time the shot is fired. I think that many( an by many i mean the vast majority) of the players vould cry a lot if something like that happens.
    However, i find your idea really good, kudos!

    Reply
  26. Jon Shearer - January 29, 2014 2:48 pm

    I’m new to the game and I like this idea

    its flexible an separate- thus can do a lot with it

    I like the idea because I love mix an matching parts(same reason I love armored core or naval ops for the p2)

    and I see this as maybe making it so we can get different types of targeting computers xD

    nice job Bill

    Reply

Have your say