1911 replies to this topic

[Karl Berg]

Rebas Kradd, on 04 May 2014 - 02:52 PM, said:

Karl, I understand the development story of MWO a lot better than I did a month ago. Thanks a million for all this dialogue.

After reading a couple of your Reddit posts, I've got a couple more questions. Can you say more about the "Cryengine layer" that you often reference? It sounds like it accounts for a good 50% of the development delays. When did you guys start building it? Is it finished, or does it require integration for pretty much any in-game feature you build? Does it factor into CW? Where does it play its biggest role - stability, performance, front end, HSR?

Also, you implied that MWO has some kind of "no-crunch" policy, in that you run a very fluid feature pipeline rather than set a deadline in stone and then rush the dev team to meet it. This avoids the personnel burnout so common to dev houses, but I imagine it also leaves the community rather frustrated in that features get moved around a ton and people rarely know what's coming next and when, and where their favorite features vanished to (collisions, MASC, etc.). Is that a fair statement? Rather broadly asking, how often does stuff get moved around? What stuff ARE you willing to crunch on (F&F build? CW?) What decides the pecking order on the pipeline?

Hey Rebas,

Without extra context, it sounds like I might be talking about the engine itself. It's fair to say that bugs and other unexpected behaviours in the engine have cost us several months of development time.

Indeed PGI has implemented a no-crunch policy for MWO. Specific individuals and teams have, on many occasions, chosen to ignore that policy to hit specific deadlines. For example, the UI engineers were putting in weekends for the last month or two prior to UI 2 being shipped. The systems team had a similar push during the first 6 months of the project in order to hit friends and family.

Features can be moved or re-prioritized due to many factors. This includes feasibility, technical risk, and available resources among other reasons. Collisions and MASC were both back-burnered due to technical implementation issues.

[Karl Berg]

Heffay, on 04 May 2014 - 03:22 PM, said:

Dear Mr Berg,

Has Crytek been in any discussion with PGI about taking some of the netcode and merging it back into their basic engine? By default it's all client side, and I figure they would probably like a nice juicy server side netcode base to work from.

Have you had any chats with CIG (the guys making Star Citizen)? They seem to be running into a lot of issues with Cryengine as well.

Love,
Heffay

Hey Heffay,

We haven't provided an engine patch to CryTek. We used to take a much more active role in their developer support forums, and on occasion we would post code solutions for engine bugs we encountered there. Generally we found their support turnaround time was so long as to be not useful, as we would frequently wait weeks or months for a single response.

I have been contacted by other studios on occasion for specific issues that we've encountered. As an example, SOE contacted me for additional details regarding the CryScaleform and STLPort interactions that resulted in our HUD bugs. I am unaware of any contact with the Star Citizen team specifically though.

Mawai, on 05 May 2014 - 06:44 AM, said:

Hi Karl,

Since it has been about 3 weeks, I was wondering if you'd received a response or clarification on whether "Launches" were solo or if a group counted as one launch in Paul's command chair statistics. If you aren't allowed to answer ... that's fine ... please just say so and we can drop it. There are very few statistics available about the game but it would be nice if the data that was available was at least unambiguous

Thanks again

Mawai

Nothing yet Mawai, sorry

[Rebas Kradd]

I'm also curious...what is the breakdown of the engineering folks? Who's on the UI/systems/gameplay teams? Is that the division of it?

[Rasc4l]

Hi Karl,

quick technical question about a possible targeting feature:

Couldn't clan targeting computers work so, that next to the crosshair there is another moving crosshair in front of a target, which is running, showing where to hit. This guiding reticle data would come easily from HSR data, right?

[Osric Lancaster]

Per -
http://mwomercs.com/...ost__p__3293363
and
http://mwomercs.com/...ost__p__3277936

I'm not terribly familiar with cry engine so I have to ask :
Can you have multiple matches running simultaneous on a single 'instance' of a map with interactions between players (collisions / weapons fire) 'transparent' to other drops in that instance? Say, you have twenty people playing private one-on-one matches in caustic valley, so they get pushed to your 'Caustic Valley Server' which holds only it's one instance of caustic's collision mesh, using that to resolve terrain collisions for all concurrent matches while hit reg and player collisions are only resolved between players in the same drop. Is that possible?

Spoiler

I am loving this thread by the way. Makes my head swim, but in a good way.

