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

Because this article is so thorough, I’ve conserved space by using these little expando-blocks. All rebuttals are in this form, and I encourage you to go read the ones that pertain to your personal opinions. Simply click once to open and again to close it.

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

Most would argue that our current balance problems can be solved with the numbers already in the game – that heat and/or some other system can be bent in such a way that it solves our balance problems. I vehemently disagree with this notion. No approach using the game’s current systems will adequately address all of the major issues, and they will all have unintended consequences.

The problem we face was never balanced for in tabletop Battletech. Random hit locations meant spread damage, but that kind of system is simply too harsh for a realtime shooter; superior aim must be rewarded. A new set of numbers to act as the bridge between those two realities is the only way to fully address the problem without leaving any messes to clean up.

An analogy in software engineering: modular code is good code. As the requirements of a piece of software grow and change, a programmer is often faced with two choices – the lazy way and the right way. The first consists of sprinkling conditional statements and other additional code into existing systems to enable them to handle the new problem. It’s the easy way, and it’s not always bad when used for small things that won’t need to be expanded or changed later.

The right way consists of writing a separate system to solve the new problem. If the problem is a significant one – particularly one that existing systems were not meant to solve – it’s always wiser to use the latter approach. It’s a precision fix to a problem that doesn’t affect other code modules – much like what this solution does for balance.

Moreover, it makes later additions to the game much easier to handle. Having this set of numbers separate from the others allows proper balancing for different problems; it is a decision the developers would not regret, particularly when Clans come out to play.

My solution is comprehensive enough that all alpha-based cheese, current and future, is effectively eliminated. I challenge you to think of a single cheese build that would survive. Sure, the 4xPPC Stalker and AC/40 Jagermech will be around, but they’ll take twice the skill to use (and they’ll simply never be as effective as they can be now).

Preventative: preempting bad behavior instead of punishing it

Another extremely important pillar of my balancing strategy is prevention. Heat penalties, effects for overheating, recoil, permanent damage, and other loss of functionality are ineffective solutions in my mind because they don’t prevent pinpoint alphas from happening – they merely punish players for doing it. Because extreme, pinpoint damage is very effective, it’s often worth doing even at a severe penalty. And at the point where it isn’t, the penalty is probably too severe.

The key is preventing players from doing it in the first place, and that’s exactly what my method will do. With my system, players have a choice between accuracy and extreme, immediate damage; I don’t believe they should ever have both.

Surgical: decoupling the problem from other numbers and game mechanics

Messing with existing numbers (heat, speed, etc.) has a very high potential to create unintended consequences. The heat system is a fragile, intricate web of balance. Shoehorning it (or any other number) to try to fix a problem it was never meant to solve will end poorly. This problem did not exist in tabletop; it only exists in realtime MechWarrior games. A separate set of numbers is the safest way to allow developers to balance it as a separate problem. Any solution involving our existing systems will have unknowable cascading effects, and that’s inherently riskier than what I’m proposing.

The system is designed to be completely isolated from every other part of the game; fire discipline is the only thing players will need to adjust. Aside from a distinct lack of instant vaporizations and slightly longer matches, gameplay shouldn’t see any other collateral effects.

Intuitive: ensuring minimal adjustment is required by players

One of the most important aspects of any new system like this is how easily it will just drop in. It will be intuitive to players, it should be easy to present on the HUD, and it won’t have collateral effects on other parts of gameplay. Anyone who has played a first person shooter with recoil will immediately recognize a loss of loss of convergence and cone of fire for firing too much too quickly. Because the TCL dissipates so quickly, it won’t need to be on a player’s mind like heat; staggered firing will simply become second nature due to its immediate, negative consequences.

Extensible: enabling tons of cool additions

In addition to solving nearly all of the game’s core balance problems, it gives the developers a fun, interesting set of numbers to play with. In the thread I originally posted to get feedback about this idea, a ton of interesting mechanics were thrown out there. Poptarting could be addressed by lowering the maximum TCL while jumpjetting. Critical hits to systems like the gyro, sensors, and targeting computer could have effects on the load or its rate of dissipation. The ambient environment could even influence the targeting computer in fun ways. Though I think the initial version should be integrated with no additions (for obvious reasons), I’d love to see the developers do some interesting things with it as time goes on.

Tactical: allowing pilots to make meaningful decisions

