1911 replies to this topic

[Tedarin]

Wow! This section of the forum was awesome (just happened to stumble upon it)!

A developer that responds to their fan/customers. No wonder it's in the off topic section!

[Kaptain]

Karl Berg, on 03 April 2014 - 10:17 AM, said:

The problem is this; if a programmer comes along and edits a few lines or functions in a 100,000 line autogenerated C++ file, you've just increased the size of your maintainable code base by those 100,000 lines, which is devastating to productivity. Our solution is a tough-love approach. If a programmer hand-edits an autogenerated file, the next time he builds those changes will be lost.

Thank you for taking the time to converse with us! As someone who has been playing MWO since closed beta I have always wondered why MWO is "haunted" by "ghosts in the machine." That is, bugs that are at some point fixed only to reappear again. Things like: LRMs only targeting center torso, Corruption in Frozen City Textures, Shooting around Terrain causes weapons to hit invisible wall, AMS continues to shoot after mech dies, blown off arms get stuck in the air, hud corruption, memory leaks and so on.

With that said I am confused by your answer so I wanted to ask some direct questions
-Is auto generated code overwriting manual edits responsible for "ghosts in the machine" ?
-If auto generated code overwriting manual edits is responsible for "ghosts in the machine" wouldn't one expect more ghosts as the UI team and Gameplay team adopt auto generated code?
-Is there a system in place to prevent auto generated code from causing ghost to reappear?
-If auto code is not the culprit, can you shed some light on what causes "ghosts in the machine" ?

Edited by Kaptain, 11 April 2014 - 10:42 AM.

[Thorqemada]

Good thread, good informations, good Karl Berg!

[Kaptain]

slide, on 11 April 2014 - 12:29 AM, said:

Again Karl I thankyou. You have done more for PGI's reputation with me in this one thread than has been done by your bosses in 2 years.

x2

[Jman5]

Karl Berg, on 11 April 2014 - 10:00 AM, said:

Sounds like aggressive performance settings or LOD settings that may have been poorly tuned or taken way to far. If you have some good examples, I would be more than happy to pass them on to the engineer responsible for overseeing this.

Thanks for the response. I recorded some videos in low settings to highlight how jarring it can be.

http://www.twitch.tv...ive/b/518966488
Take a look at the terrain and watch as I move closer. You will see a few large rocks appear out of no where. As I move up to them you can see that they are large enough to cover an entire mech. Players would waste a lot of shots shooting at rocks.

http://www.twitch.tv...ive/b/518961529
First I show how these statues in river city appear at only the last second. They can block shots and block you from moving, so I think it's important to make these visible from a longer distance.

Next you can see the giant building in the airport appearing out of thin air. It can be hard to see if there are any other buildings doing that because of all the haze.

Finally, I take a look at how the buildings are drawn at different distances. You can see that it becomes see through in places as you move back. Take note that there is a fire behind one of the buildings that you can see clearly through the many spaces that appear. Generally it's easy to spot mechs through those spaces and you can use it to tell when they're about to pop out. From their perspective it's a solid building.

http://www.twitch.tv...ive/b/518962019
For my next trick, I'm going to make this building disappear! Notice how it's big enough for a small mech to use as cover. From the other side it would look like my jenner is standing out in the open. Players would shoot at the mech and just hit an invisible building instead.

http://www.twitch.tv...ive/b/518960133
This caustic valley and an example of how the terrain morphs right before our eyes. While that might not be game breaking, it's kind of sloppy looking.

Next you will see an atlas that appears to be hovering in mid-air. As we get closer suddenly a new hill snaps into focus. Any mech who was standing behind that bit of the hill would appear completely visible from the other side.

Finally, I go through the center looking at a particular rock. Watch how it morphs and reforms as I approach. Sometimes it reverts back and forth.

[Karl Berg]

@JMan5 thanks! This has been escalated; and the rendering guys are reviewing the video's you've just linked.

[Karl Berg]

Yeah, definitely some weirdness going on there. The statue and building popping in particular looks like something got past both us and QA. We'll look into addressing that as soon as we can. Would you mind telling us what your sys-spec is set to, or any other custom settings you might have, including the FOV you're using? It would help us with repro.

[Jman5]

Karl Berg, on 11 April 2014 - 12:10 PM, said:

Yeah, definitely some weirdness going on there. The statue and building popping in particular looks like something got past both us and QA. We'll look into addressing that as soon as we can. Would you mind telling us what your sys-spec is set to, or any other custom settings you might have, including the FOV you're using? It would help us with repro.

I'm so happy to hear that this is being looked at.

