1911 replies to this topic

[Mawai]

In the interest of clarity ... I have another question (thank you for the reply to my previous one ... I can now drop the subject of the launch module until I see how it works out ).

Statistics: Everyone loves statistics.

In Paul's post about the number of solo and group players he said that 84% of launches are solo and 16% are groups. Is a launch a single player? Or is a "launch" a single request to the matchmaker such that a group represents one launch since they have to be kept together through the matchmaking process? If launches are all individual players then the number of folks in groups is quite small. If launches are matchmaker requests and groups are considered one launch then the number of folks dropping in groups is more like 33% of the player base.

In my experience, there seems to be significantly more than 16% of players dropping in groups. Often matches seem to have one or more groups on both teams (this can vary a lot by time of day as well). The 33% figure would more closely fit my personal experience so I just wanted to know what the definition of "launch" was in Paul's statistics.

[East Indy]

Karl Berg, on 14 April 2014 - 07:38 PM, said:

Yup, we're well aware; but thanks for raising your concerns. Absolute worst case scenario, we've built in the ability to toggle the 3/3/3/3 ruleset on/off. We will definitely be monitoring the launch of 3/3/3/3 very closely to ensure the impact on wait times is minimal.

Any interest in offering players a secondary weight class choice if they prefer shorter queues? Or queue-length estimates to help players gauge what's in demand and what's gridlocked?

[Aym]

Chronojam, on 12 April 2014 - 12:47 AM, said:

Your efforts in getting us the response are incredibly welcome. A few eyebrow-raisers in there, particularly about the teamplay aspects being potentially bound by certain agreements, but I hope that all works out.

About ghost heat, balance, SRM/LRMs, etc: One of the issues with ghost heat is that it helped discourage build diversity and felt more like a temporary punishment than a real fix. Ideally, you'd want all equipment to feel viable, without fear that a long range mech will always core you before your own weapons ever become effective. Some tweaks to mech health might have even helped figure that balance out, but it didn't seem to really ever be on the table. On that note, test events that help discover the impact of hypothetical new balance changes would be really cool, the test server seems a little underutilized beyond stress/sanity checks. And maybe help avoid "Wait, why did they do that?" reactions come patch-day.

Anyhow, thanks again for all the info you've brought forward in this thread.

(The apology for missed deadlines and such was really cool, too)

This reminds me of many discussions we've had internally in our Marik community regarding time-to-kill and mech durability. Many others have suggested and supported modifying internal structure based on the area of the mech, and maybe again based on tonnage, and I've supported that as well, but perhaps getting rid of the damage-transfer reduction from destroyed components and simply proportionally increase the armor and IS of the more critical sections, CT and LT/RT. I believe that would go some of the way to buff DOT and splash style weapons relative to pinpoint burst while maintaining weapon flavor.

[Kraven Kor]

Aym, on 15 April 2014 - 08:54 AM, said:

This reminds me of many discussions we've had internally in our Marik community regarding time-to-kill and mech durability. Many others have suggested and supported modifying internal structure based on the area of the mech, and maybe again based on tonnage, and I've supported that as well, but perhaps getting rid of the damage-transfer reduction from destroyed components and simply proportionally increase the armor and IS of the more critical sections, CT and LT/RT. I believe that would go some of the way to buff DOT and splash style weapons relative to pinpoint burst while maintaining weapon flavor.

I think it would also increase the frequency and impact of having weapons, armor, or equipment destroyed before your mech finally says "@#$% this" and shuts down for good.

[Cimarb]

Aym, on 15 April 2014 - 08:54 AM, said:

This reminds me of many discussions we've had internally in our Marik community regarding time-to-kill and mech durability. Many others have suggested and supported modifying internal structure based on the area of the mech, and maybe again based on tonnage, and I've supported that as well, but perhaps getting rid of the damage-transfer reduction from destroyed components and simply proportionally increase the armor and IS of the more critical sections, CT and LT/RT. I believe that would go some of the way to buff DOT and splash style weapons relative to pinpoint burst while maintaining weapon flavor.

I'm not looking to get into a debate, honestly, but increasing torso IS would not "buff DOT and splash style weapons". In fact, it would make them even worse, because they do a fraction of the pinpoint damage that front-loaded damage (FLD) weapons do. The more the damage is spread, the less effective that damage would be against increased structure/armor.

Kraven Kor, on 15 April 2014 - 10:25 AM, said:

I think it would also increase the frequency and impact of having weapons, armor, or equipment destroyed before your mech finally says "@#$% this" and shuts down for good.

It would make criticals more important, that is true, but FLD will still be more dominant than any other damage delivery system because there is more damage being done to that one section at one time.

[Chronojam]

Kraven Kor, on 15 April 2014 - 10:25 AM, said:

I think it would also increase the frequency and impact of having weapons, armor, or equipment destroyed before your mech finally says "@#$% this" and shuts down for good.

That had been on my mind for a long while. I hope you don't mind if I quote something from an August 2013 Ask The Devs:

Quote

Question from Chronojam: Are there any plans to increase internal health to capture that stubborn resilience we're told mechs have, to capture the feel of wrangling a giant war machine as various weapons and support systems shut down over time, to diminish the impact of the high-alpha long-range dominance over short range builds, to reduce the odds of a lucky snap-shot or bad maneuver insta-killing lighter mechs, and ultimately to increase time to kill so we feel we're playing a mech sim where strategy and maneuvers (plus a commander's quick decision-making) matter more?

Answer from Paul: We currently have the ability to do this on a global scale (i.e. all Mechs are affected by the same multiplier.) However, it wouldn’t be pertinent to set this number yet as we are still waiting on HSR improvements. Depending on the amount of time HSR fixes will require, we MAY bump IS health by a small percentage to hold us over until the majority of HSR issues are dealt with. We are going to be looking at this on 2 levels. We need to make sure we don’t end up with a bunch of Mechs running around with no weapons/ammo and we need to make sure we don’t make the armor destruction time shorter than the IS destruction time.

It would not be unreasonable to consider a mech without weapons mission-killed for purposes of establishing a victor, of course. Since there is/was a global multiplier, that could be something interesting to try out on a test server weekend.

[DEN_Ninja]

Chronojam, on 15 April 2014 - 12:47 PM, said:

That had been on my mind for a long while. I hope you don't mind if I quote something from an August 2013 Ask The Devs:



It would not be unreasonable to consider a mech without weapons mission-killed for purposes of establishing a victor, of course. Since there is/was a global multiplier, that could be something interesting to try out on a test server weekend.

Most of the time I tend to be in disagreement with your views Chrono but I particularly enjoy this idea.

I'd love to see this on the PTR for an isolated study on what IS durability has on gameplay. I am very on the fence about this change and would rather see a first hand account on how it would affect gameplay.

IMO I feel like the PTR should be used in general for certain balance/gameplay changes to see if they are actually viable. Such as the Point SRM change that removes the splash and just does straight up Missile damage to component.

Edited by Tichorius Davion, 15 April 2014 - 01:16 PM.

[9erRed]

Greetings all,

Reference the explosion radius for SRM's (now listed at 0.05Mtrs);

Quote

Why do you even use the explosion code for SRMs? A year ago Paul set the explosion radius to 0.05 meters. Yep. That's 5 centimeters. Why do you waste server resources to simulate explosions with a radius of 5 centimeters? The missile itself is bigger than that.
Why not using ballistic projectile code for SRMs? These are anti-armor missiles designed to punch through armor. If a missile hits a hitbox, it should apply full damage to that hitbox. No fancy equations. Just like LBX, but a lot slower (300 meters/second vs 1100) and with shorter range (270 vs 1620 meters).

From reference these missiles are HEAT (High Explosive Anti Tank) warheads, that create a supersonic chemical jet to burn their way through armour. Todays current HEAT warheads are anywhere from 3 to 5 inch's in diameter for the projectile and the jet they produce is only 1/2 to 1/4 inch diameter, but it will cut through nearly 1.5 metres of some armour.

So having the "in Game" radius set to 0.05 for the size of the missile is inline with that type of warhead, now when we get different warheads that will need to be opened up again. If we get straight HE (High Explosive) it should have a large radius blast but only do surface armour damage, with no chance of any internals. The "Tandem Warhead" for SRM's (introduced during the Clan invasion) was designed to increase the internal damage per missile. The Tandem Charge missiles are larger and heavier than their standard counterparts, so a 'Mech can only carry half as many per ton, at five times the expense of a standard SRM.

Side-note; Technically the Gauss rounds we are using should actually just be punching there way through the surface armour and doing internal destruction. (similar to a very fast Sabot round, which leaves a very small hole on the surface but creates chaos inside)

So, when Paul reduced the blast radius down to almost nothing, he was actually getting close to how this warhead type really works. But they should be doing most of there damage to internals and even damaging the inside back armour where they hit. (again leaving only a small hole on the front armour surface.)

- In Game: Direct fire projectiles transfer all there kinetic energy into the surface of the armour they strike, damaging that material in an attempt to push through it. Most AC type of rounds will crater the armour and require successive hits at that location to actually break through. (most lack the shear energy that a Gauss carries to punch through on a single hit.)
- Game wise, we see a small or medium Mech struck with an AC5/10/20 or even a gauss round and it keeps on moving. This could be explained as the round simply punched completely through the location and went out the other side. If the location was not a critical component, the Mech has a hole through it, and damaged but not killed.
[Real life situation, you can shoot at a lightly armed vehicle with armour piercing rounds all day, unless they strike a critical location it keeps on moving. Hit it once with HEAT or HE and say good bye to it.]
(the AP rounds just go completely through doing little damage)

9erRed

Edited by 9erRed, 15 April 2014 - 04:08 PM.

[Aym]

9erRed, on 15 April 2014 - 03:57 PM, said:

Greetings all,

Reference the explosion radius for SRM's (now listed at 0.05Mtrs);



From reference these missiles are HEAT (High Explosive Anti Tank) warheads, that create a supersonic chemical jet to burn their way through armour. Todays current HEAT warheads are anywhere from 3 to 5 inch's in diameter for the projectile and the jet they produce is only 1/2 to 1/4 inch diameter, but it will cut through nearly 1.5 metres of some armour.

So having the "in Game" radius set to 0.05 for the size of the missile is inline with that type of warhead, now when we get different warheads that will need to be opened up again.

The point of the original question was WHY bother having to code explosion damage, which uses up system resources, when no noticeable affect from said explosions exists. Arguably it was to eventually enlarge the radius to make them splash weapons again, but the team has been unable to find a way to balance that in light of small mech hitboxes (Commandos used to suffer from splash weapons, spiders seemed immune, etc). Once upon a time LRM's were splash weapons as well...

[Dimento Graven]

Another quick question:

On the map splash screen as you're connecting, in the upper left hand corner there's a little upside down guy that occasionally pops up.

What is that?

[Tekadept]

I have a question, in the Backend code is there a Real critical hit system? if it is coded in there somewhere with the current Pinpoint High Damage,Before the "virtual dice" roll to see if a crtical hit happened you are cored before you even notice you lost a weapon due to a critical hit.

[3Xtr3m3]

Epic Thread.
best in a very long time.
A while back i stated the forumites wanted a behind the scenes look into PGI.
Karl is doing one better and showing us what is under the hood.
A lot of what Karl showed was over my head comprehension-wise, but I am cool with that.

Keep it coming.

[Tekadept]

3Xtr3m3, on 15 April 2014 - 05:47 PM, said:

A while back i stated the forumites wanted a behind the scenes look into PGI.

Behind the Scenes.... Good Idea KARL show us a picture of your desk.. DON'T clean it first or it doesn't count hehe

[Killashnikov]

Thanks for this thread! Great communication here.

[Karl Berg]

Gasoline, on 15 April 2014 - 02:21 AM, said:

To be honest... I feels like you could leave the disclaimer out and it would be totally legit.

Those posts below have been raised in an effort to get a response to what PGI's idea of community warfare is at the moment. The pillars of game design have been razed, 3/3/3/3 was invented instead of a rough tonnage match/limiting. Everything seems to lead away from the community warfare that was promised to us on the launch event.

The disclaimer was there because I was poking a bit of fun at Paul, but didn't want it to be taken literally by mistake. I'm not joking about the fail stamp, he actually did that to us for shock value and giggles; but he still took the time to go through all the submitted propositions, offered feedback where he could, and got some of the better ideas into the product backlog.

That's a difficult thing to do. If I had artists and designers submitting ideas for algorithms, class design, or other software interfaces that I was expected to sift through and offer feedback on, I'm not sure I would have handled it so well.

As for commenting on CW design, as you can imagine this is a highly active area within the company right now. I'm going to leave this one for Paul to discuss, as he is definitely the most informed with all aspects of what's going on right now.

Tekadept, on 15 April 2014 - 06:36 PM, said:

Behind the Scenes.... Good Idea KARL show us a picture of your desk.. DON'T clean it first or it doesn't count hehe

Covered in paper, quite unsightly.

[Karl Berg]

Tekadept, on 15 April 2014 - 05:29 PM, said:

I have a question, in the Backend code is there a Real critical hit system? if it is coded in there somewhere with the current Pinpoint High Damage,Before the "virtual dice" roll to see if a crtical hit happened you are cored before you even notice you lost a weapon due to a critical hit.

It's best to talk to Omid or David Bradley about this; but from what I've discussed with them, there is a per-component critical hit table, based on the table-top rules, so that actuators, weapons, heatsinks, ammo, structure slots and anything else equipped all take up the appropriate number of slots. I'm fairly certain there is a dice roll on internal damage both to determine if a crit happened, and also which piece of equipment took the crit.

Dimento Graven, on 15 April 2014 - 04:53 PM, said:

Another quick question:

On the map splash screen as you're connecting, in the upper left hand corner there's a little upside down guy that occasionally pops up.

What is that?

No idea? Is there a screen cap of this anywhere you can link to?

[Karl Berg]

Chronojam, on 15 April 2014 - 12:47 PM, said:

It would not be unreasonable to consider a mech without weapons mission-killed for purposes of establishing a victor, of course. Since there is/was a global multiplier, that could be something interesting to try out on a test server weekend.

Interesting. Again something best brought up with Paul. I'll ping him and see if he has some time to stop by this thread. Obviously, we're still making fixes to HSR. Both with the patch that went out today, and we have another larger change coming on the 29th patch with Launch Module.

[Karl Berg]

Cimarb, on 14 April 2014 - 11:37 AM, said:

Karl, did you happen to see my followup about the AC change and how it would possibly affect game performance (or not)?

My apologies. I've been getting to these pretty late at night, and it's a little difficult to keep up with the volume of posts. I scanned back to find the post you were referring to, and I most certainly remember reading over your post before; with respect to changing the cool down and damage levels on AC weapons.

The impact on game performance is something that would have to be carefully tested, and would also be driven by design because of the obvious impacts on play experience, and the requirements for them to rebalance the modified weapons.

Similarly changing damage levels on AC's would, I assume, be a very tricky change to make.

[Tekadept]

For some reason i had a few thoughts on HSR,and probably just me rambling,and trying to avoid my own work

What length of time is rewind information kept? ie last 10 seconds, last 20 seconds,whole match then archived for future telemetry?

Does the current HSR code only track player positions, a set criteria of objects or does it track the whole world state?

Does HSR also do the calculation of Line of sight for whether a shot can hit because of obstacles or is that done client side? otherwise wouldnt that be hackable to allow shooting through objects? ie I can tell there is a player on the other side of the hill, I hack the client to send a packet showing my laser "hit", then the server HSR does its thing to determine the "actual" hit? or is it more of a player fires and sends calchit(myvector,enemyvector) and the servers checks LOS first, returns false if LOS check fails or HSR determines there was no hit

Tied to this if not already factored in how would HSR work if destructible terrain was to be brought in ie trees etc (dunno if this even planned),wouldn't you have to track the state of each destructible object as well as the players position, to determine, if at the time that object was in the way of the shot.

ramble out

Edited by Tekadept, 15 April 2014 - 10:46 PM.

[Karl Berg]

Tekadept, on 15 April 2014 - 10:46 PM, said:

For some reason i had a few thoughts on HSR,and probably just me rambling,and trying to avoid my own work

What length of time is rewind information kept? ie last 10 seconds, last 20 seconds,whole match then archived for future telemetry?

Does the current HSR code only track player positions, a set criteria of objects or does it track the whole world state?

Does HSR also do the calculation of Line of sight for whether a shot can hit because of obstacles or is that done client side? otherwise wouldnt that be hackable to allow shooting through objects? ie I can tell there is a player on the other side of the hill, I hack the client to send a packet showing my laser "hit", then the server HSR does its thing to determine the "actual" hit? or is it more of a player fires and sends calchit(myvector,enemyvector) and the servers checks LOS first, returns false if LOS check fails or HSR determines there was no hit

Tied to this if not already factored in how would HSR work if destructible terrain was to be brought in ie trees etc (dunno if this even planned),wouldn't you have to track the state of each destructible object as well as the players position, to determine, if at the time that object was in the way of the shot.

ramble out

We keep only half a second, as it's a fairly intensive system, and a larger window starts to degrade performance due to seek costs in the rewind buffer. For a connectionless protocol, this is way beyond the required limits set for PS3 / 360 cert, and this is also why we state HSR only support pings up to 500 ms. For lag spikes beyond 500 ms, the server will simply clamp rewind state at max, so up to half a second in the past.

It tracks rewind state for all rewindable entities, which is a small subset of actual game objects that are network relevant as well as movable. Mechs are obviously included in this set.

HSR is multiphase. It rewinds all rewindable entities, except the shooter, by the shooters ping; and then takes a very high / mid / narrow phase like approach to see what was shot. The mid phase is a continuous (swept) check against the set of rewindable entities, and gives us an accurate time of intersect if anything was actually hit. We can then adjust time to the new TOI and run the narrow check, including static geo and terrain. The client never tells us what they hit except for telemetry purposes. The authoritative determination of 'hit' is only ever done on the server; so it's not possible to say 'I hit that guy behind the wall' with a hacked client.

More approachable reading (valve has a lot of excellent networking articles on this topic, well worth the read):
https://developer.va...nd_Optimization

If we made trees network relevant, and capable of intersecting weapons, we would need to fully network them, yes. That means correct synchronization, authority, lag compensation, and rewinding for hit detection. This quickly scales beyond a servers ability to handle, hence Glenn Fiedlers' work into shared authority systems for networked rigid body simulations. His work was only ever intended for coop games, but it was really neat to see!