While many systems focus on how to make alpha strikes or convergence go away entirely, mine presents the player with a choice: accuracy or immediate damage. It’s a light simulation element that adds an interesting layer of depth to fire discipline. It may be worth overloading your targeting computer as you dodge around a corner, but it’s not such a good idea when you’re in the open and 300 meters away from your target. I see no reason to remove elements from the game when you could simply give the player a choice.

Superior: putting the beatdown on alternative solutions

Even if you have reservations about this system, I challenge you to find a solution that is more effective with fewer unintended consequences. Every other approach to solving these problems is either draconian and un-fun or incomplete and ineffective; my proposal hits every problematic build without any foreseeable collateral damage. I know most people want something less complicated, but there simply isn’t an easy solution that’s more than a band-aid.

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

Weapon Type

Weapon Name

Targeting Computer Stress: # (how much the TCL increases by)

Simultaneous Fire: # (how many you can fire simultaneously)

Continuous Fire: # (how many you can continuously fire)

*/Note: (If applicable)

Energy

Small Laser

TCS: 8

Simultaneous Fire: 12 + Change

Medium Laser

TCS: 12.5

Simultaneous Fire: 8

(ER)Large Laser

TCS: 25

Simultaneous Fire: 4

Small Pulse Laser

TCS: 10

Simultaneous Fire: 10

Medium Pulse Laser

TCS: 15

Simultaneous Fire: 6 + Change

Large Pulse Laser

TCS: 30

Simultaneous Fire: 3 + Change

(ER)PPC

TCS: 50

Simultaneous Fire: 2

Ballistics

Machine Gun

TCS: 0.8 (8 / second)

Simultaneous Fire: 125

Continuous Fire: 12 + Change

Gauss Rifle

TCS: 75

Simultaneous Fire: 1 + Change

AC/2

TCS: 10 (20 / second)*

Simultaneous Fire: 10

Continuous Fire: 5

*Value for Autocannons is based on caliber (5/caliber)

AC/5

TCS: 25*

Simultaneous Fire: 4

*Value for Autocannons is based on caliber (5/caliber)

AC/10

TCS: 50*

Simultaneous Fire: 2

*Value for Autocannons is based on caliber (5/caliber)

AC/20

TCS: 100*

Simultaneous Fire: 1

*Value for Autocannons is based on caliber (5/caliber)

LBX/10

TCS: 30* [40]

Simultaneous Fire: 3 + Change [2 + Change]

*Value for LBX Autocannons is based on caliber (3/caliber) [4/caliber]

Note: These are underpowered and need damage adjusted to 1.2 per pellet or something. The values in [ ] are based on the LBX getting some love.

UAC/5

TCS: 25* initial shot, 12.5* double-tap

Simultaneous Fire: Depends on double-tap usage

*Value for Ultra Autocannons is based on caliber (5/caliber initial shot, 2.5/caliber double-tap)

Note: An Ultra Autocannon does not add its TCS to the TCL if it jams.

Note: Ultra Autocannons are a bit awkward with the double-tap. This setup allows UACs to serve their intended purpose without bypassing the penalty. You may notice that with current TCS values, a UAC/20 would take a partial accuracy penalty on the first double-tapped shot. This is intentional as limiting pinpoint damage is my intent and UACs don’t get a free pass.

Missiles

SRM

TCS: 4.167 per missile

Simultaneous Fire: 24 missiles

Note: These numbers are based on SRMs getting the love they deserve. These are underpowered right now, and I figure they’ll end up around 2.0 damage / missile. I refuse to make the TCS value based on the current, broken state of SRMs.

SSRM

TCS: 6 per missile

Simultaneous Fire: 16 missiles + Change

Note: These are hopelessly overpowered right now due to their affinity for the center torso. This number will look a lot more reasonable once they’re spreading damage around properly.

LRM

TCS: 2.5 per missile

Simultaneous Fire: 40 missiles

Note: Again, these values are based on LRMs feeling right. They’re currently overpowered because they seek the core too much; I’m hoping they increase damage slightly and make it spread more evenly.

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

The Stalker can fire two PPCs simultaneously (TCS == 100) without incurring any sort of accuracy penalty. One second after the first volley (when the TCL is at zero), another two PPCs can be fired without a penalty.

Firing three at once (TCS == 150) would result in the loss of convergence and a moderate accuracy penalty. Firing all four simultaneously (TCS == 200) would result in the loss of convergence and the maximum accuracy penalty. A 6xPPC Stalker could reach a TCL of 300 by firing all six at once, but the maximum accuracy penalty will occur at 200.