Edited by Osric Lancaster, 06 May 2014 - 05:20 PM.

[GalaxyBluestar]

great to see the superthread carrying on strongly and not just falling to a whimoper after a while.

this might turn into a backendslayers fanmail inbox before too long.

[Drogue SIgn]

Hi Karl,

The first thing i wanted to say is a massive thank you for taking the time to answer peoples questions, your contact ALONE has encouraged me to purchase an additional 30,000MC (yes the special helped, but with the bugs in the last few releases, and the fact i have about 10 mates who play, but group sizing still an issue.......).

Anyway, once again, thank you keep up the great work

-Dave

[Kmieciu]

Hi Karl,

Could you share with us the recent distribution of players among different mech weight classes?
For example, during the last week, what % of players dropped in a light, medium, heavy and assault mech?

Because the majority of matches I'm in, I see a huge heavy and assault bias. I just wonder if that's because of my particular Elo bracket, or is it a common trend?

Edited by Kmieciu, 06 May 2014 - 10:49 PM.

[Edustaja]

Hi Karl,

You mentioned the bugs with the Scaleform - Cryengine layer interaction.

When the Planetside 2 team was doing their optimization pass on their game they noticed that the Scaleform hud was a major CPU cycle sink. They did optimization on their hud assets and the problems mostly went away.

In MWO the Hud also seems to be CPU intensive. The only way for us players to verify this is of course turning off the Hud by pressing RShift+F11. I have noticed a considerable change in fps when I turn the HUD off during a regular match or in the Training grounds. This change is usually around 60-100% or 10-30 fps.

Do you have any other metrics on this behavior?
Do you think that optimizing the HUD might reasonably mitigate the CPU load or is the Scaleform implementation been already optimized as far as MWO goes?

For me the MWO client fps is mostly CPU restricted so anything that lowers that load would help.

[Modo44]

The HUD and other slowdowns (e.g. with heat vision) are rig-specific. Both together eat under 5 fps on my old hardware (Core i5 2500, Radeon HD 6950). It seems like various hardware acceleration functions are not used (or present) consistently.

[East Indy]

Karl: 3/3/3/3. Is the concept still valid, and just experienced technical difficulties on 4/29?

[shellashock]

Modo44, on 07 May 2014 - 12:42 AM, said:

The HUD and other slowdowns (e.g. with heat vision) are rig-specific. Both together eat under 5 fps on my old hardware (Core i5 2500, Radeon HD 6950). It seems like various hardware acceleration functions are not used (or present) consistently.

I never had any performance gain when I turned off the HUD for my Intel HD Graphics 1000, but turning it off while using my R7 240 card will easily gain 10-20 fps. Does anyone know if Nvidia cards suffer the same problem? I mean, MW:O is supposed to be optimized for Nvidia.

[DEMAX51]

I have a GTX 570, and I notice improvements when I turn my HUD off - FPS goes from 45-55 up to 65+

[Mawai]

shellashock, on 08 May 2014 - 06:20 AM, said:

I never had any performance gain when I turned off the HUD for my Intel HD Graphics 1000, but turning it off while using my R7 240 card will easily gain 10-20 fps. Does anyone know if Nvidia cards suffer the same problem? I mean, MW:O is supposed to be optimized for Nvidia.

Even this game trying to run on Intel integrated graphics would be GPU limited ... reducing CPU load wouldn't make much difference. If I understand the comments earlier in the thread it is the reduction of CPU usage resulting from turning off the HUD that increases the frame rate ... MWO is CPU limited and not GPU limited in many cases.

This is also why the game often ran much better on quad core processors rather than dual or single core ones.

[BARBAR0SSA]

Karl Berg, on 06 May 2014 - 08:45 AM, said:

This is a bug. Essentially, at this time, the order in which you equip weapons determines the visual outcome, but that order is not persisted right now. This means, in-game, the order the game falls back on is the sort order the game retrieved equipped inventory in, which is sorted by primary key. That primary key for player inventory is a specially constructed hash with a few special properties. One of those properties is that it monotonically increases for given single player. This effectively makes the equip ordering fall back to inventory purchase order once you leave the mechlab.

The gameplay team has the bug, and is investigating options for resolving this. We've provided them some space for saving extra metadata about equipped inventory.

Couldn't we get something on the hud that says

