1911 replies to this topic

[Karl Berg]

Modo44, on 29 April 2014 - 01:17 AM, said:

Karl, the product may change and have a lot of nuances, but the basics remain the same for long periods of time. Due to the complexity, many new people have this reaction. Threads like that pop up almost every day. Very basic game info is not directly provided nor quick-linked in the client, and often out of date on PGI's own Training Grounds (all old UI videos).

Your first link is broken Modo.. You are correct in noting that the front end videos in the training grounds section are still for UI 1.5. I'm out of the loop here, so I don't know if there are any plans to update the mechlab videos to UI 2 in the near term.

[Modo44]

Link fixed. Basically, new players often come to the forums completely lost. The one tutorial covers a small percentage of what happens in the match, and nothing of what happens in the mechlab.

[Alymbic]

Karl Berg, on 29 April 2014 - 01:18 AM, said:

I've also made an account, PGIkberg. Looks like there may be editing restrictions in place however.

Doesn't seem to be any problems here so far. I'm going light -> assault, I've updated the locust varients (adding the new ones and updating engine caps), updated raven engine caps and in the process of adding the firestarters. Pretty straightforward so far. I'll leave the depth of the pages for later, I'm just creating/updating pages with raw stats.

Edited by Alymbic, 29 April 2014 - 01:51 AM.

[Kageru Ikazuchi]

Karl Berg, on 29 April 2014 - 12:47 AM, said:

Just curious, but what level of documentation are you looking for. Are you looking for the basics? 'Here are the default key bindings', 'This is how you purchase a mech', 'This is how you unlock a mech efficiency'; or are you looking for detailed technical info on how the product works?

This would be a good start, followed by basic guidelines about how to operate a 'mech, how the various weapon types and other equipment work, how to outfit and upgrade a 'mech, etc.

I did get one of my friends to play last year, but due to time zone differences, I was unable to be there to coach him through the basics ... his comment to me was "I had no idea why I was getting killed or what I was doing wrong" ... and that's from a guy who I know has been playing video games in one form or another for thirty years. (I haven't really made the effort to learn more, especially when I heard that there was a series of tutorials in the works).

What I would really like is about 20 pages of a "getting started" guide that I can print out and hand to people. I considered writing one myself (and still may) around when U.I. 2.0 was announced ... I've still got an outline around here somewhere ...

[Tekadept]

Karl Berg, on 29 April 2014 - 12:47 AM, said:

Just curious, but what level of documentation are you looking for. Are you looking for the basics? 'Here are the default key bindings', 'This is how you purchase a mech', 'This is how you unlock a mech efficiency'; or are you looking for detailed technical info on how the product works?

Hi Karl, Yes I do have an understanding of documentation both Internal and External level.

Yes things do constantly change and I fully appreciate that, and yes there are code changes and the game is evolving every 2 weeks but the CORE Gameplay doesnt change every 2 weeks really what im talking about not much has changed at all tbh, yet people are still unsure of some of the mechanics work. The frequency based in the past on core gameplay changes is VERY manageable for user documentation.The beauty of the age we live in document can be updated quite easily and often as products to change, its a far cry from the good ole days where you had a printed manual and that was it.

Of course I am not after detailed technical info, that is just a silly thing and not what a new user would expect. You say throwing up internal documents is not acceptable as a end user manual? of course its not, but having NO USER MANUAL is not acceptable either.

Of course you need default key bindings that's simple stupid level, but you need to go beyond that and go through the mechanics, ie simple examples. What I expect as a consumer is a middle ground that is in most games manuals / official wiki pages.

Go over weapons, explain recycle times, explain heat is generated and needs to be dissipated over time.
next level is explanation of how firing weapons generates heats, ballistics run cooler but require ammo.
Cover overriding and shutdowns
Cover how AMS works
Go over weapon groupings, cycle fire etc.
Go over minimum ranges etc.
Explain ghost heat (Good luck with that one)
Standing in water increases heat dissipation.
Go over damage, external armour colour vs internal, Explain how many internal points you have.
Explain criticals, ie Gauss rifles can explode, ammo can explode.
Ultra AC Jamming Mechanic
The CASE Mechanic, how it is pointless to have with an XL engine.
Losing a Leg slows you down
General Jump jet usage, Jump jets only recharge when on the ground
Capturing bases is only possible when on the ground (I am unsure of this been a while since i played)

The list could go on, The amount of times i see on forums people questioning game mechanics and people say it does this, people say it doesn't, there is nowhere definitively to say THIS happens. Or if there is you have to troll through old command chair posts or random forum posts.

Look at MW3 Manual below, not so much for content(obviously comparing apples and donkeys) but you get the general gist of a manual layout covering different aspects of systems etc.
http://www.replaceme...d.php?view.4782