You could chain-fire the PPCs at a rate of one every half-second (you’d need eight PPCs mounted to do that continuously) and maintain a neutral TCL.

Because of the massive drawbacks (engine and heat issues), there will no longer be any reason to take a 6xPPC Stalker. 4xPPC Stalkers will be around, but not nearly as cheesy because they’re forced to stagger their shots instead of pinning you in the center torso twice.

6xSRM6 Catapult

Note: Again, these numbers assume PGI will make SRMs viable. I refuse to base my TCS values on the current state of SRMs.

The Splatcat can fire four of its six SRM6 packs simultaneously (TCS == 100) without incurring an accuracy penalty. The remaining two could be fired a half-second later to avoid any penalty.

A Splatcat that fired all six at once (TCS == 150) would lose convergence and take a moderate accuracy penalty. The loss of convergence would be particularly damning for a Splatcat because its ears are rather far apart.

Most of the time (by my best estimation of what good pilots will do), Splatcats will fire each ear individually (TCS == 75). They’ll still be able to pour on the pain, but the obscene alpha of their former days will remain in the past.

2xAC/20 Jagermech

The Jagerboom can fire one of its AC/20s (TCS == 100) without any sort of penalty. It can fire the other AC/20 one second later when the TCL reaches zero to avoid angering the targeting computer.

A Jagerboom that fired both AC/20s simultaneously (TCS == 200) would lose convergence and incur the maximum accuracy penalty.

Waiting only a half-second to fire the second AC/20 would result in a TCL of 150, the loss of convergence, and a moderate accuracy penalty.

Like the Splatcat, the loss of convergence will have a rather large effect on the Jager because of the distance between its arms. An accurate Jagerboom is effective; an inaccurate one is squishy and useless. You’ll still see them around, and they’ll still be a threat. They just won’t be nearly as demoralizing as they are today.

1xAC/20, 3xSRM6, 2xML Atlas

A brawler Atlas can fire either its AC/20 (TCS == 100) or its three SRM6 packs (TCS == 75) and both medium lasers (TCS == 25) without incurring any penalty. Alpha striking will bring the TCL to 200 and result in the loss of convergence and the maximum accuracy penalty.

9xML Hunchback

The Swayback will be able to fire eight of its nine lasers without any sort of penalty (TCS == 100). The remaining laser could be fired an eighth-second later to avoid losing convergence. Firing all nine simultaneously (TCS == 112.5) would cause the loss of convergence and a very small accuracy penalty. Under the restrictions (and current numbers) of my system, you’d probably be better off running 8xML, but it would be easy enough to set up two weapon groups and fire them slightly apart to avoid the overload.

6xML Jenner

It would be impossible to overload the targeting computer with only six medium lasers.

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.

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

I’m well aware that a cone of fire and the removal of convergence have been discussed ad nauseum and both are largely unpopular with the community (including myself). The difference in this case is the high threshold that must be crossed before either penalty is applied. Instead of forcing an artificial accuracy penalty for everything, the targeting computer only affects the player when they’ve overloaded it.

Rather than simply not knowing exactly where the next shot will go, the pilot has the choice between accuracy or extreme, immediate damage. Because the HUD allows the player to see whether their next shot will overload the targeting computer, there’s nothing random about it.

In effect, TCL actually increases the value of good aim by forcing many builds (particularly snipers) to shoot more frequently. Additionally, fire discipline will be much more necessary to be an effective pilot. It’s one thing to be penalized by shutting down in the safety of your pack; it’s another to have your shots going all over the place.

It Introduces New Balance Issues

Every potential solution could cause balance issues. Mine is just far less likely to do so because it allows for separate problems to be balanced independently of each other. A new set of numbers that does nothing more than limit accurate alpha capability will have very little effect on any other aspect of the game. As mentioned previously, it was one of my core goals to make sure this system could go in without requiring other work or balance changes.

It's Too Complex for Players

Players operating under this system will need to change two things, and two things only:

Group weapons properly (total TCS <= 100)

Don’t spam all your weapons at once