Here are my in-game settings that I used for those videos.



FOV is set to 85 and no other user.cfg edits.

Do you want my full dxdiag?

Edited by Jman5, 11 April 2014 - 12:33 PM.

[Ax2Grind]

Karl Berg, you sir are hitting home run after home run in this thread. I sincerely wish we saw this kind of communication from PGI on a regular basis.

I would also like to thank all of the players responding in this thread. I can't remember the last time I read a thread in the forums and not felt drummed over the head by immature and angry rants. Thanks for engaging in a great conversation.

Let me add my voice to other Founders and ChronoJam by saying that his post is an excellent summary of the issues that have faced many players and groups who were paying, interested fans of the game. While I am still quite active, every point he raised has taken it's toll on our guild. I look forward to your reply.

Beyond the appreciation I also have a question for you. Can you tell us any more info about the investigations and possible fixes to Hit Registration, especially SRMs? I'd love to hear your perspective on this.

[Klappspaten]

Ax2Grind, on 11 April 2014 - 01:25 PM, said:

Beyond the appreciation I also have a question for you. Can you tell us any more info about the investigations and possible fixes to Hit Registration, especially SRMs? I'd love to hear your perspective on this.

Yes, that would be very interesting.
I use SRMs quite a lot and especially against lights and fast mediums they often are only a waste of ammo. Just yesterday I wasted enough ammo to kill two Atlasses on just one Cicada until it got me. 10 or more shots from my LBX and over 200 SRMs should be enough for a 40 ton Mech to fall, even if half of the shots would miss, which they didn´t.
I will try to records something on this during the next few days.

Edited by Klappspaten, 11 April 2014 - 01:51 PM.

[Karl Berg]

Jman5, on 11 April 2014 - 12:32 PM, said:

Do you want my full dxdiag?

Not for now. If we can't manage a repro here with the settings you've already provided us for some reason, I might ask you to email it to me. Thanks!

[Karl Berg]

@Chronojam, sorry for the delay.

Well, I must thank you for not simply posting an image. Your description contains far more than missing features and a poorly thought-out twitter message. You didn't make this easy on me either though . There's so much packed in there, I don't know that I can adequately respond in a single forum post. Here goes:

Communication:

I definitely get this is a point of contention. This is something I feel I can help improve on for some members of the community; and this is the major reason why I'm making a point to spend a couple hours each day to purposefully respond to issues where I think I can shed some additional insight.

I can see people might think communications were being whitewashed, but I've seen no evidence of that myself. We regularly have received tons of negative feedback. At the very least, we all try and read feedback threads on command chair posts. I can only ask for a bit of leniency here myself, as we are dev's. We aren't really the best equipped to allocate extra time towards public communications, or even communicate technical or process issues in a manner that makes sense.

Russ has definitely said some unpopular things on twitter; however I think he's shown himself to be very malleable when his ideas turn out to be unpopular. You can probably tell that he's more brainstorming in public, rather than trying to communicate set-in-stone designs. So it’s best not to stress over it, give him your honest feedback, and he'll try and do right by you.

On official channel failures; people are unfortunately people. They'll have bad days, they'll make mistakes. In many cases the CSR's were powerless to actually address specific issues, and they were forced to apologize and back burner those issues, which was highly frustrating for them. We recently provided some significant new CSR abilities with the server support software for UI 2's release. We've also had to figure out guidelines and best practices along the way.

Missed deadlines:

Definitely our fault. No other way to cut that. We've been subject from everything from major feature slippage, to underestimating scope of work, to process failures that lead to inadequate code getting launched to production, to major challenges with the engine we chose, to significant changes in design after we’ve started development. All of those are things we're actively trying to improve on.

One of the major challenges here is we've had to make a studio-wide transition from retail boxed product development to continuously live online. We need to maintain code, assets, and processes for years now rather than the single year or so it takes to final, ship DLC, and any patches for bugs missed during the gold cert process. This is a mental, process, work ethic, and attitude shift across all teams. That includes gameplay, engine and systems, design, art, production, absolutely everyone is affected by this. There's a lot more accountability in this new environment, definitely a lot more responsibility to the user base, and that is a big adjustment to make.

I personally think we're making real strides here. UI 2 was a huge hurdle; it was a major transition point for us process wise just as much as it was a developmental pipeline stall. I think you'll find a major difference in our ability to hit deadlines with some consistency now. Of course, miscommunications comes into play here. There's always the chance someone lets a date slip without due diligence, and it turns out the date is unrealistic and unattainable. This is something that the whole team has been actively working towards addressing.

Teamplay support:

This is something we’re actively looking at addressing. We need to take some care that we don’t violate any agreements here. Russ is looking into making sure we can make this can happen.

Group play is something that's under highly active consideration. Personally I have significantly more fun playing in a group than solo. My best times in the game were back when we could manage full 8-man drops, even though we got our butts thoroughly kicked nearly every game. We are definitely open to ways to do the right thing here. I'm certainly willing to hear out any ideas you guys have, with the caveat that I'm not design, I can only speak to the technical aspects of any solutions, and I may not have the full picture with respect to future design goals for the project. So basically I can't make any promises that I'd be able to get any suggestions into the game.

Ghost heat:

I can't help here at all. This is 100% in the domain of design. I can definitely tell you the intent is to control abusive mech builds, while trying to not explicitly disallow full customization. Whether it's the best mechanic for this purpose or not, I'm not really qualified to say. I have neither the design and gameplay balance background, nor the play experience with MWO, to do this topic justice.

The specific example with LRM heat profiles sounds like a bug, either in design or implementation. I can't see any reason why 50 LRM's would run cooler than 40. This should be filed as a bug with support.

Aggressive balance changes:

I'm mostly in the dark here too. But as for DHS vs SHS, at least in the little amount of tabletop I played, it wasn't really a question of one being better than the other, it was a way to trade space for tonnage. I could very easily be incorrect here, so feel free to correct me if I am wrong.

And finally that leaves the image. Nice, matches marketings clan package art..

VOIP:

We'll have to see here, requires investigation

Balance:

This is nebulous. To be fair, even if absolutely everyone agreed the game was 100% balanced, we're a moving target, we're going to be constantly releasing new content, new modules, new maps, new mechs, new game modes for community warfare, etc. We'll never be able to attain this for everyone. I think the next image is much more focused, and addressable as a result.

No ghost(s): (heat I assume)

This would require design to have an alternative approach to penalizing specific mech builds that would be just as effective as their current solution. Again, I'm definitely no expert here, so I'm not sure how attainable this is.

LRM/SRM fixes: (hit detection fixes?)

In progress. These are bugs in a highly complex system that we've had to build from scratch in a highly unforgiving engine, that has absolutely no support for modern FPS style asynchronous hit detection as shipped. These bugs are exceptionally difficult to reproduce under controlled circumstances, and require a large amount of dev time by our most senior systems team members to address.

If you're curious at all about the particular challenges and algorithms at all, here are a set of introductory articles I compiled for the reddit thread, when a user asked about the current state of these algorithms:

Introduction (Glen is an excellent author, this is a very approachable introduction):
http://gafferongames...ame-networking/
Further reading:
http://trac.bookofho...uake3Networking (the state delta compression we use in MWO)
http://udn.epicgames...ngOverview.html (the simulated and autonomous proxy concepts we're using in MWO)
https://developer.va...ayer_Networking (lag compensation and HSR)

I have confidence that we'll make significant improvements given a bit more time. For now, the best I can do is to apologize for the negative experiences. We have live telemetry that tracks the accuracy of client <-> server simulations in realtime for every weapon fired in every game. That accuracy is currently in the high 70 to 80th percentile for all weapons currently. We should be able to boost that by a significant amount. We are dealing with the internet though, so we'll never be able to hit 100%. No asynchronous multiplayer game could ever hit 100%, the current state of the art algorithms simply aren't that robust. The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour like this:





Community warfare:

It's coming? This is directly related to the large blurb I wrote on missed deadlines. After UI 2, project management has (wisely) chosen to take a very piecemeal approach to this feature. This way we won't end up blocking the entire production pipeline for several months. The feature might take longer as a whole to complete, but at least there will be a steady trickle of new features while we work on it. UI 2 set up a good chunk of flexibility and framework, since CW is an extremely UI heavy feature. Achievements brought in a lot of currently unexposed title support for faction ranking, and rewards. We rewrote a lot of our backend mechlab/inventory purchase logic for UI 2 as well, not only to allow rewards but also to make conquest benefits easier to implement. The 12-hour downtime brought a significant data migration, one of the largest I've ever seen, to allow robust support for player created factions and association among other things.

DirectX 11:

Released

UI 2.0:

Released

Island:

Released.

So, ultimately I can't undo all the grievances that have made you stop playing. At best I can only apologize. I'm hoping that we've learned enough from the experiences you've been through, and your feedback, to be able to do much better for the community from now on.

And finally, many thanks for taking the time to write everything up. That took a significant amount of time on your part, which certainly shows you care about the future of this game enough to invest that time.

[Klappspaten]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