LT, RT, RA,LA,CT telling us where the weapons are at least, would make grouping way more easy.

[TheCaptainJZ]

shad0w4life, on 08 May 2014 - 07:23 AM, said:

Couldn't we get something on the hud that says

LT, RT, RA,LA,CT telling us where the weapons are at least, would make grouping way more easy.

They are, at least, listed in order from head > right > center > left i think

[Karl Berg]

Rebas Kradd, on 06 May 2014 - 04:20 PM, said:

I'm also curious...what is the breakdown of the engineering folks? Who's on the UI/systems/gameplay teams? Is that the division of it?

It's a bit fluid right now due to highly limited resources and wildly different workloads. The gameplay team mostly doubles as UI team as needed, and the system team doubles as additional gameplay programmers. That said there are 3 systems engineers, 3 gameplay, and 2 UI.

Not in that list are a build / integration engineer, a tools programmer, a senior rendering engineer, a full time DBA, and two web programmers.

[Karl Berg]

Rasc4l, on 06 May 2014 - 04:41 PM, said:

Hi Karl,

quick technical question about a possible targeting feature:

Couldn't clan targeting computers work so, that next to the crosshair there is another moving crosshair in front of a target, which is running, showing where to hit. This guiding reticle data would come easily from HSR data, right?

Something like this might be possible under very limited circumstances, but is complicated by the fact that mechs carry multiple weapons with varying projectile speeds. Each weapon would need it's own target lead, as the various projectile speeds result in different intercept calculation results. This would be unrelated to HSR however, as HSR is compensating for your network latency on the server.

Drogue SIgn, on 06 May 2014 - 09:02 PM, said:

Hi Karl,

The first thing i wanted to say is a massive thank you for taking the time to answer peoples questions, your contact ALONE has encouraged me to purchase an additional 30,000MC (yes the special helped, but with the bugs in the last few releases, and the fact i have about 10 mates who play, but group sizing still an issue.......).

Anyway, once again, thank you keep up the great work

-Dave

Thanks!

Kmieciu, on 06 May 2014 - 10:48 PM, said:

Hi Karl,

Could you share with us the recent distribution of players among different mech weight classes?
For example, during the last week, what % of players dropped in a light, medium, heavy and assault mech?

Because the majority of matches I'm in, I see a huge heavy and assault bias. I just wonder if that's because of my particular Elo bracket, or is it a common trend?

Sure thing. I'll grab the most recent breakdown when I get back to the office tomorrow morning.

[Karl Berg]

Edustaja, on 07 May 2014 - 12:34 AM, said:

Hi Karl,

You mentioned the bugs with the Scaleform - Cryengine layer interaction.

When the Planetside 2 team was doing their optimization pass on their game they noticed that the Scaleform hud was a major CPU cycle sink. They did optimization on their hud assets and the problems mostly went away.

Indeed, we've seen much the same. Large numbers of draw-calls and the actionscript interpreter are both major drains on the CPU. We've done cut-down passes on the HUD to speed things up a bit, but that hasn't taken us as far as we want.

Things are a bit difficult for us here for a couple reasons. The battle grid and mech targeting overlays are both fairly intensive UI components compared to other in-game HUDs. CryEngine also integrates a customized version of Scaleform 3, which CryTek won't share the source for. Because they won't share the specific changes they've made to the library, we're unable to duplicate those changes within Scaleform 4 to integrate it with the engine. Scaleform 4 includes actionscript 3 support, and draw-call batching, both of which we suspect will bring a big improvement to HUD and front-end performance. We're considering dropping the Cryscaleform wrapper completely, and just doing our own Scaleform 4 integration from scratch; but this is obviously a very large amount of work to commit to. So we'll have to see..

[Karl Berg]

East Indy, on 07 May 2014 - 01:58 PM, said:

Karl: 3/3/3/3. Is the concept still valid, and just experienced technical difficulties on 4/29?

Yes, still valid. The technical issues basically stem from non-linear performance characteristics with respect to the number of players in the matchmaking queue. We were forced to reboot the matchmaker live, which resulted in that blip where previously logged in players were losing the join-game events, and newly logged in players were noticing large numbers of 'disconnected' players in games. That bug has been fixed by the way If we ever need to reboot the matchmaker live again, this particular bug will not happen again.

We are examining our options for getting 3's back onto production as quickly as we can.