Forget about the numbers, the rate of dissipation, the details of the accuracy penalty, and all the other minutia – when you boil it down to the player’s interaction with the system, it’s a simple choice between staggering fire for accuracy or taking a one-time aim penalty for extreme, immediate damage. Players won’t need to micromanage the TCL or time their shots perfectly – they just need to cut back on the alpha spam. Again, weapon cooldown and heat will remain as the only limiters on damage over time.

Furthermore, if you’ve played an FPS with recoil, you’d immediately understand what’s going on; it’s intuitive and perfectly catered to the mass market. Even without that experience, it would take someone perhaps two minutes in the training ground or shooting at a wall to figure out precisely what’s happening.

You want to know what doesn’t have mass market appeal? Getting one- or two-shotted in a game that takes two minutes to just get to the fight.

One huge benefit my strategy is that it will only require players to change one thing: fire discipline. Whereas movement/heat penalties, highly-penalized group fire, and the wait-for-convergence strategy will all fundamentally alter combat and force players to make large changes to how they play, this solution will allow this entire balance problem to be de-coupled from every other system in the game.

Additionally, I think a lot of players are craving more depth and will actually enjoy having an additional simulation element. It’s a sorely-needed later of tactical depth in what has largely become a mindless, point-and-click shooter since ballistic host state rewind.

It's Too Complex and Arbitrary in General

I truly wish the solution could be less complicated. If there was a way to simplify this without forfeiting effectiveness, I would do it. At the end of the day, I greatly prefer solvency to simplicity, and that’s why many of the complicated details remain.

I realize that everyone wants a simple solution to our balance problems, but it’s just not going to happen. There is no magic wand – believe me I’ve been searching. The gap between tabletop random and shooter precision is massive; a system is needed to be the plug adapter between them, so to speak, and that’s where the TCL comes in. My solution is not light-weight, but it does solve all of the major issues without leaving little messes to sweet up.

To me, the most important piece of complexity is the player’s interaction with the new system. As addressed in the rebuttal above, it’s as easy to adapt to and intuitive as any other solution that’s been put forward. Is this proposal complex in concept and implementation? Sure. Is it complex in terms of player interaction? Absolutely not. As stated above, it simply boils down to staggering fire; the TCL will not need to be micromanaged like heat.

What you may view as an arbitrary scale I see as the missing link between tabletop balance and realtime balance. It’s always been needed, it’s always been missing, and it’s why pinpoint damage has been a problem in all realtime MechWarrior titles.

As you’ll see in my Rebuttals II section, there are very few alternatives capable of solving the problem, and all of those that can are more draconian than what I’m suggesting. I believe that comprehensiveness is key to any fix; simply sweeping this problem under the rug for a few more months by nerfing PPCs is an inane waste of time.

It's Too Much Work to Implement

If you read The Work Required section and think that’s an unreasonable amount of man-hours to dedicate to fixing the most systemic balance problem in the game, I think you’re crazy.

My estimates could be off as I’m not familiar with their codebase or how their asset pipeline works, but if my boss asked me to make this happen, those are the time estimates I’d give. If you don’t believe my time estimates, triple them and tell me it’s not still worth it.

Furthermore, most other solutions are an equal amount of work to implement. What PGI is doing right now (heat penalties on a per-weapon basis) is an equal amount of numbers, programming, and Mechlab changes. The only thing objectively more complex about the TCL is the HUD.

It Penalizes Legitimate Builds

I challenge you to find a cheese build that survives or a legitimate build that gets killed by the nerf-bat. Most ‘mechs (particularly heavies and assaults) will need to stagger their shots instead of playing the mindless one-click game, and that’s exactly how this system is intended to affect gameplay.

Missiles Should Be Exempt

LRMs – They need to do more damage and spread it around way more, but I also think that ridiculous salvos of 60 or 80 LRMs are bad in the same way that huge pinpoint damage is: a single mistake means instant death. I’m not saying getting caught in the open shouldn’t mean death, but I’m suggesting that it should take more than a single click to do. An LRM40 sounds like enough for a single volley to me (especially since you only have to wait one second to fire off a second one).

SRMs – They need to be at 2.0 damage or close to it. Once that happens, you’ll see Splat back in style. And I don’t see any reason that sort of build shouldn’t be hostage to the same restrictions as everything else. The Splatcat would have been a lot less cheesy if it could only fire one ear a time accurately.

SSRMs – They need to seek the center torso less, but again, why should this type of weapon be exempt from penalties? I’m thinking Timberwolf Alternate Configuration D (4xSSRM6 + 2ERPPC) when I’m thinking that streaks need the same limit as everything else gets.