Something like that would be a bloody good start. Yes things change and it needs to grow, but if properly set out, and so long as gameplay changes are documented correctly internally, it is not a big thing to change external documentation. A good example is the coming of the clans, Change to UAC for Clans, XL engine Changes etc etc that would be amended as they are released.

Karl Berg, on 29 April 2014 - 01:18 AM, said:

I've also made an account, PGIkberg. Looks like there may be editing restrictions in place however.

Perhaps a "semi oficial" PGI MWO Wiki would be a good idea, have kyle whip one up have it so the community can edit it as you wish, but then a PGI representative can go through and make the final definitive cut on whether something is true or not and it is cited as such.

Edited by Tekadept, 29 April 2014 - 05:05 AM.

[Vlad Ward]

The vast majority of the topics listed in the above post already have Dev or Engineer authored explanations somewhere on the forums, sometimes multiple times. The big issues are twofold:

A) Finding them
and
Player-driven Wikis actually sourcing them

On a smaller scale, you have additional problems resulting from:

C) Player-driven Wikis competing with each other and splitting community resources (dat ad revenue)
and
D) The fact that no one, no where can force no body to read the available documentation before bitching on the forums.

My beef regarding documentation is as much with players as it is with anyone else. Actual links to Primary Source Documents are few and far between. Unfortunately, in some cases (like CB patch notes), PSD is nearly impossible to find because the only records remaining from that time period are in the email inboxes of people involved in the Closed Beta. The various reincarnations of the forums haven't exactly helped when it comes to tracking down these PSDs either.

[Cimarb]

Karl Berg, on 29 April 2014 - 12:47 AM, said:

Just curious, but what level of documentation are you looking for. Are you looking for the basics? 'Here are the default key bindings', 'This is how you purchase a mech', 'This is how you unlock a mech efficiency'; or are you looking for detailed technical info on how the product works?

Given your background working on commercial software systems, you will have a good understanding of how much time and effort goes into writing up accurate and readable documentation, as well as maintaining that documentation as you extend and maintain your product. The effort is certainly non-trivial; and inaccurate documentation is arguably much worse than no documentation, so the maintenance costs of detailed documentation are high.

In our case, the product changes every 2 weeks. We have roughly 1 million lines of server code, and probably closer to 2 million lines of code in the client. We most certainly do have internal documentation, both of our codebases and of the design; but throwing up dozens of 50+ page documents intended for engineering, full of bullet points for specific behaviours and edge cases, as well as wireframes for intended presentation, is by no means acceptable as an end-user manual.

I can only speak from my own perspective, but I think the best start would be basic overviews of "how things work". For instance, how does the heat scale, ghost heat and ambient map temperature, work? How do armor, internal structure, and criticals all work together to give a mech it's "health"? What do each of the pilot /mech skills actually do (or not do)?

It doesn't have to be a 50+ page document to answer each of these questions, but it should allow someone to determine more detailed answers from it. For instance, Smurfy gives all of the weapon statistics, and our stats page gives more numbers - combine those and you can get detailed answers to other questions, such as effective damage, damage per match, etc. Same with the wiki: it should give the basic information that we can then use to generate more specific information ourselves. For instance, if we know how the heat scale, ghost heat and ambient map temperature work, we could then figure out how they all work together on a certain loadout.

These are all examples and I'm sure the information is out there to find right now - we just need it all consolidated and verified somewhere that new players (and veterans) can find it.

[DEN_Ninja]

Karl can you shed some light on how HSR/Hit detection, the speed cap, and MASC are related?

I was wondering why there is an imposed Speed Cap and if it has to do with HSR not being able to handle it. Also if there is any progress in getting MASC to work if it is an issue with HSR.

[IronChance]

I agree that some kind of official user manual is needed.

Karl, I sympathize with the amount of documentation and work you are saying would have to go into creating a user manual, but for any game this is stuff that HAS to be done. It never should have been considered optional or an after thought. MWO is conspicuous among games for not having any real documentation.

Since the character of this game is both free-to-play online and ever-evolving, I would suggest as good first step just keeping the FAQ section updated ad organized correctly. I've found some useful info there, but there needs to be much more. Threads could be titled like so:

GAMEPLAY: What is a critical hit?
MECHLAB: Where are my modules?
UI: What do the colors on my mech's paper doll mean?

... and each thread would give an answer crafted around the designer's intention for how a system should work, NOT the actual numbers involved and edge cases (since those are the evolving parts). I think this would help all players learn how the game should work and provide more useful feedback (hopefully).

I know this isn't your area, so thanks for listening and thinking about it anyway.

[Kraven Kor]

Karl Berg, on 29 April 2014 - 01:30 AM, said:

Your first link is broken Modo.. You are correct in noting that the front end videos in the training grounds section are still for UI 1.5. I'm out of the loop here, so I don't know if there are any plans to update the mechlab videos to UI 2 in the near term.

If there are no plans to do this, then someone needs to make said plans and prioritize them.

The disconnect between your website and the client, the deafening sound of silence that is the game manual, training videos, and information available online speak volumes to the development of this game.

I'm not trying to :post angry: or anything. I want to see this succeed. I don't want to bad-mouth PGI. At the same time, it is hard to advocate for this game with the many, many glaring problems and the glacial rate of development.

[Modo44]

Information structure based on the above ideas, and keeping in mind limited resources. In order of priority:

• Start with a big, visible, static help icon in the client to link directly to the FAQ table of contents from any place in the client, including when "Searching".
  
• Fix the icon to link to relevant FAQ segments depending on where you are. (Changing camos? The help icon sends you to the camo FAQ part.)
  
• Expand FAQ segments to link to guides/wikis with more in-depth information relevant to the questions.
  
• Continuously expand the FAQ to cover all main features as they come online. The lag here should be as minimal as possible.
  
• Continuously answer detailed community questions to help community members with keeping their guides/wikis up to date. (This would be a special thread with strict "no bullshit/venting" rules.)
  
• Provide guides/wiki authors a PGI icon to display, marking the ones that contain officially approved information.

"FAQ" above can also mean the Training Grounds when it makes more sense to just show a video. But that, again, requires the Training Grounds to be up to date with minimal lag.

Edited by Modo44, 29 April 2014 - 10:45 AM.

[Jman5]

Hey Karl, one of the concerns many people have with the UI is the number of layers you have to go through to perform a useful task. A good example is when I want to launch a game I need to click play now, then click public, then click game mode, and then finally it starts searching. Every time. Now you guys get around some of the grief by saving the settings from before so I dont have to re-select game modes, but I still have to click 3 or 4 times every time I want to launch a match.

Are all these drop-down, pop ups simply placeholders or are these going to permanent aspects of the new UI? A much better system would have one settings menu where you select what game modes you desire. This allows the players to just hit the launch button once and immediately start searching. I would bet that if you looked at the metrics you would see most of the player base choosing the same settings over and over. This should be a 1-click and go operation.

I'm not sure if you are involved with the UI 2.0 design, but if you could pass this along I would be grateful.

[Moriquendi86]

Hi Karl, you have given us great insight on MWO development process which is wonderful and I'd like to thank you for that.

I'd also want to ask about something that interest me personally. I know that maintaining couple branches of code can be time consuming and often hated by developers task but it's also necessary evil. So I'm curious how many branches you have to maintain for development with 2 week path cycle and how much of your/other coders/QA time is taken away by that from developing new features? Also if this is not a big secret could you give us rough idea on a pipeline you use to create every path and how far ahead is development from version that is currently live?

Edited by Moriquendi86, 30 April 2014 - 10:18 AM.

[Not Bob]

Hello Mr. Berg,

First, I want to say you are fantastic! I know I speak for alot of people when I say, "Thank you for taking your time to talk with us!"