LRM/SRM fixes: (hit detection fixes?)

In progress. These are bugs in a highly complex system that we've had to build from scratch in a highly unforgiving engine, that has absolutely no support for modern FPS style asynchronous hit detection as shipped. These bugs are exceptionally difficult to reproduce under controlled circumstances, and require a large amount of dev time by our most senior systems team members to address.

If you're curious at all about the particular challenges and algorithms at all, here are a set of introductory articles I compiled for the reddit thread, when a user asked about the current state of these algorithms:

Introduction (Glen is an excellent author, this is a very approachable introduction):
http://gafferongames...ame-networking/
Further reading:
http://trac.bookofho...uake3Networking (the state delta compression we use in MWO)
http://udn.epicgames...ngOverview.html (the simulated and autonomous proxy concepts we're using in MWO)
https://developer.va...ayer_Networking (lag compensation and HSR)

I have confidence that we'll make significant improvements given a bit more time. For now, the best I can do is to apologize for the negative experiences. We have live telemetry that tracks the accuracy of client <-> server simulations in realtime for every weapon fired in every game. That accuracy is currently in the high 70 to 80th percentile for all weapons currently. We should be able to boost that by a significant amount. We are dealing with the internet though, so we'll never be able to hit 100%. No asynchronous multiplayer game could ever hit 100%, the current state of the art algorithms simply aren't that robust. The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour like this:

As I said before I am using a lot of SRMs because they fit very well into my way to play the game.
It is very rare that I encounter issues with the SRM hitreg when shooting at large and slow targets. It happend a few times that I encountered weak hitreg on heavys and assaults, but I can explain those with high latency.

When fighting lights and fast mediums though I encounter those issues not just very often, but all the time.
If you say that your telemetry shows that the accuracy is in the high 70% to 80% area it seems very likely for me that there is a disballance between big, slow moving, and small, fast moving targets. It has been so bad that I almost stopped fighting lights in the mechs I mainly use SRMs on.

Is there any way that your telemetry can show those numbers for different targets seperated?
If you are able to do that it could be a worthwile thing to take a look at more specified data.

[Rebas Kradd]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

I can see people might think communications were being whitewashed, but I've seen no evidence of that myself. We regularly have received tons of negative feedback. At the very least, we all try and read feedback threads on command chair posts. I can only ask for a bit of leniency here myself, as we are dev's. We aren't really the best equipped to allocate extra time towards public communications, or even communicate technical or process issues in a manner that makes sense.

I have to disagree that you're not equipped for this job, Karl. I hate to think of you losing dev time on the game because you're talking to us, but this is amongst the most eloquent and transparent dev threads these forums have ever seen, and you made your company money with it. I'm getting meself an Uller package because I strongly believe in this level of community interaction as a pillar of a good product.

I'll add here for everyone else's benefit, though, that a lot of folks in software development really aren't the eloquent type. Many aren't even the social type. It takes a specific kind of mind to work in that field, and it's often the type that coincides with quiet and introverted. I've heard stories of dev offices at Microsoft where you're expected to stay silent in a room full of devs at their stations, but as soon as you log in, you get bombarded with IMs. So while I believe a company should be forthcoming and transparent, it's not reasonable to expect them ALL to be that way.

Quote

No asynchronous multiplayer game could ever hit 100%, the current state of the art algorithms simply aren't that robust. The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour

This is not the first time I've gleaned that building a server-side authoritative game on an engine intended for client-side work has created some challenges. At my entry-level understanding, it seems a major mismatch. What features/advantages of CryEngine convinced you guys that it was worth the hassle?

Edited by Rebas Kradd, 11 April 2014 - 06:22 PM.

[Kageru Ikazuchi]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

... wow ... one of the best Dev posts to date ...

This needs to be re-posted in the Command Chair with an appropriate thread soliciting feedback. Thank you for taking the time and trouble to increase our awareness and insight into your processes and difficulties. You just earned PGI another two tiers of Clan package from me.

[GalaxyBluestar]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

Spoiler

@Chronojam, sorry for the delay.

Well, I must thank you for not simply posting an image. Your description contains far more than missing features and a poorly thought-out twitter message. You didn't make this easy on me either though . There's so much packed in there, I don't know that I can adequately respond in a single forum post. Here goes:

Communication:

I definitely get this is a point of contention. This is something I feel I can help improve on for some members of the community; and this is the major reason why I'm making a point to spend a couple hours each day to purposefully respond to issues where I think I can shed some additional insight.