To account for the fact that all of them spread damage, the TCS to damage ratios of missiles are very low compared to other weapons. Once Clan LRMs and Clan SSRMs make an appearance, attitudes on missiles being exempt will change rapidly.

Missiles Should Increase Spread Instead of Losing Lock

Though I’m not entirely opposed, this change has one glaring flaw: player feedback. Spread would be much more work for PGI to implement (they’d need to change quite a few things in the missile code), and it would be very difficult to communicate to the player: “When you fired those missiles five seconds ago, your TCL went to 160 and it made the spread pretty bad.” It’s too delayed for spread to be intuitive. I also see no reason that the TCL shouldn’t function as the boolean (on or off) punishment that it does for the other weapon types.

Forget about Loss of Convergence

See the Clarification: Loss of Convergence section for why it’s necessary.

Forget about Cone of Fire

See the Clarification: Cone of Fire section for why it’s necessary.

The Cone of Fire Should Happen before Loss of Convergence

Having the cone of fire penalty come first will do one of two things: make an accuracy penalty show up unnecessarily early or make the convergence penalty show up too late. If cone of fire started at 80 or 90 in the current system, it punishes players before I think they need it. If the cone of fire starts at 100 and convergence loss comes later, it’s letting some cheese seep through the cracks. In addition, because a cone of fire only punishes long-range attacks, such a change would favor brawlers to an extent.

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

Just like hitting your heat threshold will cause you to shutdown, hitting 101% of your targeting computer’s capacity will cause you to lose convergence. It would be ridiculous to ask for a freebie when “just barely going over” the heat limit, and I see the targeting computer as no different.

You aren’t supposed to go over 100, the TCL dissipates extremely quickly, you have to actively fire a large amount of weaponry in a short timespan to exceed the threshold in the first place, the HUD lets you know what’s going to happen before you fire, and unlike the harsh penalty of shutting down, it just means one volley is inaccurate. Stop whining, cowboy up, and take another shot.

The only compromise that I feel would still be effective is the gradual removal of convergence from 101-125 on the scale. Essentially, it would be implemented as a linear interpolation between the converged and non-converged aim locations. For instance, a TCL of 105 would cause your weapons to be 80% converged, while a TCL of 120 would only let your weapons converge 20% of the way.

Consequences Applied before Firing a Shot is Bad

It could be argued that the preemptive consequences my system applies are harsh and confusing. The rapid dissipation of TCL and the new HUD elements will solve this problem. The weapon group icons around the reticle will change colors based on what TCL will be at: blue for <=100, yellow for >100, and red for >200. Players will be able to know before they fire exactly what the consequences will be.

Furthermore, it dissipates so rapidly that heat and weapon cooldown are still, by far, the limiting factors in damage per second. This system might confuse players for a round or two, but the way it works is extremely intuitive, and the HUD will do an adequate job of conveying the consequences before the action is taken. Once players are used to slightly staggering their fire, it won’t be an issue.

Additionally, a preemptive penalty is the only way to ensure players can’t get off one free alpha strike; causing it to work like recoil would make this entire system pointless

The Targeting Computer Is a Bad Explanation

I designed this system with balance in mind – not lore or realism. It was only after most of it was constructed that I decided the targeting computer was the best explanation for a preemptive convergence/accuracy penalty that also affected missiles. If anyone has a more logical explanation, by all means let me know.

It Would Be Cooler if You Added X

As I’ve said before, a major advantage of this system is how easy it is to expand. Modules, variations for conditions, etc. are not ideas I’m opposed to after the initial implementation. That said, I think the system needs to go in vanilla without any additional frills for proper testing and balancing.

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

Stacking heat penalties will be extremely arbitrary and difficult to balance. Sculpting such an intricate layer on top of the heat system sounds dangerous. There are so many weapon combinations that I think it will be extraordinarily difficult to integrate into what is already a delicate system.

It will punish players for certain alpha strikes, but it won’t prevent them from doing it. Even assuming the heat balancing goes well, the penalties will have to be ridiculously severe to truly deal with things like the 4xPPC Stalker. It still doesn’t solve that single, massive, focused burst that’s enough to leg a light whether by a skilled or lucky hand. It just means they’ll have to be a little smarter about picking their shots.

Refer to “The Coming Storm” to see my thoughts on why solving ballistics is so important. Heat penalties are completely incapable of solving the problem for ballistics (particularly the Gauss).

