132 replies to this topic

[Troutmonkey]

Okay so I've gone full hog into try to show people exactly how I'd like the pinpoint alpha strike problem solved.

I'm advocating for a system where each weapon is assigned a value to represents it "CPU cost" on the "Targeting Computer". Each time you fire a weapon, the cost is added to the computer and the computer returns a firing solution. The Targeting Computer can only process "X" CPU per second. Overloading the CPU causes the computer to return incorrect firing solutions. The more the Targeting Computer is overloaded, the more inaccurate your fire will be. Under normal circumstances fire will be 100% accurate, but firing too many weapons at the same time will likely cause an overload. Smaller weapons and spray fire weapons (SRMs, LB10X) will have a lower CPU cost than larger weapons.

The system shall be represented with a cylinder of fire. The more the Targeting Computer is overloaded, the larger the cylinder of fire. The CoF is completely unaffected by heat or movement. The system is based on Homeless Bill's original idea from 2013 but does not use convergence as that adds more technical overhead (and losing convergence is really bad, as per my last demo).

This CoF solution proposes to solve high damage alpha strikes from any combination of weapon systems by causing that damage to be more spread out than if those weapons were not all fired at once. It is an intuitive system from a players perspective, as CoF mechanics are already present in every top FPS game on the market. Skilful players will won't be punished for their skill in aiming, as long as they can also develop a skill in trigger discipline. It will replace ghost heat, and fill in the voids that ghost heat could not solve - boating mixed lasers / combinations of lasers and AC. This solution will require developer work with relation to balancing weapon CPU values as well as artist work creating new UI elements to represent the CoF and Targeting Computer's load. Depending on how the code is written, the CoF could use existing code based on the jump jet inaccuracy code.

Here is a video of roughly how it will work. Keep in mind that all numbers for CPU "processing", CPU cost,and the maximum amount of spread are all subject to change should any value be too extreme.

This video shows how 6 "Large Lasers" would work when fired in different numbers
and how 6xAC5 would work (1:50)


If you would like to try the demo scene yourself you can download it here (~20mb). Controls are 1-6 for weapons, and Enter to switch between.

Re: This is going to be a lot of work for the devs to do / it's too hard