I can see people might think communications were being whitewashed, but I've seen no evidence of that myself. We regularly have received tons of negative feedback. At the very least, we all try and read feedback threads on command chair posts. I can only ask for a bit of leniency here myself, as we are dev's. We aren't really the best equipped to allocate extra time towards public communications, or even communicate technical or process issues in a manner that makes sense.

Russ has definitely said some unpopular things on twitter; however I think he's shown himself to be very malleable when his ideas turn out to be unpopular. You can probably tell that he's more brainstorming in public, rather than trying to communicate set-in-stone designs. So it’s best not to stress over it, give him your honest feedback, and he'll try and do right by you.

On official channel failures; people are unfortunately people. They'll have bad days, they'll make mistakes. In many cases the CSR's were powerless to actually address specific issues, and they were forced to apologize and back burner those issues, which was highly frustrating for them. We recently provided some significant new CSR abilities with the server support software for UI 2's release. We've also had to figure out guidelines and best practices along the way.

Missed deadlines:

Definitely our fault. No other way to cut that. We've been subject from everything from major feature slippage, to underestimating scope of work, to process failures that lead to inadequate code getting launched to production, to major challenges with the engine we chose, to significant changes in design after we’ve started development. All of those are things we're actively trying to improve on.

One of the major challenges here is we've had to make a studio-wide transition from retail boxed product development to continuously live online. We need to maintain code, assets, and processes for years now rather than the single year or so it takes to final, ship DLC, and any patches for bugs missed during the gold cert process. This is a mental, process, work ethic, and attitude shift across all teams. That includes gameplay, engine and systems, design, art, production, absolutely everyone is affected by this. There's a lot more accountability in this new environment, definitely a lot more responsibility to the user base, and that is a big adjustment to make.

I personally think we're making real strides here. UI 2 was a huge hurdle; it was a major transition point for us process wise just as much as it was a developmental pipeline stall. I think you'll find a major difference in our ability to hit deadlines with some consistency now. Of course, miscommunications comes into play here. There's always the chance someone lets a date slip without due diligence, and it turns out the date is unrealistic and unattainable. This is something that the whole team has been actively working towards addressing.

Teamplay support:

This is something we’re actively looking at addressing. We need to take some care that we don’t violate any agreements here. Russ is looking into making sure we can make this can happen.

Group play is something that's under highly active consideration. Personally I have significantly more fun playing in a group than solo. My best times in the game were back when we could manage full 8-man drops, even though we got our butts thoroughly kicked nearly every game. We are definitely open to ways to do the right thing here. I'm certainly willing to hear out any ideas you guys have, with the caveat that I'm not design, I can only speak to the technical aspects of any solutions, and I may not have the full picture with respect to future design goals for the project. So basically I can't make any promises that I'd be able to get any suggestions into the game.

Ghost heat:

I can't help here at all. This is 100% in the domain of design. I can definitely tell you the intent is to control abusive mech builds, while trying to not explicitly disallow full customization. Whether it's the best mechanic for this purpose or not, I'm not really qualified to say. I have neither the design and gameplay balance background, nor the play experience with MWO, to do this topic justice.

The specific example with LRM heat profiles sounds like a bug, either in design or implementation. I can't see any reason why 50 LRM's would run cooler than 40. This should be filed as a bug with support.

Aggressive balance changes:

I'm mostly in the dark here too. But as for DHS vs SHS, at least in the little amount of tabletop I played, it wasn't really a question of one being better than the other, it was a way to trade space for tonnage. I could very easily be incorrect here, so feel free to correct me if I am wrong.

And finally that leaves the image. Nice, matches marketings clan package art..

VOIP:

We'll have to see here, requires investigation

Balance:

This is nebulous. To be fair, even if absolutely everyone agreed the game was 100% balanced, we're a moving target, we're going to be constantly releasing new content, new modules, new maps, new mechs, new game modes for community warfare, etc. We'll never be able to attain this for everyone. I think the next image is much more focused, and addressable as a result.

No ghost(s): (heat I assume)

This would require design to have an alternative approach to penalizing specific mech builds that would be just as effective as their current solution. Again, I'm definitely no expert here, so I'm not sure how attainable this is.

LRM/SRM fixes: (hit detection fixes?)

In progress. These are bugs in a highly complex system that we've had to build from scratch in a highly unforgiving engine, that has absolutely no support for modern FPS style asynchronous hit detection as shipped. These bugs are exceptionally difficult to reproduce under controlled circumstances, and require a large amount of dev time by our most senior systems team members to address.

If you're curious at all about the particular challenges and algorithms at all, here are a set of introductory articles I compiled for the reddit thread, when a user asked about the current state of these algorithms:

Introduction (Glen is an excellent author, this is a very approachable introduction):
http://gafferongames...ame-networking/
Further reading:
http://trac.bookofho...uake3Networking (the state delta compression we use in MWO)
http://udn.epicgames...ngOverview.html (the simulated and autonomous proxy concepts we're using in MWO)
https://developer.va...ayer_Networking (lag compensation and HSR)

I have confidence that we'll make significant improvements given a bit more time. For now, the best I can do is to apologize for the negative experiences. We have live telemetry that tracks the accuracy of client <-> server simulations in realtime for every weapon fired in every game. That accuracy is currently in the high 70 to 80th percentile for all weapons currently. We should be able to boost that by a significant amount. We are dealing with the internet though, so we'll never be able to hit 100%. No asynchronous multiplayer game could ever hit 100%, the current state of the art algorithms simply aren't that robust. The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour like this:




Community warfare:

It's coming? This is directly related to the large blurb I wrote on missed deadlines. After UI 2, project management has (wisely) chosen to take a very piecemeal approach to this feature. This way we won't end up blocking the entire production pipeline for several months. The feature might take longer as a whole to complete, but at least there will be a steady trickle of new features while we work on it. UI 2 set up a good chunk of flexibility and framework, since CW is an extremely UI heavy feature. Achievements brought in a lot of currently unexposed title support for faction ranking, and rewards. We rewrote a lot of our backend mechlab/inventory purchase logic for UI 2 as well, not only to allow rewards but also to make conquest benefits easier to implement. The 12-hour downtime brought a significant data migration, one of the largest I've ever seen, to allow robust support for player created factions and association among other things.

DirectX 11:

Released

UI 2.0:

Released

Island:

Released.

So, ultimately I can't undo all the grievances that have made you stop playing. At best I can only apologize. I'm hoping that we've learned enough from the experiences you've been through, and your feedback, to be able to do much better for the community from now on.

And finally, many thanks for taking the time to write everything up. That took a significant amount of time on your part, which certainly shows you care about the future of this game enough to invest that time.

Karl Berg, on 11 April 2014 - 05:34 PM, said:

Aggressive balance changes:

I'm mostly in the dark here too. But as for DHS vs SHS, at least in the little amount of tabletop I played, it wasn't really a question of one being better than the other, it was a way to trade space for tonnage. I could very easily be incorrect here, so feel free to correct me if I am wrong.

may i suggest that the amount of crit slots an engine has for engine heatsinks be brought into line with the philosophy crit slots for tonnage? cause at the moment i can gain 4 DHS in and engine or 4 SHS in an engine for the same expendature in tonnage howevere not only is the DHS cooling better but for the same tonnage "price" i've saved myself 8 critslots on my mech for other weapon/ammo/equipment. that's one of a few reasons why there's a lot of DHS played and little SHS. just things like this need consideration if tonnage vs critslots is the only way to balance SHS usage vs DHS usage.

Edited by GalaxyBluestar, 11 April 2014 - 08:33 PM.

[Homeless Bill]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

Spoiler

@Chronojam, sorry for the delay.

Well, I must thank you for not simply posting an image. Your description contains far more than missing features and a poorly thought-out twitter message. You didn't make this easy on me either though . There's so much packed in there, I don't know that I can adequately respond in a single forum post. Here goes:

Communication:

I definitely get this is a point of contention. This is something I feel I can help improve on for some members of the community; and this is the major reason why I'm making a point to spend a couple hours each day to purposefully respond to issues where I think I can shed some additional insight.

I can see people might think communications were being whitewashed, but I've seen no evidence of that myself. We regularly have received tons of negative feedback. At the very least, we all try and read feedback threads on command chair posts. I can only ask for a bit of leniency here myself, as we are dev's. We aren't really the best equipped to allocate extra time towards public communications, or even communicate technical or process issues in a manner that makes sense.

Russ has definitely said some unpopular things on twitter; however I think he's shown himself to be very malleable when his ideas turn out to be unpopular. You can probably tell that he's more brainstorming in public, rather than trying to communicate set-in-stone designs. So it’s best not to stress over it, give him your honest feedback, and he'll try and do right by you.

On official channel failures; people are unfortunately people. They'll have bad days, they'll make mistakes. In many cases the CSR's were powerless to actually address specific issues, and they were forced to apologize and back burner those issues, which was highly frustrating for them. We recently provided some significant new CSR abilities with the server support software for UI 2's release. We've also had to figure out guidelines and best practices along the way.

Missed deadlines:

Definitely our fault. No other way to cut that. We've been subject from everything from major feature slippage, to underestimating scope of work, to process failures that lead to inadequate code getting launched to production, to major challenges with the engine we chose, to significant changes in design after we’ve started development. All of those are things we're actively trying to improve on.

One of the major challenges here is we've had to make a studio-wide transition from retail boxed product development to continuously live online. We need to maintain code, assets, and processes for years now rather than the single year or so it takes to final, ship DLC, and any patches for bugs missed during the gold cert process. This is a mental, process, work ethic, and attitude shift across all teams. That includes gameplay, engine and systems, design, art, production, absolutely everyone is affected by this. There's a lot more accountability in this new environment, definitely a lot more responsibility to the user base, and that is a big adjustment to make.

I personally think we're making real strides here. UI 2 was a huge hurdle; it was a major transition point for us process wise just as much as it was a developmental pipeline stall. I think you'll find a major difference in our ability to hit deadlines with some consistency now. Of course, miscommunications comes into play here. There's always the chance someone lets a date slip without due diligence, and it turns out the date is unrealistic and unattainable. This is something that the whole team has been actively working towards addressing.

Teamplay support:

This is something we’re actively looking at addressing. We need to take some care that we don’t violate any agreements here. Russ is looking into making sure we can make this can happen.

Group play is something that's under highly active consideration. Personally I have significantly more fun playing in a group than solo. My best times in the game were back when we could manage full 8-man drops, even though we got our butts thoroughly kicked nearly every game. We are definitely open to ways to do the right thing here. I'm certainly willing to hear out any ideas you guys have, with the caveat that I'm not design, I can only speak to the technical aspects of any solutions, and I may not have the full picture with respect to future design goals for the project. So basically I can't make any promises that I'd be able to get any suggestions into the game.

Ghost heat:

I can't help here at all. This is 100% in the domain of design. I can definitely tell you the intent is to control abusive mech builds, while trying to not explicitly disallow full customization. Whether it's the best mechanic for this purpose or not, I'm not really qualified to say. I have neither the design and gameplay balance background, nor the play experience with MWO, to do this topic justice.

The specific example with LRM heat profiles sounds like a bug, either in design or implementation. I can't see any reason why 50 LRM's would run cooler than 40. This should be filed as a bug with support.

Aggressive balance changes:

I'm mostly in the dark here too. But as for DHS vs SHS, at least in the little amount of tabletop I played, it wasn't really a question of one being better than the other, it was a way to trade space for tonnage. I could very easily be incorrect here, so feel free to correct me if I am wrong.

And finally that leaves the image. Nice, matches marketings clan package art..

VOIP:

We'll have to see here, requires investigation

Balance:

This is nebulous. To be fair, even if absolutely everyone agreed the game was 100% balanced, we're a moving target, we're going to be constantly releasing new content, new modules, new maps, new mechs, new game modes for community warfare, etc. We'll never be able to attain this for everyone. I think the next image is much more focused, and addressable as a result.

No ghost(s): (heat I assume)

This would require design to have an alternative approach to penalizing specific mech builds that would be just as effective as their current solution. Again, I'm definitely no expert here, so I'm not sure how attainable this is.

LRM/SRM fixes: (hit detection fixes?)

In progress. These are bugs in a highly complex system that we've had to build from scratch in a highly unforgiving engine, that has absolutely no support for modern FPS style asynchronous hit detection as shipped. These bugs are exceptionally difficult to reproduce under controlled circumstances, and require a large amount of dev time by our most senior systems team members to address.

If you're curious at all about the particular challenges and algorithms at all, here are a set of introductory articles I compiled for the reddit thread, when a user asked about the current state of these algorithms:

Introduction (Glen is an excellent author, this is a very approachable introduction):
http://gafferongames...ame-networking/
Further reading:
http://trac.bookofho...uake3Networking (the state delta compression we use in MWO)
http://udn.epicgames...ngOverview.html (the simulated and autonomous proxy concepts we're using in MWO)
https://developer.va...ayer_Networking (lag compensation and HSR)

I have confidence that we'll make significant improvements given a bit more time. For now, the best I can do is to apologize for the negative experiences. We have live telemetry that tracks the accuracy of client <-> server simulations in realtime for every weapon fired in every game. That accuracy is currently in the high 70 to 80th percentile for all weapons currently. We should be able to boost that by a significant amount. We are dealing with the internet though, so we'll never be able to hit 100%. No asynchronous multiplayer game could ever hit 100%, the current state of the art algorithms simply aren't that robust. The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour like this:




Community warfare:

It's coming? This is directly related to the large blurb I wrote on missed deadlines. After UI 2, project management has (wisely) chosen to take a very piecemeal approach to this feature. This way we won't end up blocking the entire production pipeline for several months. The feature might take longer as a whole to complete, but at least there will be a steady trickle of new features while we work on it. UI 2 set up a good chunk of flexibility and framework, since CW is an extremely UI heavy feature. Achievements brought in a lot of currently unexposed title support for faction ranking, and rewards. We rewrote a lot of our backend mechlab/inventory purchase logic for UI 2 as well, not only to allow rewards but also to make conquest benefits easier to implement. The 12-hour downtime brought a significant data migration, one of the largest I've ever seen, to allow robust support for player created factions and association among other things.

DirectX 11:

Released

UI 2.0:

Released

Island:

Released.

So, ultimately I can't undo all the grievances that have made you stop playing. At best I can only apologize. I'm hoping that we've learned enough from the experiences you've been through, and your feedback, to be able to do much better for the community from now on.

And finally, many thanks for taking the time to write everything up. That took a significant amount of time on your part, which certainly shows you care about the future of this game enough to invest that time.

I would like to personally thank you for this post. That's some serious no-bullshit perspective right there.

Edited by Homeless Bill, 11 April 2014 - 08:35 PM.

[East Indy]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

Ghost heat:

I can't help here at all. This is 100% in the domain of design. I can definitely tell you the intent is to control abusive mech builds, while trying to not explicitly disallow full customization. Whether it's the best mechanic for this purpose or not, I'm not really qualified to say. I have neither the design and gameplay balance background, nor the play experience with MWO, to do this topic justice.

This is a topic many players have trouble being objective, or in some cases, intellectually honest about. Perceptions are also colored by play circles (high-end, 12-man organized) that are unrepresentative of the majority player base. Simply put, there were beneficial extinction events.

In conjunction with stiffer overheating penalties, heat scale succeeded in discouraging the most extreme builds last spring/summer, especially those with PPCs. Three subsequent changes (Gauss charge, AC/10 velocity nerf, AC/20 velocity nerf) marginalized the first and second set of "fallback" builds. In early January min-max players settled on 30ish-point pinpoint/poptart builds, and gameplay over the last three months has remained under varying degrees of influence from them.

At this point, a fair number of players are wondering about design's opinions on the central cause, and whether rules against, as you put it, "abusive 'Mech builds" will be modified to more directly address the root — and, as a result, both marginalize the last, current meta while preparing for both Clan weapons and future loadout combinations carrying far more potential for instant, pinpoint damage.

Certainly, asking for developer rationale is sometimes a gambit players use to prolong appeals, or even manipulate developers into accepting demands. And a lot of players have poisoned the well with irresponsible behavior. And, on a technical note, lighter teams in public matches will apply some limits to the extent of current meta.

But although solutions are hotly debated, "the problem" with balance is something players generally agree on. I think players want (maybe need?) to hear more specificity on the subject, even if developers see it differently. There's a difference between acknowledging a claim before rejecting it on very precise terms, and responding in generalities, or not much at all. It goes both ways, too, since the game suffers when players' accusations go unchallenged.

Blizzard, especially lately, has done very well with Chadd "Celestalon" Nervig and Ion "Watcher" Hazzikostas engaging directly with players and discussing issues while at the same time pointing out just how wrongheaded or mistaken some protests can be.

What you have here is very helpful, and your colleagues should follow suit.

[ArmyOfWon]

Karl, I must say that this thread is, bar none, the absolute best communication from anyone at PGI I've ever seen. Period. (And I've been around for almost 2 years!)

That said, could you please, please pass on chronojam's criticism of ghost heat and balance to Paul. Could you also please see if you can get him to explain how the design team arrives at their balance decisions with the game. PPC+Heavy Ballistic Poptarts have been dominant in the meta since the Highlander dropped (a year ago!!), and they decide to nerf light ballistics dps? What? Please ask Paul to explain exactly how they came to that decision.

[repete]

Karl Berg, on 11 April 2014 - 05:34 PM, said:

Russ has definitely said some unpopular things on twitter...give him your honest feedback, and he'll try and do right

Actually, speaking from experience, and based on others, he's just as likely to block you. I still have ZERO idea why Russ or Bryan blocked me.

Karl Berg, on 11 April 2014 - 05:34 PM, said:

The only way to hit 100% would be to cheat, take the easy way out, go back to Cry's client authoritative solution, and leave ourselves wide open to abusive behaviour like this:

[video]

That was probably one of the funny-saddest things I've ever seen

Edited by repete, 11 April 2014 - 10:44 PM.