Verdict: Incapable of solving ballistics, lots of unintended side-effects, will mess with the most delicate system in the game, punishment – not prevention.

Lower the Heat Cap (and Increase Dissipation)

Of all the heat solutions, I like this the best because it’s a system-wide change that doesn’t affect relative weapon balance. But I still don’t like it.

Lowering the heat cap would require harsher penalties for overheating to be effective; otherwise, you’re just making the first alpha shut them down instead of the third. With that in mind, I think it would make the game quite unforgiving to new players. It’s going a bit far in my mind if a single salvo with all equipped weapons could do serious, self-inflicted damage.

I also think alpha strikes are an awesome, valid tactical choice. Seeing a ‘mech fire everything in a desperate bid to put out some damage is fun to watch. I simply think that alpha strikes and regular shooting should have a difference: one is for putting damage on a specific target and the other is for putting huge amounts of immediate damage on any part of a target – not just an act of suicidal desperation.

Increasing dissipation could make the experience smoother, but it would certainly have a few unknowable effects on gameplay. High damage per second would be king, and heat management would, in some ways, be less necessary.

Verdict: Punishment instead of prevention, too harsh, relegates alphas to a sad, lonely corner, will affect the pace of gameplay in unknowable ways, and utterly ineffective against ballistics.

Implement Hardpoint / Customization Restrictions

Hardpoint restrictions are a good idea for a few reasons, and I do think they would help with a lot of the current cheese that’s running around. That said, it’s not a permanent or proper solution to our problem. What about the Warhawk? What about the Hunchback IIC? Even Inner Sphere ‘mechs like the Devastator or Thunderhawk look unbelievably angry running stock configurations.

I’ll be doing an article at another time about hardpoint restrictions. Regardless of where you stand on the idea, it doesn’t solve Canon boats, and that’s a rather large shortcoming.

Verdict: Somewhat effective at mitigating the problem, does not solve Canon boats, does not solve the real issue, could be harsh and irritating depending on implementation.

Make All Weapons Behave Like Lasers

Changing all weapons to behave like a lasers takes away a lot of the flavor and is ultimately a lazy balancing solution. To me, the AC/20 is satisfying precisely because it fires one huge, angry shell. In addition to being uninspiring, this approach to balance leaves several issues unresolved.

Unlike autocannons, the Gauss Rifle canonically only fires a single projectile. Making it work as the only instant-damage weapon simply makes it the only offender and thus the ideal choice for boating. If it gets the burst treatment like autocannons, it goes against lore and severely gimps the weapon’s capacity for sniping (which is, after all, what it was meant to do).

Gauss aside, UAC/20s and other high-damage combinations are still going to be a problem. Whether or not you’ve got to hold it on target for a little while, 80 points of damage to a single spot is too extreme. While damage over time makes it more difficult to do, it doesn’t come close to making it impossible. Though that band-aid might work for a while, the Clan invasion will rip it right off.

Additionally, this does absolutely nothing to counter missiles. Although they aren’t a big problem now, Clan LRMs and SSRMs will bring a world of pain that must be addressed somehow. The damage-over-time solution effectively eliminates weapon diversity to cover up the problem, and I’d argue that a more robust, permanent solution is far superior.

Verdict: Only partially effective at solving the problem, removes weapon diversity, does not affect missiles.

Apply Accuracy Penalties for Movement

Movement penalties are a terrible (not bad, but terrible) idea for a few reasons. First and foremost, there is already a movement penalty. Go to the testing grounds and aim for nothing but the center torso; you’ll find it’s a lot easier to do when you’re standing still than when you’re moving. Jumpjetting also makes it more difficult. This goes a step too far, in effect punishing players able to shoot on the run. Punishing skill is not the way to make a fun or competitive shooter.

Furthermore, movement penalties beg people to camp. If you think the sit-and-snipe metagame is bad now, can you imagine what it would be like if the game actually rewarded you for standing? How are mediums supposed to do their jobs? Why does my Awesome 9M need a huge nerf? Rewarding the act of camping is unbelievably foreign to me. Movement is a good thing and should be rewarded – not punished. I see absolutely no reason to penalize good maneuvering. All this solution does is make the big alpha boats inclined to camp.

