1911 replies to this topic

[Cimarb]

Karl Berg, on 25 April 2014 - 12:59 AM, said:

Yes indeed, the explosion queue fix will affect multiple weapons. Lasers and other trace-fires will not be affected though.

Ok, since this directly ties into what is most important to me, and the info Paul stated about the Clan weapons being burst-fire, can you talk more about the burst-fire "overload" on the system you mentioned a while back? For reference:

Karl Berg, on 13 April 2014 - 09:20 AM, said:

I'm not an expert on the weapons systems, but I think this might be a bit troublesome. Alex is also hugely supportive of this model for AC's, as it's actually much closer to lore.

Here's the gotchas: The highly rapid-fire weapons, like machine guns, act as trace-fire weapons similar to lasers. The AC's all simulate with somewhat more physical accuracy, they spawn an actual projectile which has velocity, simulates over time, is affected by gravity, etc..

So while we could shoot off a pile of rapid-fire projectiles, that would have knock-ons that would require additional investigation at the very least. Increases in network traffic, increases in processing time and collision detection costs. Or, we might consider turning AC's into trace-fire at the cost of simulation fidelity. The shells would then fire with effective infinite velocity, no longer have gravity falloff, etc.. That's not necessarily a tradeoff we would like to make.

Essentially, what are the technical/server issues related to making autocannons burst-fire as far as amount of rounds (and explosions as a result) being fired down range?

Have there been any discussions about making this the norm for IS weapons as well (i.e. Is this a test run?) and if so, are there any sort of technical limitations involved in making manufacturer variants of weapons to allow us to finally mount a ChemJet AC20 or Pontiac 100 AC20 as our playstyles prefer? (See the link in my signature for more details on that)

[Heffay]

Karl,

You mentioned that there is a business analyst team that does a lot of work with the data you collect. I know a lot of the information you collect is proprietary and closely guarded, but is there any way they can release some carefully massaged data, much like when they did the infographic a while back?

I love seeing stuff like that, as do a number of others. Info porn goes great with mech porn!

[Cade Windstalker]

Karl Berg, on 25 April 2014 - 12:56 AM, said:

As to the iteration processes we're taking part with design, it's only been positive for us so far. The process is pretty much as I described earlier in this thread. Design puts together a formal document on some specific feature, detailing how they would like the feature to work. They submit the document to us, and we point out areas where further clarification is required, inconsistent or contradictory behaviours, portions that might have high technical risk, etc. On occasion we point out ways that we might reduce implementation costs by making small tweaks to the design. The design team writes down all our feedback and incorporates it into a second revision. They then submit that second revision for review. This process repeats until we all agree that the feature is ready for implementation.

So, I'm going to ask a *very* thorny question here and hope you'll take on the challenge with ghusto. What was the design process like for Heat Scaling? There were a lot of competing ideas for how to make high-alpha weapons less optimal. I've looked at some of these and some seemed feasible but would have other negative effects and some just make the Software Engineer and Game Designer in me cringe at the scale of the required implementation.

I know this is going to run into the NDA like a crashing fighter-jet with all the resultant firey explosions but could you give us some insight into the process that lead to Heat Scaling being addopted over other proposed ideas, specifically relating to the process you outlined above with Design and Engineering bouncing feedback between each other?

[Contra420]

I just cam here to post a thank you.
Thanks Karl Berg For actually answering some real concerns of the community in an honest and straight forward manner, We need more developers like you in this business, Keep it up man.

Edited by Contra420, 25 April 2014 - 09:21 AM.

[DEN_Ninja]

For any Dev, can you clarify if whether or not there will be the Missile Pod components for when clans arrive? This really applies to any mech with the extended boxes.

We've seen the screenshots of the HUD bugs that show the paper doll missile pods but is there actual functionality for it? Are there circumstances preventing this feature?

Spoiler

[Heffay]

Dear Mr Berg,

There is an interesting conversation going on in another game forum about whether server performance can affect your client performance. The specific claim is that because someone is going from 80 FPS in Crysis 3 to 20 FPS in MWO, it's a sign that the game servers can't handle the load. The argument then goes that because the tickrate on the game servers is so low, that it's affecting the clients so they don't render the FPS they are capable of.

