REsponse to Chrono Jams concernshttp://mwomercs.com/forum ... findpost__p__3287909http://mwomercs.com/forum ... findpost__p__3287909
@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:
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.
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.
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.
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..
We'll have to see here, requires investigation
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...am ... e-networking/
Further reading:http://trac.bookofho...ua ... ke3Networking
(the state delta compression we use in MWO)http://udn.epicgames...ng ... Overview.html
(the simulated and autonomous proxy concepts we're using in MWO)https://developer.va...ay ... er_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:
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.
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 futur