MechWarrior: Online is not like other shooters. In other shooters, the gameplay is fast-paced, characters are maneuverable, and shooting people that are moving is rather difficult; quite the opposite is true in MWO. Camping is already encouraged by the nature of the game, ‘mechs are not maneuverable, and I can’t think of a single positive effect accuracy penalties for movement would have on gameplay.

Verdict: Ineffective at solving the problem, rewards camping, punishes aiming skill, and penalizes all the wrong builds and playstyles.

Apply Accuracy Penalties for Running Hot

This is Canon, but I disagree with implementing it. I see no good reason to punish running hot for a couple reasons. 4xPPC Stalkers often run relatively cool until a heavy engagement, while a lot of brawlers and fire support ‘mechs run consistently hot. Gauss snipers run extremely cool, and larger ballistics in general don’t have too many heat problems. It hits random builds and energy weapons with add a ridiculous penalty, while leaving a lot of cheese (and large ballistics) completely untouched. It will skew balance in a big way and will mandate weapon rebalancing.

Verdict: Ineffective with large ballistics, punishes the wrong things, will undoubtedly mandate a weapon rebalancing.

Lock and Acquire Convergence

This is an interesting idea that fits well with Canon, but I don’t like the effect it will have on pacing or the way it punishes twitch shooting. It will make ‘mech combat slower, but not in a good way. Taking that skill shot as someone dodges between cover will be impossible. Torso twisting will be a terrible idea since you have to face them again to lock on again.

Assuming non-convergence is a step too far; gameplay would be too slow, it would take a toll on skilled aim, and it would ultimately drive away mainstream gamers. On top of that, it still doesn’t solve the problem. It just makes those big boats wait a second or two to fire (6xPPC Stalkers and the like already take time to line up a good shot if they know what they’re doing).

This is overly harsh and wildly unpopular. People love group fire, it’s convenient, weapon groups make perfect sense to new and veteran players alike, and its removal would hit strikers in a hugely negative way.

Many mediums and other ‘mechs rely on shoot-and-scoot tactics. Many of them would be at a huge disadvantage if they were forced to chain-fire their weapons. Bursts of damage aren’t a problem – huge bursts of damage all hitting a single location are. We need a scalpel; this solution is a battle axe.

I like that it’s easier to understand, but that solution removes a small bit of complexity for a large portion of solvency. Per-weapon TCS values are necessary to properly balance for fact that different weapons deserve different penalties. Four medium lasers is fine. Four AC/20s isn’t. I would hate to see a Jenner’s accuracy being penalized for doing what it’s supposed to do.

Causing group fire to take a convergence or accuracy penalty is simply too harsh in my mind. Though it would be more true to tabletop in that only the AC/20 could put 20 points of damage on a single location, I think group fire is too intuitive and useful to take the nerf bat to. New and veteran players alike benefit from being able to group weapons, and its removal (or severe punishment) is extremely unpopular with the community.

Additionally, most of the complexity from my system will be necessary to make it work properly. To prevent people from creating macros to circumvent the chain-fire requirement, some sort of global cooldown would be needed. And that system would need to take into account what weapon type is fired since weapons like machine guns and AC/2s have an extremely high rate of fire. At the point where you have a global cooldown on a per-weapon basis, you’re essentially describing my system without having a good explanation or way to communicate it to the player.

Another big problem I have with removing group-fire’s ability to be accurate is the impact it will have on the striker role. Strikers are ‘mechs that rely on the ability to pop out, fire off a quick alpha strike, and duck back into cover. Mediums, Dragons, fast Awesomes, and others would all be unduly punished. None of them have a ridiculously cheesy amount of firepower, but their ability to get it off quickly is essential to the way they play.

Verdict: Effective at solving most problems, does not affect missiles, needlessly nerfs strikers, no less complexity in practice, more drastic effect on pacing, goes slightly too far in my mind.

Remove Convergence

Again, this is extremely unforgiving and unpopular. How do you represent it to the player on the HUD? Beyond that, it gives many chassis an advantage due to hardpoint locations. The HGN-732 can mount 45 points of damage on its right side (3xPPC in RT, 1xGauss in RA) and would be quite superior to a sniper with spread hardpoints. The Jagermech would be useless as a fire support ‘mech if both of its arms couldn’t aim at a single location. This is another battle axe solution.