I, of course, claim hooey. Inadequate server capacity will cause issues with rubber banding, but not client FPS. My question is: Is there a tickrate for the MWO game servers, and does their argument that it is causing a reduction in their FPS hold water?

Edited by Heffay, 25 April 2014 - 04:48 PM.

[Wintersdark]

Heffay, on 25 April 2014 - 04:45 PM, said:

Dear Mr Berg,

There is an interesting conversation going on in another game forum about whether server performance can affect your client performance. The specific claim is that because someone is going from 80 FPS in Crysis 3 to 20 FPS in MWO, it's a sign that the game servers can't handle the load. The argument then goes that because the tickrate on the game servers is so low, that it's affecting the clients so they don't render the FPS they are capable of.

I, of course, claim hooey. Inadequate server capacity will cause issues with rubber banding, but not client FPS. My question is: Is there a tickrate for the MWO game servers, and does their argument that it is causing a reduction in their FPS hold water?

Also claiming hooey.

I'd be unsurprised to see people with much lower FPS in MWO, but that's due to how CPU bound MWO is.

Performance in other Cryengine games will not reflect performance in MWO. MWO's CryEngine implementation is very heavily modified.

[Tekadept]

Nikolai Lubkiewicz, on 25 April 2014 - 09:46 AM, said:

Editors Note: Fox handles more the development and bug fixing side of the page. Otherwise, it is updated about once a month by Bryan Ekman. We would love to keep this to a regular set schedule but fluctuating needs and events may mean flexibility is needed. That said, I'll try to keep a reminder going to have this in mind around the same time next month.

Simpler solution..... Just take a picture of the scrum board every sprint

Edited by Tekadept, 26 April 2014 - 04:19 AM.

[Wintersdark]

Karl, I'm curious if you can share a bit of data with us.

There's a constant thread in matchmaker discussions, something that keeps cropping up. As has been stated a few times in official posts, relative team Elo ratings have a very small delta in the majority of drops. The question then is, what is the average Elo delta within a team (given average matches, as we can obviously assume outliers will always exist)?

Players feel if they do well, and climb to higher Elo rankings, it becomes ever more likely that the matchmaker will slot in lower-Elo players to bring the team Elo rating down to match the opposing team.

And, as a further question:

However this currently works, when we move to the next MM system (the Three Buckets system), will people in each bucket ONLY play with and against (with being an important part of the question) people in the same bucket? Or will the Matchmaker still stretch it's bounds and include players from other buckets when necessary?

[Wintersdark]

And, one other followup:

Are the Three Buckets a split of thirds of Elo ranking, or thirds of player pool? I mean, assuming Elo rankings of 0-2800, will the buckets be: (roughly) 0-933 / 934-1867 / 1868-2800, or the highest 1/3rd of online players, middile 1/3, and lowest 1/3?

In the former system, the high and low Elo buckets would then have very small player pools, while the middle bucket would be chock full of players. In the later, each bucket would have the same sized player pool, but with a larger Elo spread in the High and Low buckets as the player-Elo curve shows the vast majority of players have very middle-of-the-road Elo rankings.

[Heffay]

Wintersdark, on 26 April 2014 - 08:15 AM, said:

And, one other followup:

Are the Three Buckets a split of thirds of Elo ranking, or thirds of player pool? I mean, assuming Elo rankings of 0-2800, will the buckets be: (roughly) 0-933 / 934-1867 / 1868-2800, or the highest 1/3rd of online players, middile 1/3, and lowest 1/3?

In the former system, the high and low Elo buckets would then have very small player pools, while the middle bucket would be chock full of players. In the later, each bucket would have the same sized player pool, but with a larger Elo spread in the High and Low buckets as the player-Elo curve shows the vast majority of players have very middle-of-the-road Elo rankings.

This was posted earlier, and the buckets were supposed to be 0-1000, 1000-1500, and 1500+. My guess is that the sizes correspond roughly to 1/3 of the overall population.

[Davers]

While the buckets are nice, I hope that doesn't replace matching Elo as best as possible. Even a 200 point difference in scores is a huge disparity (a 200 point advantage gives a 76% chance of victory).

[Karl Berg]

Kmieciu, on 25 April 2014 - 03:46 AM, said:

Karl, please take a look at this post - it's about the matchmaker:

http://mwomercs.com/...ost__p__3228282

Hi Kmieciu, Mawai actually posted earlier in this thread on this topic.

DarkonFullPower, on 25 April 2014 - 04:01 AM, said:

If Karl can answer this question for me, it will put to rest the only major worry I've had for this game since closed beta.

Where do Hardcore Lone Wolf players fit in Community Warfare?

HI Darkon,

Unfortunately this topic heavily touches on future design, which hasn't been fully announced by the design team yet. When Paul is given the green light, I'm sure there will be some very information rich command chair posts on this topic.

[Karl Berg]

EGG, on 25 April 2014 - 04:49 AM, said:

Hi Karl

I'd assume there's been manual data-mining of match stats to find optimal mechs / builds / weapons for the balance fixes we see come through. But I was wondering if there had been any movement towards hooking these stats back into other systems?

It would be interesting if the matchmaker were able to take into account the "match efficiency" of the Awesome(or specifically the AWS-8Q, or even a specific build), rather than just it's weight and class.

Cheers

Not in this manner, nope. Putting feedback loops into highly complex systems can result in very unpredictable behaviour. Our current approach is to solve imbalance issues with explicit design, which is where Paul and others would look at the analytics you mention to assist in their decisions. Instead, I would ask Paul to provide us a weighting table per variant based off those analytics, and we would hook it up in a manner that allows easy adjustment. Since player skill is a hidden state problem, we're forced into using an adaptive system here to solve for this; but I would worry about testability, reproducibility, stability, accuracy, whether the systems would be prone to oscillations or convergence, and a host of other factors, by attempting to automate a telemetry driven system. It's certainly a cool idea though! Sounds like an excellent research problem.

Nikolai Lubkiewicz, on 25 April 2014 - 09:46 AM, said:

Editors Note: Fox handles more the development and bug fixing side of the page. Otherwise, it is updated about once a month by Bryan Ekman. We would love to keep this to a regular set schedule but fluctuating needs and events may mean flexibility is needed. That said, I'll try to keep a reminder going to have this in mind around the same time next month.

Yup, Fox mentioned the same when I followed up with him Friday. Thanks for the clarification Niko!

[slide]

Hi Karl I see that you are on as I type, I hope I can catch you.

Time to kill (TTK) has been a hot topic for a while now, with various solutions including increasing IS hit points and burst fire AC's

I was wondering if a simpler solution was possible, this was my thinking.

Some stats would help here but it seems to me that most of my deaths are due to engine destruction through the CT, even when running XL engines. Currently engine health I believe is 15 points. If this were to be increased to say 50 points (it stands to reason a fusion reactor would be heavily shielded) then TTK would be greatly increased without changing any other fundamentals about the mech. I think you would take more crits to other systems (HS, weapons etc) before dying.

This would increase TTK (no more one shots) and also increase the immersion factor by having your mech fall apart around you more. As an added immersion and balancing factor, as your engine take more damage you can suffer other set backs like reduced speed, higher heat etc.

Just a thought, maybe you can pass it on to Paul/design.

Edited by slide, 27 April 2014 - 04:12 PM.

[Karl Berg]

Heffay, on 25 April 2014 - 04:45 PM, said:

Dear Mr Berg,

There is an interesting conversation going on in another game forum about whether server performance can affect your client performance. The specific claim is that because someone is going from 80 FPS in Crysis 3 to 20 FPS in MWO, it's a sign that the game servers can't handle the load. The argument then goes that because the tickrate on the game servers is so low, that it's affecting the clients so they don't render the FPS they are capable of.

I, of course, claim hooey. Inadequate server capacity will cause issues with rubber banding, but not client FPS. My question is: Is there a tickrate for the MWO game servers, and does their argument that it is causing a reduction in their FPS hold water?

The server most certainly could affect client performance, although we have suitable guards in place to ensure that the impact is minimal. Flooding a client with expensive network traffic would be one way a server could impact client performance for example.

The claim that a slow server tick rate results in a slow client tick rate is certainly false however. We've done a lot of work to allow client and server simulations to run at independent frequencies. In fact, the 'network relevant' simulation for movement runs at a fixed frequency of 20 hz, although this is completely invisible to players due to the client side game simulation that runs overtop. Servers actually run much faster than 20 hz to reduce the latency of certain network operations. Clients can run at any frequency they are capable of. From our telemetry, that typically ranges from 15 hz for some users, to hundreds of frames per second for others.