Now, I got a question that you could possibly shed some light on: Map making/ design. I would like to know what the team has to deal with when making a good quality map, and what challenges could occur. I've seen a few people talk about map design, but I realize that I don't know that much. I was hoping you could shed some light on this rather dark area. (If you got time that is, we know you're very busy! )

[Davers]

Hi Karl,

Someone pointed out that the impulse of SRM4s is set less than SRM2 and SRM6. Is this an oversight or are SRM4s supposed to have less 'knockaround' for some reason?

[Karl Berg]

Modo44, on 29 April 2014 - 10:40 AM, said:

Information structure based on the above ideas, and keeping in mind limited resources. In order of priority:

• Start with a big, visible, static help icon in the client to link directly to the FAQ table of contents from any place in the client, including when "Searching".
• Fix the icon to link to relevant FAQ segments depending on where you are. (Changing camos? The help icon sends you to the camo FAQ part.)
• Expand FAQ segments to link to guides/wikis with more in-depth information relevant to the questions.
• Continuously expand the FAQ to cover all main features as they come online. The lag here should be as minimal as possible.
• Continuously answer detailed community questions to help community members with keeping their guides/wikis up to date. (This would be a special thread with strict "no bullshit/venting" rules.)
• Provide guides/wiki authors a PGI icon to display, marking the ones that contain officially approved information.

"FAQ" above can also mean the Training Grounds when it makes more sense to just show a video. But that, again, requires the Training Grounds to be up to date with minimal lag.

I gotcha; so the concerns are over transitioning players from the very basic introductory level, to moderate familiarity with the game? Particularly mechlab, battlegrid, potentially consumables.. At first glance, the points you list here seem quite reasonable. I'm minimally involved with UI, and not at all involved with the training grounds work, but I will certainly see what I can do to raise visibility on these issues.

From the retention analytics I would expect most effort to be put into the very initial intro tutorials, since after a very few games played, player retention skyrockets. In fact, new user experience has been one of the core concerns repeatedly raised within the office for a very long time now. The data certainly implies that once a player has the very basics of gameplay down, they are motivated to seek out additional sources of information; although I'm not trying to ignore or discount any anecdotal evidence or personal experiences on this topic.

[Modo44]

Ideally, both first contact and deep game information should be available. I think these bleed into each other in many cases, and both can be vastly improved. For example, the weapon range display in matches (black/yellow/green weapon names) is a great learning help for new players not familiar with weapons, but even veterans do not notice it for a long time -- simply because of limited information.

The choice of focus here is hard to judge from a veteran's perspective. In case of new player help, you might need to ask actual noobies. Different aspects of the game appear (non)obvious to different people.

[Karl Berg]

Tichorius Davion, on 29 April 2014 - 06:34 AM, said:

Karl can you shed some light on how HSR/Hit detection, the speed cap, and MASC are related?

I was wondering why there is an imposed Speed Cap and if it has to do with HSR not being able to handle it. Also if there is any progress in getting MASC to work if it is an issue with HSR.

At the most basic level, ping * speed represents an error bubble between anything you see on your screen, what the server thinks world state is, and what all the other clients think the world state is. Increasing speed increases the size of that bubble, which can impact error.

Going way back, we had problems with high speeds and rubberbanding in our movement code. Even today, there are still theoretical speed caps for smooth movement under our supported latency levels. I'm reasonably certain that those caps are well over what would be required for masc, but this would require specific testing under a large variety of network conditions. So, as it stands, my highest concerns would be with weapon accuracy. I would want solid numbers on the new theoretical accelerations and top speeds of the affected mechs. I would want QA to run extensive tests under varying levels of packet loss, constant latency, varying latency, etc..

[Karl Berg]

Moriquendi86, on 30 April 2014 - 04:17 AM, said:

Hi Karl, you have given us great insight on MWO development process which is wonderful and I'd like to thank you for that. I'd also want to ask about something that interest me personally. I know that maintaining couple branches of code can be time consuming and often hated by developers task but it's also necessary evil. So I'm curious how many branches you have to maintain for development with 2 week path cycle and how much of your/other coders/QA time is taken away by that from developing new features? Also if this is not a big secret could you give us rough idea on a pipeline you use to create every path and how far ahead is development from version that is currently live?

The number of branches for any given 2 week cycle can change dramatically, but typically involves at least a couple asset branches as well as anywhere from one to say a half dozen code branches. Integration can be a huge drain, this is true; but this can be mitigated with good integration processes (prior to test locking trunk, integrating trunk into feature branch, getting QA signoff, integrating fully tested branch back to trunk merge free, and unlocking trunk).

Because of this, the person cost varies dramatically, but can range from well under a day of person time, to potentially weeks of integration time in the case of engine drops.

Not Bob, on 30 April 2014 - 04:45 PM, said:

Hello Mr. Berg, First, I want to say you are fantastic! I know I speak for alot of people when I say, "Thank you for taking your time to talk with us!" Now, I got a question that you could possibly shed some light on: Map making/ design. I would like to know what the team has to deal with when making a good quality map, and what challenges could occur. I've seen a few people talk about map design, but I realize that I don't know that much. I was hoping you could shed some light on this rather dark area. (If you got time that is, we know you're very busy! )

Hah I know less about art process than I do about design. Let me try and get an expert to pop in and answer that for you.

Davers, on 01 May 2014 - 07:20 AM, said:

Hi Karl,

Someone pointed out that the impulse of SRM4s is set less than SRM2 and SRM6. Is this an oversight or are SRM4s supposed to have less 'knockaround' for some reason?

I'm not certain. I'd need Paul to answer whether or not this is intentional.

[Dennis de Koning]

Not Bob, on 30 April 2014 - 04:45 PM, said:

Hello Mr. Berg,

First, I want to say you are fantastic! I know I speak for alot of people when I say, "Thank you for taking your time to talk with us!"

Now, I got a question that you could possibly shed some light on: Map making/ design. I would like to know what the team has to deal with when making a good quality map, and what challenges could occur. I've seen a few people talk about map design, but I realize that I don't know that much. I was hoping you could shed some light on this rather dark area. (If you got time that is, we know you're very busy! )

This may give you a little insight:
http://penny-arcade....am-creates-worl
An article I compiled for Penny Arcade about a half year ago or so.