[WAR] Q&A with C&C Developer Nate Levy

Posted: August 30, 2010 in WAR

In the developer world, you have a wide range of problems to solve.  Some are black and white, such as “My client crashes when I hit the X button” and others are a bit more subjective such as “My God, my Marauder sucks a trailer hitch.”  I’m not envious of those who have to tackle the latter issue, as there are so many variables going around, including the Human Factor which can change on a whim.

One of the guys at Bioware Mythic fighting the good fight in such a fuzzy battle is Nate Levy.  I’m sure everyone knows Nate.  He’s done a few Q&As on Vent recently.  Nate was nice enough to sit down an answer a few question I had about general Combat and Career balancing.  It’s tough to get a good answer to specific questions, such as “Hey, why does my Marauder suck so much” or “Hey, that WH killed me.  Why?” so I kept things broad.  Take a read below to see his responses.

Time to Kill (TtK) overall seems a bit too fast. People die a bit too…quickly.  Is something in motion to help draw out the length of fights, or at least keep healers from pulling their hair out?

We agree that TTK can be too fast in some situations, but it’s a very delicate thing to change.  If taken too far in the other direction, you run the risk of fights which drag on for so long that they become tedious.  Obviously that’s an extreme case, but the issue isn’t as simple as merely “turning all the knobs down.”  To an extent, some of the TTK speed was exacerbated by certain overly-effective AoE strategies, and we hope that our most recent changes in patch 1.3.6 will get AoE back to a more manageable level and help work towards addressing TTK in that manner.  We’ve also made some moves in that direction with the introduction of several defensively-oriented Sovereign armor sets:  using these will greatly increase a character’s survivability, but at the cost of some of their damage output – which will also lower the overall amount of damage flying around the battlefield, helping TTK.

There are two things to keep in mind regarding TTK, however.  First, it’s common that many players find it most satisfying to gear, spec, and play for maximum damage output at all costs.  There’s nothing wrong with that at all, but it’s crucial to keep in mind that if a character has intentionally ignored all of their defensive stats, tactics, masteries, etc., then their lifespan will be proportionately lower when under fire.  Second, don’t overlook the basic reality that if eight people happen to all target and focus on a single enemy…that enemy is pretty much going to explode.  =)

How do you decide on a change?  Such as the new Zealot/Runepriest mechanic.  From your numbers, you can see they’re underplayed, but what then?  And how do you evaluate if the proposed change will tip the scales too far in the other direction?

Once we identify an area that needs a change, we begin coming up with as many ideas as we can for possible ways to address it.  One thing that’s often overlooked about working as a designer is that shooting down an idea is often much more critical than coming up with an idea.  Thinking an possible change through to the nth degree, figuring how it would affect the broader game as a whole, predicting possible interactions with other designs, and so on, all have to be considered.  Once the untenable ideas have been eliminated, we discuss the remainder not only amongst the designers but also with the producer, community team, engineers, QA, and others.  From there, we make our decision and move forward to implementation, internal testing, and then PTS for public feedback.

Many classes have a pretty broad spectrum of tactics available.  Some tactics are fantastic and complement the class well.  Some tactics are largely ignored.  How do you go about fixing these tactics so players have a harder time deciding on which to slot?

Our general goal for tactics is that we want players to agonize over their loadouts and have to make tough choices between several desirable options and end up with a loadout that they’re happy with once the choice has been made.  Additionally, we want players to be using different loadouts for different situations, and tactics to be less “set and forget” – hence the multiple loadout sets built into the basic UI.  It’s pretty common knowledge that there are some tactics which are viewed as “must-haves”, and we see from our metrics that players don’t frequently change tactics.  Broadly speaking, our approach to improving tactics is to take one or two of the least-used and consider what improvements can be made to them; in most cases, we’d rather make bring up under-performing tactic options and make them as desirable as the most-used tactics.

[Rancid Note:  I wonder if making Tactic sets swappable in combat would help alleviate the “Set and Forget” mentality around them.  I could see it becoming quite popular to start a fight with an Anti-CC set, and then switching to a damage set.  Would that imbalance things?  Maybe.  It would add depth to combat though, for sure.

You guys have mentioned that you constantly monitor different metrics such as class population and ability usage.  Aside from raw data like that, how do you gauge the overall effectiveness of a class?

“Effectiveness” can be defined in several different ways, but at a high level, career representation is a useful snapshot as we watch migrations from one “FOTM” build to another – if one specific career is so overrepresented that they’re played massively more than average, then it’s a clear indicator that something about that career is probably too effective.  From that point, we investigate several aspects of that career such as the frequency of abilities used, the amount of time that tactics are slotted, how often morales are used, what masteries are being taken, etc., and determine what needs to be done from there.  By the same token, we follow the same process when we see that a career is drastically underrepresented as well.

Our other primary sources of information when it comes to career effectiveness are our QA and Community teams.  I’m constantly sitting down with Andy and our QA lead to discuss the feedback that they’re seeing and gathering, what it means for the game, and which careers they feel are over- or under-effective based on their information.

Beyond all of that, we also naturally have our own impressions from when we play on our regular Live characters, as well as feedback from everyone else in the office playing their own characters.  After all, no amount of metrics or reports can make up for first-hand involvement in playing the game and being part of the community (even if anonymously!).

It’s no secret Mythic wants to move closer to realm-mirrors.  How close do you think we’ll get to exact clones?  What’s keeping us from true mirrors?

In one sense, “what’s keeping them” is that we’ve learned in the past that we need to be cautious and incremental with our changes when possible, and try to avoid large, sweeping career adjustments.  This is a goal that we’d like to work towards over time, to make sure that we’re doing the right thing at each step.  In a more practical sense, though, while we do have a long-term aim of moving closer to career parity, that doesn’t necessarily mean that careers need to be -exactly- identical; minor differences often enhance the personality and “flavor” of a career.  The delicate part is getting to a point where we have enough differentiation for each career to have an enjoyable identity, while still having the broad strokes play out similarly.

What type of development tools do you use for you job?  Do you actually do real coding?

We have engineers that work very closely with the designers, and designers will often code their own tools on the side to help them analyze specific issues, but designers don’t do a great deal of coding day-to-day.  Instead, much of design work is data-driven, using custom/in-house tools and frameworks created by the engineers in cooperation with the designers.  It’s common for an engineer and a designer to be working together in parallel on the same task, with the engineer creating the code necessary to support a feature while the designer works through the design and data, and either one of them having input into the other’s direction.

Special thanks to Nate for taking the time to answer all these.  As you can see, he’s got a lot to say.  Got a follow-up question for some of these answers?  Post it below.  I’ll pick out some of the good ones to send back and see about getting answered.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s