Everything I said in response to removing convergence applies here, except this version adds confusion and favoritism for chassis with arm-mounted weapons. Arm-mounted weapons are already superior; there’s no reason to make the Hunchback completely useless. The Warhawk is the perfect example of a ‘mech that would be made a veritable god by having arm-mounts, while the Jagermech and Stalker would be utterly useless due to the distance between their weapon mounts and lack of lower arm actuators.

Verdict: Half of the solvency of removing convergence wholesale, double the problems.

Implement Fixed Convergence

Fixed convergence (whether pre-determined or user-set) would be irritating without fixing the problem. It just forces players to be at the range of convergence at all times if they want to be accurate. On top of that, it doesn’t solve those pinpoint alphas – it just makes you work harder for them.

In my mind, it would actually make the problem worse by encouraging more high-alpha builds. Because getting off as much damage as possible as quickly as possible at the range of convergence would be the goal, there’s no better way to achieve that than to run cheesy, high-alpha builds.

Fixed convergence in a game where the player is unmaneuverable (relative to other shooters) just becomes extremely annoying. It’s a simulation element that many players (especially casual / cross-overs) will hate. The negative effect it would have on pacing far outweighs the limited solvency it would achieve.

Reducing the amount of cheese isn’t the same as removing its existence. This solution could actually make things even worse. Imagine one team gets an Atlas with a diverse loadout while the other gets a 4xPPC Stalker with a competent pilot. I can’t imagine the BV of 4xPPCs on an 85-ton ‘mech would be super-high. But that build can carry hard, and without more heavy-hitters to counter it, it could easily be a pillaging.

All of these fixes ignore the real problem. They just try to reduce the problem’s frequency instead of addressing the root cause. I’m not saying I’m against some more work on matchmaking, but it’s also not going to fix this problem.

Verdict: Does not solve the real issue, possibly makes the issue appear less often, unintended consequences, possible negative effects on matchmaking, would require an inordinate amount of balancing.

Implement Recoil for Ballistics

This was the solution I tried to make work for a long time, but every implementation I devised ended up being messy and incomplete.

It makes weapon balancing inconsistent. You’re solving the same problem two different ways for two different weapon types, and you’re not really solving the problem at all for missiles (missiles aren’t bad now, but the Clans will make them bad). It means balancing pinpoint damage will be that much harder because you have to make two or three systems solve the same problem with the same relative strength. It would end up being an absolute nightmare for the balance team.

Communication to the player would also be difficult. Either you let them fire a huge ballistics alpha and then recoil happens (which doesn’t solve the problem since the first shot was pinpoint) or you preemptively penalize them without any sort of explanation. You’d need most of the new HUD elements from my solution to do a less effective job of communicating what’s going to happen.

Verdict: Only partially effective, inconsistent, hard to communicate.

Remove Zoom

This is an incomplete and misguided way to approach this problem. It punishes ranged engagements – not pinpoint alphas. Needlessly forcing the game into close range is not a good solution, and it doesn’t actually fix anything; it merely makes it so that they can’t do it across the map as easily. A 4xPPC Stalker is as effective at 90m as it is at 540m.

Verdict: Ineffective at solving the problem, lots of unintended consequences, annoying for the player.

Increase the Speed of All 'Mechs by a Flat Percentage

Like the removal of zoom, this is a puzzling suggestion that just attempts to make gameplay flow around the problem instead of fixing it. The rationale is that the alpha-monsters will be much slower relative to lighter chassis, and therefore will be the only ones being shot by other alpha monsters. In practice, it doesn’t work that way, non-cheese heavies and assaults are punished, lights become gods of speed, there would be massive pacing changes, and it has the potential to be an absolute disaster. In addition, with the current speed cap on lights, it’s probably not even feasible. On top of all that, it leaves alpha monsters around, relying on other alpha monsters to make them miserable.

It doesn’t address the problem, and it fundamentally alters the pace of combat in a big way. Changing something unrelated to convergence or alphas and hoping it fixes convergence and alphas is a terrible approach to balance. Additionally, it means snipers can’t really snipe. If everything can move just as fast but the rate of fire is drastically reduced, nothing is stopping short-range powerhouses from ripping snipers to pieces.

Verdict: Ineffective at solving the problem, drastic repercussions on gameplay.

Tabletop Values for Everything

Just shut the fuck up.

Verdict: Seriously.

35 comments

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!

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)

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!

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.

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?

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.

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

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.

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.

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).

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.

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.

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.

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:

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.

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.

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.

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!

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.

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.

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!