Yes I agree there is a lot of work to do testing wise, but adding in the mechanics and UI is rather simple as I have just displayed (Server code may require more work, I'm not sure what their netcode is like). A simpler system would be nice, but we already have a "simpler" system called Ghost Heat and it's too easy to work around it and it doesn't solve alpha strikes, it just punishes them after the fact. This system would be impossible to bypass with different combinations of weapon systems. It's a future proof system that can be used to address most balance problems for the foreseeable future.

Spoiler

It's like the NBN here in Australia. The government decided to roll out a "Fibre to the Node" system because it was "cheaper" and "easier" to do knowing that it would be worse. Now it's not even finished and it's already obsolete. If they had taken the more comprehensive approach (Fibre to the Premises) that required more initial work (but less upkeep) we wouldn't be in this situation.

If I were to balance it I would start off and say that alpha of "~25" are okay, and that anything above that would need some spread. Then you would set the Targeting Computer's limit to 25, and then set each weapons CPU to the same as it's damage value. Then you would work out the finer details from there. Reduce the CPU for LBX weapons and SRMs, increase Gauss and PPC CPU slightly.

After that point you would take it to the test server and gather metrics. You can check if the maximum cylinder is too large or small. If any weapons are too inaccurate/powerful you can decrease/increase their CPU. If any mechs are too heavily effected you could increase their total CPU limit.

Later you can start to use the system to add value to other less used in game items like the Command Console and the Clan Targeting Computers. These items could improve the CPU cap at the expense of tonnage and slots in addition to their other benefits. You could even use it to buff / nerf underpowered / overpowered mechs.

Edited by Troutmonkey, 12 February 2016 - 09:46 PM.

[Champion of Khorne Lord of Blood]

So to counter high alphas you are allowing higher alphas but making them spread damage out rather than shut down your mech?

I'm just going to dislike the idea for not quite fixing the problem awhile also adding in non pinpoint damages.

[DjPush]

Sooo... pinpoint accuracy if you only fire one or two at a time but a hot mess if you alpha?

[Troutmonkey]

DjPush, on 09 February 2016 - 06:36 AM, said:

Sooo... pinpoint accuracy if you only fire one or two at a time but a hot mess if you alpha?

Pretty much the idea. The total amount by which fire spreads is a number which can be fine tuned to be greater or smaller. This video shows a fairly extreme amount of spread

Dakota1000, on 09 February 2016 - 06:31 AM, said:

So to counter high alphas you are allowing higher alphas but making them spread damage out rather than shut down your mech?

I'm just going to dislike the idea for not quite fixing the problem awhile also adding in non pinpoint damages.

Heat is still a balancing factor in weapons, but Ghost Heat won't need to be a thing anymore. It was brought in to counter 4/6 ERPPC Stalkers, which aren't scary at all if you know that most of their shots aren't going to all hit the same component should they decide to alpha. Not only that but they still run hot without ghost heat.

Edited by Troutmonkey, 09 February 2016 - 06:42 AM.

[Tarogato]

Reduce the size of the cone by about 35% (maybe 40%) and that's similar to what I'd like to see in MWO. OR---- alternative, have the spread be determined by your rangefinder. So that you get the same spread on the same size target regardless of your distance from it.

Then take a cone about 10% of that size and apply it to movement (the faster you go, closer to 10% of your already demonstrated spread)

[TexAce]

Thanks a lot for making that video and demo!

Dakota1000, on 09 February 2016 - 06:31 AM, said:

So to counter high alphas you are allowing higher alphas but making them spread damage out rather than shut down your mech?

I'm just going to dislike the idea for not quite fixing the problem awhile also adding in non pinpoint damages.

Who is saying the mech is not shutting down when your heat exceeds? Its nowhere stated like that. People these days....

[Ratpoison]

An interesting idea, however it seems likely to me that PGI probably wouldn't find the daunting amount of work to complete it acceptable. Adding in an entirely new stat is hard enough, but that on top of adding necessary components to the UI, coding in all the new mechanics, and the extensive public testing it would require? That's a pretty serious amount of resources and labor that PGI would likely rather put toward the new engine. Perhaps if you simplified it, but as is there is just too much work required.

[process]

Not sold on the idea, but nice demonstration!

[Quaamik]

It is too much coding and testing, especially when there are simpler ways already in game to limit the high pinpoint alphas.

Weapon charge up (see Gause)
Projectile velocity (true, gave us laser vomit, but fixed most of the rest)
Ghost heat

[TexAce]

Quaamik, on 09 February 2016 - 08:09 AM, said:

It is too much coding and testing, especially when there are simpler ways already in game to limit the high pinpoint alphas.

Weapon charge up (see Gause)
Projectile velocity (true, gave us laser vomit, but fixed most of the rest)
Ghost heat

This would eliminate ghost heat nearly completely

And Trout coded this in a day.....just saying.

[nehebkau]

@ OP

With any solution you HAVE to consider the ease or difficulty of coding the system into the current environment! I can't remember how many times users have come to me after a brain-storming session and given me a list of requirements and I have had to say "Sure we can do it but the current budget is too small." and they ask "how much more?" and I have to say "At least 10 times the current budget if we can stretch out the delivery date by a year or so."

I don't think PGIs environment could handle it both development wise or system-wise.

Edited by nehebkau, 09 February 2016 - 08:17 AM.

[TexAce]

tortuousGoddess, on 09 February 2016 - 07:05 AM, said:

An interesting idea, however it seems likely to me that PGI probably wouldn't find the daunting amount of work to complete it acceptable. Adding in an entirely new stat is hard enough, but that on top of adding necessary components to the UI, coding in all the new mechanics, and the extensive public testing it would require? That's a pretty serious amount of resources and labor that PGI would likely rather put toward the new engine. Perhaps if you simplified it, but as is there is just too much work required.

As said above, Trout did this in a day....so much for huge amount of coding

Edited by TexAce, 09 February 2016 - 08:13 AM.

[Lostdragon]

I would like to see something like this added with an accuracy stat for each weapon. Accuracy indicates the weapon's COF size. This would allow another method for tuning weapon balance and also add a lot of depth to mech design/weapon choice. It could also add a lot of depth and meaningful choices to the skill trees by having the option to take a skill that increases accuracy with a specific weapon or weapon type. PGI needs to setup the skill trees so they involve choices like this instead of just filling out everything. They could easily pay for the effort and generate ongoing revenue by charging MC for skill tree resets.

[TexAce]

Love it how someone finally posts a video of a working CoF as Bill intended and all the complainers can say now is "it takes too much time to code"

Seriously guys you are starting to crack me up. You are running out of arguments.

Edited by TexAce, 09 February 2016 - 08:15 AM.

[Ratpoison]

TexAce, on 09 February 2016 - 08:12 AM, said:

This would eliminate ghost heat nearly completely

And Trout coded this in a day.....just saying.

Comparing that to the work it would take to implement the idea into MWO makes absolutely no sense.

[TexAce]

tortuousGoddess, on 09 February 2016 - 08:15 AM, said:

Comparing that to the work it would take to implement the idea into MWO makes absolutely no sense.

Are you a PGI empleyee?

No? Well then...you know where the door is.

[Lostdragon]

tortuousGoddess, on 09 February 2016 - 08:15 AM, said:

Comparing that to the work it would take to implement the idea into MWO makes absolutely no sense.

You are making a lot of assumptions about how difficult it would be. Of course, PGI can't figure out how to do ammo switching, so it would likely be rather difficult for them.

[Mechteric]

Honestly we really need to see the heat system get a revamp before moving on to trying things like this.

I'm talking lower heat cap, higher dissipation, and most importantly, start to actually have penalties for being above 50% heat or so.

Edited by CapperDeluxe, 09 February 2016 - 08:21 AM.

[Matthew Ace]

Good job OP.

Personally, I would love to see a very subtle COF in action, implemented in such a manner that:

• The spread I have in mind, is at worst, such that it is still possible to obtain pinpoint damage where you want it on the biggest mech by default, but you will have to aim dead-center of that particular component. (Challenge lies in 'Mech Geometry bias and foreseenable complaint of hit-reg issues especially when hitting small targets.). Perhaps couple the size of COF with number of weapons fired, or requiring players to lock targets to ensure better precision on smaller targets.Perhaps the size of the COF is also made even smaller for ballistics to make up for lead time and trajectory drop.
  
• The spread is based on the weapon's maximum optimal range, further adding strategic values to a loadout beyond damage falloff when fired beyond optimal range (do I take a bunch of lighter shorter ranged weapon for raw damage or do I take a single heavier long range weapon for precision?). This may also give allowance to tone down certain long range weapons.
  
• The best part is that the base mechanism is a simple XML change to most/all weapons.

Could be interesting if further coupled with the targeting computer load mechanism that's presented in OP.

Edited by Matthew Ace, 09 February 2016 - 08:38 AM.

[Ratpoison]

TexAce, on 09 February 2016 - 08:14 AM, said:

Love it how someone finally posts a video of a working CoF as Bill intended and all the complainers can say now is "it takes too much time to code"

Seriously guys you are starting to crack me up. You are running out of arguments.

Dude...computers aren't magic boxes that just do whatever you tell them. The engines and tools aren't related at all. Just because you can mock up a 3D demo in a day, does not mean that adding such a system to existing code in a different engine will be easy. UI has to be changed and added, entirely new stats added into the existing system, existing code has to be made to play nice with it, and whenever you get something working is when you start testing it and revising the design. For MONTHS. It's a HUGE amount of work to add such a thing to this game.