[Karl Berg]

Wintersdark, on 26 April 2014 - 08:09 AM, said:

Karl, I'm curious if you can share a bit of data with us.

There's a constant thread in matchmaker discussions, something that keeps cropping up. As has been stated a few times in official posts, relative team Elo ratings have a very small delta in the majority of drops. The question then is, what is the average Elo delta within a team (given average matches, as we can obviously assume outliers will always exist)?

Players feel if they do well, and climb to higher Elo rankings, it becomes ever more likely that the matchmaker will slot in lower-Elo players to bring the team Elo rating down to match the opposing team.

And, as a further question:

However this currently works, when we move to the next MM system (the Three Buckets system), will people in each bucket ONLY play with and against (with being an important part of the question) people in the same bucket? Or will the Matchmaker still stretch it's bounds and include players from other buckets when necessary?

I would need to run some fairly specific analytics before I could factually answer this; so I'm not going to give out any hard numbers at this time.

What you say certainly makes sense; this is even expected behaviour for the current system under specific conditions. We currently need to worry about weight class delta, skill rating delta, game mode, public or 12-man, and wait times. The matchmaker is reasonably strict about which skill-ratings it will consider initially, so if there is a good population of high-Elo players, the matchmaker would group them together first. Over time, it will degrade those tolerances in an attempt to get you into the game rather than waiting. We can't improve on everything at once unfortunately. Any tightening of weight class has to come at the cost of skill or wait times. Any tightening of skill rating would have to come at the cost of weight class or wait times, etc.

3/3/3/3 is going to alter the current queuing dynamics considerably. Once we have some solid data post 29th, we'll certainly be taking a very close look at what those impacts were, including what the impact on Elo was. Elo variance within a team is a good metric to look at.

The bucket system, as proposed by design, was strict. It would not allow players to cross buckets under any circumstance.

[Karl Berg]

Wintersdark, on 26 April 2014 - 08:15 AM, said:

And, one other followup:

Are the Three Buckets a split of thirds of Elo ranking, or thirds of player pool? I mean, assuming Elo rankings of 0-2800, will the buckets be: (roughly) 0-933 / 934-1867 / 1868-2800, or the highest 1/3rd of online players, middile 1/3, and lowest 1/3?

In the former system, the high and low Elo buckets would then have very small player pools, while the middle bucket would be chock full of players. In the later, each bucket would have the same sized player pool, but with a larger Elo spread in the High and Low buckets as the player-Elo curve shows the vast majority of players have very middle-of-the-road Elo rankings.

Paul proposed those Elo ranges to us for the bucket solution. You would need to ask him how he arrived at those numbers. This Elo bucket system hasn't gone through any solid technical review yet, so unfortunately I don't have a lot of answers here yet.

[Karl Berg]

slide, on 27 April 2014 - 04:09 PM, said:

Hi Karl I see that you are on as I type, I hope I can catch you.

Time to kill (TTK) has been a hot topic for a while now, with various solutions including increasing IS hit points and burst fire AC's

I was wondering if a simpler solution was possible, this was my thinking.

Some stats would help here but it seems to me that most of my deaths are due to engine destruction through the CT, even when running XL engines. Currently engine health I believe is 15 points. If this were to be increased to say 50 points (it stands to reason a fusion reactor would be heavily shielded) then TTK would be greatly increased without changing any other fundamentals about the mech. I think you would take more crits to other systems (HS, weapons etc) before dying.

This would increase TTK (no more one shots) and also increase the immersion factor by having your mech fall apart around you more. As an added immersion and balancing factor, as your engine take more damage you can suffer other set backs like reduced speed, higher heat etc.

Just a thought, maybe you can pass it on to Paul/design.

Indeed, I can bring this up with Paul. This is 100% in his domain though, so that's the best I can do.

[ICEFANG13]

Karl Berg, on 27 April 2014 - 04:37 PM, said:

Indeed, I can bring this up with Paul. This is 100% in his domain though, so that's the best I can do.

Unless something changed since I played a lot more often, you cannot die from engine crits, only from actually losing the part of the body.