paladin

A lot of people want the ability to go "invisible" with the Battletag system. That is, to appear offline to everyone else, but be able to see who's online. I sympathize with this desire. Sometimes you just want to play by yourself in peace. But it feels socially awkward to request that solitude when other people can see you online. As well, a lot of people don't respect the Busy status. They figure that means you are Busy to other people, and that you'd be fine if they contacted you. However, does no one remember ICQ and the late 1990s? The arms race that was "I am invisible to most people, but these specific people can see me if I'm invisible, unless I'm really invisible." Honestly, the entire concept of invisibility just made things overly complex. The thing is that in an ideal world we want things to be asymmetric. We want perfect opaqueness for ourselves, and perfect transparency for others. But this cannot work, because applies to everyone. There's no point to a friends list where everyone is invisible. I think that a better option, instead of invisibility, is to allow the option to "go dark" as a status. No one can see that you are online, but you can't tell if any of your friends are online either. To others you would appear offline, and everyone in your list appears offline. This would preserve the symmetry of the Battletag relationship. It gives you incentive to appear online as the default so you can see if your friends are online. But it would also allow you to play privately by yourself in peace.

Diablo 3 was released last night. I actually got home pretty late, so I decided to stay up for a little bit longer and see if I could get started at midnight. I got the infamous "Error 37" for about half an hour or so, but eventually I was able to log in and play. I'm starting off with a Demon Hunter, mostly because I think she has the best voice. It's really too bad there's no knight/paladin archetype in D3. I got to level 5 before deciding to go to sleep. The cutscenes are very nice. The game does seem a little harder than it was in beta, at least starting in the cathedral. But that might be because the first group I ran into was a pack of champion bats, with a couple harvesters mixed in, so maybe it's just a skewed first impression. I am thinking about trying Hardcore mode, maybe even from the start. But I'm not sure I'm the type of person who can restart and replay from scratch when my character dies. I rather think I'd just end up playing something else instead. So maybe Hardcore isn't the best idea for me. How were your Diablo experiences?

One of the interesting things about TERA is that--even though it has a cross-server instance finder--transient dungeon groups often still form via the old method of asking in local chat. It seems sort of odd, given the experience in WoW, where the Dungeon Finder has completely displaced asking in chat. So why does local chat still work for forming groups? I have several theories: 1. First, TERA's LFG has no rewards associated it. Using the instance finder has no innate bonus other than letting the system find a group for you. 2. Dungeons are located near people questing. So far, all the dungeons are in roughly the same area as the bulk of people at the correct level. This means that local chat is likely to contain all the people who might be interested. This is in contrast to WoW, where dungeons are often in a different zone, and especially SWTOR, where the dungeons were all back at Fleet. 3. Queue times for non-tanks are very long. TERA only has one tank class, Lancers, who are eligible for the Instance Finder. Thus the queue times for the other classes can be very long, up to half an hour for healers, and one to two hours for DPS. This makes it worthwhile for a non-tank class to start a local group. However, tank classes have instant queues. So why would a tank class go with a local group, rather than jumping in the Instance Finder? I think that part of it is the idea, maybe caused by WoW, that local groups are superior to random groups, which lack accountability. Personally, I don't see this in practice, in either WoW or TERA, but it is a very common belief. However, I think another part of it is that local chat can get tanks who are beginning to tire of their current leveling activity. Because queues are instant, the choice as a Lancer is very binary. You either run the dungeon or you go questing. But maybe after doing a few quests, you're sort of wavering between continuing questing or going for an instance. Seeing a request for a tank can tip you over to one side, and might even allow you to feel altruistic for helping out an existing group. Either way, it's an interesting phenomena. I am still not really sure why local chat and the instance finder coexist.

This is one of my favorite videos. Greyfoo does really good work, and this is one of his best. It's interesting, because he did this video for the Rise To Power contest, and that contest produced a *lot* of really good videos. Yet another example of the idea that restrictions breed creativity.

Ratshag left a comment on the previous post on MMO decline, and I've decided to highlight his comment and my response:

I notice you done completely skipped over the change from 40-man raiding ta 10/25 what came in TBC. If'n yer arguements was correct, should there not have been a drop in subscriptions then? Afters all, it hit a lotta raidin' guilds hard, and hardest hit were the 15-or-so grunts what (accordin' ta conventional wisdom) was bein' carried. Leaders, not so much. So how's come the subscription numbers went up?

I also notice what you says 10-man raidin' came "into vogue" in mid/late-Rash. What does this mean? It started showin' up on magazine covers? I mean, 10-mans was more popular in terms of numbers of buggers startin' in Kara, and this never changed. 25-mans had better rewards all through the end of Rash of the Itch King, an' still offer a greater quantity. So is yer "in vogue" claim fer that point in time based on anythin' objective, or did ya fall inta a trap of "well, that's when subscriptions done peaked, so that musta been when 10-mans became more stylin'."?

I don't think that the drop from 40 to 25 really changed the "nature" of guilds. To put it another way, a 40-man guild is closer in structure to a 25-guild than a 25-man is to 10-man. A 25-man guild will maintain sub-groups like healers and tanks and ranged dps. But a 10-man generally only has the main group, with no subgroups. A 25 is far more likely to have formal loot structures, where a 10 will be mostly ad hoc. Qualitatively, I would say that their is a point where a guild flips from "large" to "small" and that point is somewhere between 10 and 25. An interesting question might be 15-mans. Would they feel more like 10s or 25s? Keep in mind that the guild needs more than the bare minimum. A 25-man guild is really more like 35 people, and a 40-man is closer to 50 or 60. As for the timing, I don't think that Karazhan changed the nature of guilds. Everyone knew that future raids in TBC would be 25 man, so they temporarily bent their structure to accomodate Kara. But I definitely think that around Ulduar, guilds started to internalize the idea that 10s were viable. Structure started shifting to accommodating 10s. Large guilds started forming subgroups, almost subguilds, that ran the 10s together. In my view, it all comes down to structure. The structure of 40s is very similar to the structure of 25s. But that is different than the structure of 10s. Ulduar-ish was the time that guild structure started changing permanently, at least from my observations. I just think the 40/25 structure was more conducive to retention than the 10 structure is.

I love Blizzard. Their playerbase is busy arguing about pandas and their dances. Then out of left field, Blizzard goes, "Hey guys, cross-realm zones. And they're seamless." Ahh, Blizz, raising the bar for everyone else. Never stop. I think we are seeing the beginning of the end of sharded servers. An end to the time when specific servers corresponded to specific pieces of hardware. Rumor has it that Blizzard basically operates a cloud of servers now, like Google, and the servers are all virtual. I was wondering how they managed to put a million people in the Pandaria Beta with only four Beta servers. I strongly suspect that Titan, Blizzard's next generation MMO, will be a single world for all players. Or possibly a world for each language and ruleset combination. And if Blizzard makes that truly seamless, with minimal or zero load screens, it will be an impressive feat.

First, let's start with a caveat. The following theory is most likely not true. I doubt its validity, mostly because I would like it to be true, and that is always a dangerous sign. But I present it as a hypothetical for your delectation. The modern MMO decline in subscriptions, as evidenced by World of Warcraft and The Old Republic, is being caused by the shift in the extended endgame to smaller groups and smaller guilds. Let's look at at World of Warcraft. The decline in subscriptions starts in mid-to-late Wrath, when 10-man raiding starts coming into vogue. In Cataclysm, when 10-man raiding moved up to first-class citizen standing, the decline accelerated. In The Old Republic, the primary endgame group size is 8-man. It is clear that the SWTOR has real trouble holding on to people at max level. Small guilds, built for a small group endgame, are just not sticky enough for significant player retention. The one MMO which has shown continuous growth, even over the same time period, is Eve Online. And Eve bucks this trend in group size. Endgame in Eve trends toward larger and larger groups, with hundred-person fleets flying around. If this idea is true, why would large raids, and the corresponding large guilds, be stickier than small raids? First, and most importantly, there's a lot more room for "grunts" in a large guild. Grunts are average players who like playing the game, but don't really want to take on extra responsibility like the officers. If you take a 30-man raid size, and break it into 10-mans, I think you end up losing the bottom 10 players, just because there really isn't room for them if the subsequent guilds that form. I think a lot of people just want to play the game, and are perfectly willing to follow orders from someone more dedicated. Second, larger guilds and sub-communities are more likely to have people playing during off-hours. They can feel less lonely, which contributes to people sticking around. Third, turnover is more easily managed by larger groups. People leaving and joining is not as much of a big change to the group. A larger guild is also more likely to be able to absorb a smaller group of players. This is also true when a guild breaks up. It is easier for three or four 30-man guilds to each absorb a faction of players from the dead guild. In contrast, asking a 10-man guild to absorb 5 players strains the resources of that guild. Fourth, the intra-guild bonds don't have to be as strong in larger guild, as they are in a smaller more tightly-knit group. They don't require the large effort to create, to maintain, and don't cause as much damage when they break. I think this is actually an advantage for a lot of players. They just want a casual, light relationship with their guild, not an intense one. I think this also makes it easier to apply to a new guild, and form bonds which are "strong enough". Fifth, large group endgame requires a greater focus on technical performance by the developers. Does anyone believe that the SWTOR engine could handle 40-man raids? Whereas WoW could handle that 8 years ago. If 40-man raids had been a development requirement, SWTOR would have had to optimize earlier and harder. And that would have a lot of trickle-down performance improvements, especially for low-end machines and the performance of the levelling experience. For these reasons, I think larger groups are just stickier and better for the extended game than smaller groups. Smaller groups are easier on the officers and the devoted, definitely. However, I think they cause a lot of the grunts to be unable to find a home at endgame, and thus they unsubscribe and fade away.

The big news today is that Bioware revealed that The Old Republic has 1.3 million subscribers, a drop of 400,000 from their previously announced count of 1.7 million. I feel a bit sad for Bioware. I rather liked SWTOR, and if I wasn't boycotting Bioware, I think I still would be playing it. As an aside, it's really been an annus horribilis for Bioware. Dragon Age 2 was not received that well, there was unprecedented audience outrage over the Mass Effect 3 ending, and The Old Republic is hemorrhaging subscribers. Here's hoping the good doctors manage to regroup. In any case, the internet is awash in acrimony. Since no one has hard data, we all agree that the subscriber drop was because of the aspects that we personally did not like. If only Bioware had listened to us, and fixed whatever element was most important to us, the drop could have been averted. Here are a couple thoughts, in no particular order. Alt-Based Design It really looks like alt-based design is not a good strategy. The Old Republic greatly rewards playing alts, with eight different (excellent, in my opinion) class storylines and the entire Legacy system. And yet, judging by the timeline, I would wager that the largest group of people who quit only had one max level character, and the second largest only had two. To me, this strongly looks like encouraging alts is a losing strategy. The better strategy for MMO design might be to assume that most people play a single character all of the time. I mean, don't go out of your way to stop people from playing alts, but just design the game assuming that everyone focuses on one character. To further compound things, the Legacy system may have actively hurt SWTOR. Only characters on the same server share and contribute to the same Legacy. This might have discouraged people from rolling alts on more populated servers, leaving people feeling like they were stuck on low pop backwaters. Launch Managing launch seems to be the most important element for a new game, especially one with a lot of hype. In hindsight, it might have been better to stick with fewer servers and longer queues, rather than open too many servers and then see drastic population drops. Thinking about it, I wonder if one of the major reasons of WoW's success happened to be what happened at launch. I only started playing WoW about six months after launch. This was because the game was completely sold out. Blizzard had literally not printed enough physical copies to meet demand. This was before downloading large games became common. But what that meant for Blizzard is that six months after launch, when they finally got a second wave of copies out to stores, there was a new rush of pent up demand, injecting a lot of new blood into the system. Servers that were heavily populated stayed heavily populated. Medium populated servers became heavily populated. Suppose Bioware had capped the initial launch population at 500,000. And then only sold an additional 200,000 copies each month. That strategy may have worked out better for them, with continuous waves of new players topping up existing servers. Obviously, though, they wouldn't have made as much money up front as they did. And, of course, everyone on the internet would be outraged at being excluded. But no one would be saying anything about a dying game. This sort of artificial exclusion model might be a better model for a genre which relies on a minimum necessary population, and yet also experiences a lot of churn. Further Thoughts I have one more crazy, off-the-wall hypothesis (yes, even by my standards). But I'll leave it for tomorrow. All in all, there's no way to spin this subscriber drop as good news for SWTOR, though EA is trying hard. But I do hope that the population stabilizes, and the game moves forward. It is a good game, with decent ideas, and I would like to see what Bioware does with it.

Lancer tanking in TERA is the best implementation of tanking in any MMO that I have played. Now you should take that with a grain of salt, as my Lancer is only level 28, and that is far from endgame tanking. But I thought I'd take a look at the mechanics of tanking in TERA, and what makes it different from WoW-style MMOs. The Lancer is a shield tank. Her signature skill is Stand Fast. When you press the Stand Fast button, the Lancer brings up her shield to block enemy attacks from the front. She braces in place and continues blocking for as long as the button is held down. Blocking the enemy's attack is guaranteed, and absorbs a fixed amount of damage--not a percentage--from every attack. As well, players behind the tank are also shielded from damage. The key element here is that the amount of damage blocked is extremely large. Almost all attacks, including boss specials, are fully absorbed. Essentially, while the Lancer Stands Fast, she takes zero damage. However, while she is blocking, the Lancer cannot deal damage or gain threat or mana. She must drop the block, making her vulnerable, in order to attack the enemy. And threat matters. The Lancer needs to fight for threat to keep the boss from going after the DPS or the healer. Those two mechanics produce a marvellous tension. The Lancer must block, or she will take too much damage and die. The Lancer must attack, or she will lose the boss's attention. As well, the boss telegraphs his attacks through his animations. So the Lancer can observe the boss and identify times when it is safe to drop the block and attack, and the times where she absolutely must block. I think the key here is the absoluteness of defence. In WoW, the choice between threat and survivability always went to survivability, because every inch made the tank less likely to die, and lessened the burden on the healer. In TERA, you know that if you block correctly, your defence is absolute, and so you are free to spend resources on threat. It moves the threat/balance trade-off from gearing to gameplay. For example, right now I'm spending all my specialization points on threat. This means that fewer attacks build the same amount of threat, and thus I can spend more time blocking, and have more room for error. The last part is positioning. WoW tanks spend a lot of time and effort positioning and moving bosses correctly. In TERA positioning doesn't seem to matter as much, as the bosses seem to run around like monkeys anyways, and the other characters are agile enough to dodge out of the way. Now, there are downsides to the TERA model. In particular, it can be very unforgiving. The first time I tanked an instance, I dropped my shield at exactly the wrong moment, and got nailed by a boss special, which killed me because I was already a bit damaged. Tanks are somewhat rare in TERA, so maybe this is a cause. (Though it might be just because there are so many DPS classes compared to the tank classes.) Perhaps the secret to the success of TERA tanking design is that the tank has control over both threat and survivability during gameplay, and has to balance both. In vanilla WoW, the tank didn't really control her damage intake outside of long-term cooldowns. Instead that was a function of her gear. She spent all her resources on threat and positioning. In modern WoW, threat no longer matters. Instead, the tank will spend her resources on mitigation and positioning. Neither style has the enjoyable tension that TERA tanking does. Or perhaps the secret is just making the tank more responsible for her health, and the healer less responsible. You still need a healer in TERA, as it makes life a lot easier. But losing a healer isn't always an immediate loss, not the way it often is in WoW, because the tank can play very defensively and dramatically reduce the damage she takes, buying time for the DPS to finish the fight.

So there's a New Blogger Initiative making the rounds. I was thinking about writing some advice, but I remembered that I've pretty much written all the advice I can think of before:

• On Blogging, Part I - covers platform, focus, and content
• On Blogging, Part II - covers traffic, advertising, and comments

Here's a really nice video and song about the Dragonwrath questline. The storybook conceit is very nicely done. Hats off to Nananea and Sharm. You know, an awful lot of stuff happened on that questline. I wonder if the Rogue quest was similarly eventful.

This will be the last post on the PLEX issue. I still think PLEX is unfair. All the arguments for PLEX have sidestepped the basic unfairness issue, and pointed to the good effects that PLEX has. But at it's heart, Eve permits one faction of players to skip content for real money, but does not do the same for other players. It weakens the fidelity of the economic simulation that is Eve Online. However, as Voltaire said, perfect is the enemy of good. PLEX has lots of positive effects. It induces liquidity in the markets, causing ISK to be spent instead of hoarded. It decreases the effect of unsafe third party RMT in Eve. It allows the producers to avoid spending money on subscriptions. It allows people who don't like the "work" of producing to concentrate on the fun, and keeps them in the game, and paying subscriptions. It provides excitement for piracy and shipping. Killing an enemy carrying PLEX seems to be one of the great delights of Eve PvP. On net, PLEX is probably a necessary evil for Eve Online. But it still has a cost, and that cost is the basic unfairness. To annoy Wilhelm, I will make yet another analogy. PLEX is like the designated hitter rule in baseball, or shootouts in hockey. It's legal, it's in the rule book. It's popular, the crowds enjoy it. It might even be necessary for the continued health of the game. But baseball without the designated hitter is a purer form of baseball, as is hockey sans shootouts.

I am really enjoying TERA so far. It's a great deal of fun. I adore combat as a Lancer. Bringing your shield up to block at just the right time, taking no damage from a big hit, is awesome, especially with the visual feedback provided. Blocking a huge monster as it does some sort of bullrush attack, pushing you backwards as you take the hits on your shield, taking no damage, makes you really feel like a tank. Chaining combos together is also neat, and the animations make combat very visceral. The thing I like about PvE combat in TERA is that it is very interactive. In WoW and most other MMOs, what your opponent is doing doesn't really matter, aside from maybe interrupting or stunning. You go through your rotation, and the mob dies. TERA really encourages you to pay attention to the mob, to watch for the tells and block or dodge. The game also performs very well, and is very responsive. The game is colorful, and feels fun and full of whimsy. I also find some of the design and art decisions hilarious.  Here's my Lancer with shield and lance at the ready. Looks pretty awesome, with a great shield design: Now here she is showing her armor: The armor is just hilariously bad. It's like it's giving the monster a target to aim for. But somehow, instead of being annoyed at the armor, it just amuses me greatly. Now, TERA has it's downsides. The questing is very old school, and is just an excuse to kill a new set of mobs, rather than tell some sort of important or memorable story. The writing is not particularly good either. It's decent, and occasionally very funny (sometimes intentionally, sometimes not, and sometimes it's hard to figure out if it's intentional or not). Some of the subsystems are unnecessarily complex. For example, enchanting a piece of armor requires another piece of the same slot of roughly equal item level as a raw material. But for some reason, you can't put many items in your bank. So I'm carrying around a dozen chestpieces just in case I need to enchant a new chestpiece. There are also some interesting design decisions as well. For example, gathering materials gives you a small random buff, rewarding you for making gathering part of your questing and combat routine. For some reason, I absolutely love this feature. It really does not make a big difference in questing, but it just works for me. As well, I really like how they are handling the launch rush. There are queues on some servers. But TERA has server transfers implemented, and the transfers will be free for the first little while. So even if your preferred server has a queue, you can start a character on a different server and eventually transfer over once everything gets sorted out. This strikes me as a really good balance, allowing the population to flow from server to server in response to the changing conditions of launch, without heavy-handed dev intervention. There's also an instance finder, but groups are also forming in area chat. So right now, you have the best of both worlds. I've done the first dungeon twice, once through instance finder, and once through a local group. As well, for some reason area chat seems to be hopping. Maybe it's because it's the RP server, maybe because the chat box can display more than three lines, or there's less system spam. But whatever the reason, it's a very nice change from the quietness of most recent MMOs. All in all, I'm really enjoying TERA. It seems to strike this nice balance of being "different enough" from most WoW-like MMOs, while not being too different.  I definitely recommend the game so far, and think it's well worth the initial box price. Edit: Another small thing I like is that the quest tracker has a button to track or untrack by area. So you can easily swap up your quest tracking when you change areas. Also, to continue the inappropriate armor screenshots, I got a blue armor piece from the end boss of the first dungeon: One thing I do like is that the character's hairstyle changed, to adjust to the new armor. That was a nice touch.

I've been following Gevlon's comment thread, and I've realized that he and I are actually talking about two different aspects of PLEX. PLEX versus Economic Simulation From the outside, one of the main attractions of Eve Online is that it is this huge economic simulation with hundreds of thousands of actors. People harvest resources, refine resources, produce goods, trade, purchase and use those goods. Then you add on the player conflict overlaid on top of all that. It is a magnificent economic simulation and experiment. It is amazing to realize that the ammo I purchase to shoot pirates was produced by another player, as is the ship I fly in and modules which the ship is outfitted in. The thing about this economic simulation is that you can trace the flow of wealth, see how all the interlocking transactions combine into one harmonious whole. And each transaction makes sense within the universe. But then, inside this beautiful simulation, you have some extremely large transactions that simply do not make sense within the context of the universe. Half a billion ISK transferred from one player to another, for no discernible rhyme or reason. That transaction weakens the economic simulation, warps it slightly, has trickle-down effects, and makes the whole thing less real than it could be. PLEX as a Means of Skipping Content Some people are producers. They enjoys earning ISK, either by harvesting resources or trading or producing goods. They dot not enjoy being attacked by other players. But they deal with that inconvenience, and adjust their gameplay to defend or mitigate against that possibility. PLEX buyers are consumers. They enjoy expending ISK, often on attacking other players. They do not enjoy earning ISK. However, unlike the producers, the consumers don't have to deal with their inconveniences. They don't have to adjust their gameplay to compensate. They can spend real money to skip the part of the game they don't enjoy. That is the part which is not fair. The situation is not symmetrical. One faction can skip the part of the game they do not enjoy, while the other faction cannot. Consider the following hypothetical. Suppose CCP sold, for real money, an IMMORTAL module which rendered your ship immune to player attack (but disabled your weapons while installed). The module would have a lifespan of one month of real-time, after which it would self-destruct. Would the Eve playerbase be okay with such a module? Or would using it be considered cheating? After all, all it does is equalize the situation between producers and consumers. The consumer can buy PLEX to skip the parts of the game he doesn't enjoy. The producer can buy IMMORTAL modules to skip the parts of the game which she doesn't enjoy. Yet I suspect that the Eve loyalists would howl if IMMORTAL modules were ever sold by CCP. But in many ways IMMORTAL modules are no different than PLEX in their effect on how an individual enjoys the game.

Gevlon wrote a post saying essentially that PLEX was cheating. PLEX is essentially a a game card for 1 month of game-time, that is purchased from CCP for real money, but can be sold in game for virtual currency. Gevlon was promptly jumped on by Eve loyalists in the comments. However, I think he is sort of right. Though, "cheating" is not precisely the right word. Rather, I would say that PLEX is against the spirit of Eve Online. Eve is a sandbox game, a virtual universe inside which one builds a virtual existence more or less from scratch. Allowing outside transactions to affect transactions inside the virtual universe seems to cut against the whole sandbox. It kind of comes back to the notion of inconvenience. It is certainly convenient for, as an example, PvP pilots to buy PLEX to fund their games. But there is a price for that. Those pilots don't have to work, to participate in the game economy, for those funds. If PLEX did not exist, they would have to do something, produce something of value, before they could get to what they think is the fun part. Maybe they would take up mining, maybe they would become pirates. Who knows? But not having to do that does distort the economy in some small fashion. It weakens the notion of Eve as a self-contained sandbox universe. But maybe PLEX is a necessary evil. Maybe its existence spices up gameplay, and makes the economy more liquid, with more and larger transactions moving around. Maybe the alternative is those players quitting Eve instead of continuing to play. Maybe it means that CCP would make less money, and not be able to fund development as Eve deserves. Maybe third-party ISK sellers would fill the void, leading to the same result, but with a lot more unfortunate side-effects. Ultimately, inconvenience is what makes a world a world, and not just a game. PLEX is convenient, but makes Eve less of a world, and more of a game.

Jita. The largest trading hub in Eve Online.  You will never find a more wretched hive of scum and villainy. At least, that's the case if you go by the local chat. Honestly, this was worse than Barrens chat, with multiple people spamming macros of repeated chat, ascii graphics, scams, and all other sorts of foolishness. Like many others in Eve, I heard about the Goons attack on Jita this weekend and thought that I would go see it for myself. I'm just flying a Catalyst destroyer, so I figured that even if I died, I could replace my ship easily. There were a lot of people in Jita, about 2000 or so. But nothing much seemed to be happening. Maybe I play at a different time than when all the events go down. There were a lot of ships flying around, and occasionally CONCORD (the NPC police) would blow someone up. I thought I would try and join the action, and targeted someone who was a yellow skull to me. But when I went to fire, I got a warning saying that CONCORD would attack me, so I didn't fire. I guess yellow isn't bad. All in all, my time in Jita was pretty boring. I did like watching a fleet of about 30 Hurricanes set up some sort of interdiction net around the gate to the Perimeter system. That looked kind of cool. But ultimately, after a couple hours in wandering around Jita, I got bored and went back to my usual mission-running systems. After that, I thought I would make a mining alt. But when I started the alt, the game informed me that I could only learn skills on one character at a time. I wonder what the point of having multiple characters on a single account is with that restriction. Is it worth losing a month or so of skill time on your main to skill up an alt? It seems like I could just spend that month (or less because I already know some skills) and learn those mining skills on my main.

In the last three posts, we’ve built up the equations we need to calculate the survivability stat weights for warriors.  In this post, we’re going to summarize the equations we need, and then plug in numbers to see how it all works out.

Note that I’m not going to go through the derivation step by step here.  I’m just going to list the equations we need, and then analyze them.  If you want to know where a particular expression comes from, you’ll have to slog through reading parts 1-4.

Required Equations from Part 1:

In part 1, we built up the normalized scale factors :

where , , , , , , and are the factors that convert rating to percentage for armor , hit, haste, crit, mastery (in this case, rating->mastery), parry, and dodge, respectively.  is the armor mitigation factor,

,

where is a constant that depends on player and target level, and is the player’s armor.  is the avoidance mitigation factor,

,

where is the player’s total (post-DR) avoidance.  is the block mitigation factor:

,

where is the probability that an unavoided attack becomes a guaranteed block, is the critical block chance as determined from mastery,  is the player’s total block chance, and is the player’s block value (30%).  has the form,

,

where we’ve implicitly defined the Shield Block buff duration and the Shield Block cast rate , which will be defined later on in the rage generation section.

We also have the factor , which represents the avoidance mitigation factor’s scaling with dodge and parry:

with being the player’s post-DR dodge from sources subject to DR, and and being the avoidance diminishing returns coefficients.  We’ve assumed here that dodge and parry are properly balanced.  And we have the factors , which represent the scaling of the block factor with respect to different stats:

where we’ve incorporated definitions from the differential block factor equation:

as well as factors from the equation for :

and the factor representing diminishing returns on block:

where is the mastery-to-block-chance conversion factor (1.5%) is the player’s post-DR block chance due to mastery (i.e. the part that’s subject to DR), and and are the diminishing returns coefficients for blocking.

We’ve also used , which is the mastery-to-crit-block conversion factor (1.5%).

In the expressions for we’ve defined some factors which represent the scaling of the SB cast rate with different stats.  These will be defined in the “Part 3″ section.

Required Equations from Part 2

In part 2, we modeled the rotation.  We defined and , the melee and spell hit factors:

And used a stochastic matrix method to determine the steady-state probability factors:

We then determined the cast rates for different abilities:

And we defined some differential cast rate factors :

.

We then went on to calculate the effects of parry-haste, giving us definitions for the auto-attack rate:

in terms of the incoming attack rate , and two more definitions that represent haste and parry-haste scaling of auto-attacks:

Required Equations from Part 3

The shield block cast rate is found from the rage generation equation (link):

,

where is the enrage buff uptime, is the player’s base auto-attack rate, is the player’s auto-attack rate after haste and parry-haste effects, the rate of regular shield slams, the rate of Sword-and-Board-affected Shield Slams

where , , and are the hit, dodge, and parry caps (7.5% each), and and are the player’s hit and expertise percentages.

The found in the expressions come from the derivative of the Shield Block cast rate equation, and are:

where we’ve made use of the following definitions from the Enrage derivation:

Tying it all together

At this point, you might expect that I would start back-substituting expressions.  There are two reasons I’m not going to do that.  The first is that these expressions are complicated enough that doing so is futile.  It’s hard to get any useful information out of these expressions once they become too complicated to read. It’s a little easier to glean intuition by simply evaluating all of the different factors we have and understanding why they’re positive, negative, small, large, etc.

The other problem is recursion.  If you were paying close attention, you might have noticed the following quandary:

So depends , which depends on , which depends on , which depends on…. .  This isn’t a simple thing to solve analytically, and the expressions will end up getting even worse in the process. A similar situation happens for haste, mastery, hit, and dodge when we try to evaluate and .

It’s much faster to use recursion to do this numerically.  Basically, we make a guess at , and then evaluate the whole chain, recalculating at the end.  We then take the new value of and repeat the process.  We do this until a certain tolerance threshold is reached – say, the maximum change in value of any of these variables changes by less than %.  It turns out that only takes around 12 iterations, so it’s not particularly time consuming.

Numerical Calculation

The code I’m using to calculate the results can be found here:

derivations_warr.m

You can see that I’ve more-or-less reproduced all of the equations from this post, and written small loops to handle the recursive definitions.  The input values I’m using are:

(5% base miss/dodge/parry plus 10% dodge and parry from DR)

Numerical Results

Plugging those in and multiplying by for ease of analysis, we get the following stat weights:

Parry and dodge rank at the top, as expected.  Parry pulls ahead of dodge by virtue of increased rage generation through parry-haste, but it’s a pretty small effect.  Mastery doesn’t fare too badly for warriors, but it’s definitely not as attractive as dodge and parry.  I was actually a little surprised at how well mastery did, figuring that the Shield Block mechanic would suppress it some.  In fact, it does – about 80% of mastery’s value comes from the raw mitigation of more critical blocks.  Only about 12% comes from increased block chance, and the other 8% comes from increased Shield Block uptime (via more critical blocks increasing Enrage uptime).

Hit and expertise help increase rage generation and significantly impact Shield Slam casts (by reducing Revenge misses/dodges/parries), so it has a strong effect on resource generation.  Note that armor is actually ahead of mastery in terms of itemization, because you get 4 armor per itemization point.  Haste and crit both provide some increased resource generation (from auto-attacks and Enrage uptime, respectively), but they’re both weak effects.

While we’re at it, let’s see what Shield Block and Enrage uptimes look like:

That’s an incredibly large uptime on Shield Block.  Most of this is due to the changes in this last beta push – doubling the Enrage bonus and reducing Revenge’s cooldown both had a significant impact on rage generation.  Let’s quickly look at the breakdown of rage sources:

So our net rage generation rate is 8.09 rage per second, and the majority of it is coming from Enrage-buffed auto-attacks.  Shield Slam is only accounting for a little over 2 RPS because we’re at low hit/exp.  At 7.5% hit/exp, we jump up to about 9.7 RPS, a little over 7.5 of it from auto-attacks and 2.5 from Shield Slams.  At that level of hit/exp, Shield Block uptime reaches 97% – nearly block-capped.

This is a bit of a problem, in my mind.  Shield Block is rather powerful because it forces block-cap for a fixed time period, and we’ve seen how unbalancing that was in Cataclysm.  If warriors can successfully reach 90%+ uptimes on Shield Block, it will become a balance problem.  I’m not sure what the solution is – nerfing the duration on Shield Block would do it, but that would make Shield Block a bit more timing-intensive too.  Lowering rage generation rates seems like the simplest way to do it.  They could keep the Revenge change, since that makes the rotation more interesting, but drop the auto-attack accumulation rate so that it’s on par with Shield Slams.  That could be achieved by dropping the Enrage bonus, or by keeping Enrage at 50% but dropping the normalized rage generation from auto-attacks from 5/second to 3/second.

Conclusions

In this series, we’ve seen that the warrior equations are much more onerous than the paladin ones due to the complications of parry-haste, Enrage, and auto-attack-based resource generation.  Nonetheless, we slogged through it to get stat weights, and those stat weights seem reasonable given what we know about warrior mechanics.  The dodge/parry values aren’t highly inflated because Shield Block’s guaranteed block effect doesn’t get consumed, unlike the Paladin version.  And since warrior mastery isn’t simply block chance, it interacts with their active mitigation and keeps mastery attractive.  They still see a mitigation benefit from hit/exp, haste, and even crit due to faster rage generation, but those effects are all weaker than the increase from “true” tanking stats.  All in all, the system doesn’t seem too bad.

The real eye-openers are the rage generation levels and subsequent Shield Block uptimes we’re seeing in the model.  If accurate, those suggest a potential balance problem as warriors gear up and can afford to reach hit and expertise caps.  Of course, there could still be changes in the pipeline for warriors, so it’s too early to tell.

I was rather bored this weekend, so I decided to have another shot at TERA.  The thing about TERA is that I expect so little from it that the game is actually a great deal of fun. This time I chose to roll a character on the Role-Playing server, under the theory that the innuendo in general chat would at least be in proper English. (As a complete aside, I rather wish there were Normal servers, but with the Roleplaying restrictions on names, chat, etc. A 'Polite' server ruleset, as it were. I have no interest in roleplaying, but I rather like being on a server with people who can write in full sentences, and no Arthasloldk in sight. But the roleplayers must get pretty annoyed that "their" server is overrun with people who don't roleplay at all.) In any case, I rolled a female human Lancer, which is a lance-and-shield tank. Yeah, the first rule of TERA is not to question the logic behind anything, but just go with the flow. The lance telescopes somehow, automatically extending to full length when you enter combat. As expected, this leads to interesting commentary in general chat. For some reason, TERA to me is symbolized by the following story. The female Lancer is very scantily-clad, which includes a miniskirt as part of her (theoretically heavy) metal armor. But as my female readers can probably attest, a miniskirt does not really go well with riding a horse. So what does any logical knight-errant do? That's right, she rides sidesaddle:

Coriel the Lancer, with mount. Note the telescoping lance on her back.

Somehow, this is just so perfectly TERA to me. Perfectly reasonable thinking, but from completely crazy starting points. I'll talk more about tanking in a later post, because it's quite interesting, and quite possibly the perfect blend of tanking mechanics, of what Ghostcrawler calls "active mitigation". Honestly, if you can get past the skimpy clothing, and the race that looks like little girls (who now wear shorts instead of tiny dresses), TERA is quite a fun and engrossing game, with some really intriguing mechanics and subsystems.

So far, we’ve developed the general expressions for warrior block mechanics, and we’ve worked out the warrior rotation and the effects of parry haste.  In this installment, we’ll work out the last two pieces to the warrior block mechanics puzzle: the Enrage mechanic, and the rage generation equation.

1. Enrage Mechanics

The Enrage buff increases rage generation from auto-attacks by 25%, so we need an accurate model of it if we intend to get accurate estimates of rage generation.  Normally, buff uptimes are fairly simple – a buff with a single potential trigger has an uptime of

where is the probability that the effect doesn’t proc ( is the probability that a proc does occur), and is the number of proc chances that occur during the buff’s duration.  The logic behind this is pretty straightforward – the probability of having N failed proc chances during the buff’s duration is , and if that happens, the buff will fall off.  You can rigorously show that this is the correct formula using a Markov chain, if you’re so inclined.  Since this is a well-established result, we’re not going to repeat that here.

However, Enrage is more complicated than this, because Enrage has three proc mechanics.  It can proc from critical strikes (so auto-attacks, Shield Slam, Devastate, Revenge, and Thunder Clap in our model), critical blocks, and from automatic crits through the interaction of Ultimatum and Glyph of Incite.  And on top of all of that, Berserker Rage grants the enrage effect on-demand.

1.1. Multi-Sourced Uptime Equation

Let’s ignore Berserker Rage for a moment, and handle the three proc mechanics.  Using the same logic as the simple example, the buff will drop off if we get no successful procs from any of the three mechanics during the buff duration, so our uptime should look like:

,

where , , and are the “failure” chances for critical strikes, critical blocks, and Ultimatum procs, respectively, and , , and are the number of times each of those events can happen in the 6-second buff duration.  We can write explicit expressions for :

Where is our crit chance, is our crit block chance, and is the Ultimatum proc chance. The expressions for are:

Where we’ve used our definitions of and from last time, and included the glancing blows chance .  Here, we’re assuming that the warrior will only ever use Heroic Strike if it’s free (i.e. 0 rage coast), and Glyph of Incite guarantees each of those will be a crit.  If the glyph isn’t used, is no longer necessary, and regular Ultimatum-induced crits can be folded into by adding a 1.3 to the coefficient of .

Note also that is complicated by the fact that we have different miss rates for each attack source.  Shield Slam, Devastate, and Revenge are all melee attacks, while Thunder Clap is a spell, and auto-attacks have an extra chance for glancing blows (which cannot be crits).

Berserker rage can be trivially included in this, as it gives 20% uptime automatically.  If we treat this as a stochastic event (i.e. random), then our expression for enrage uptime is

In theory, you might be able to do a little better than this by saving Berserker Rage and using it only when your stochastic (i.e. random) Enrage effects aren’t active, but it’s not likely to be a big improvement.

1.2. Derivatives of q and N

We’re going to need to differentiate , so it will be to our benefit to calculate the contributing differentials and .  The are very simple:

where is as defined in part 1.

The derivatives of are much more annoying, so we’ll do them one at a time:

There are a few simplifications we can make to this expression.  We know that from part 2.  We also know that is all of our GCD-based casts except for Battle Shout, thus

Using all of these, along with our definitions of , , , , and from part 2, we have:

We can define a few abstraction factors to help clean this up:

is even worse, because it’s got in it.  Let’s crank through that:

And, again, saving you some algebra:

,

where

,

and I’ve used the definitions from part 1.

is quite simple:

which simplifies to

.

Now, we have all the derivatives of and that we need to complete our Enrage model.  All that remains is to differentiate our expression for and plug in the results from this section.

1.3. Differentiating E

Unfortunately, differentiating is a bit of a pain.  The problem is that both and differentials come into play, which makes the results a bit cumbersome.  To differentiate, we’ll make use of the identity:

Doing so gives us:

We can simplify this some by pulling out a factor of :

We can simplify this further by noting that and plugging in our results for :

Unfortunately, the expression balloons a bit when we plug in the :

But by combining terms and abstracting, we can get a reasonably manageable form:

Which is our final form for , and completes our model of Enrage effects.  Note that while there seem to be a lot of negative signs in these expressions, it’s because all of the natural log factors are negative.

2. Rage Per Second Calculation

At long last, we’re ready to construct our rage generation equation.  The basic form will be:

The easiest is , which is just

,

and since it’s a constant, its derivative is zero.

2.1. Shield Slam Rage Generation

Shield Slam is also fairly straightforward,

The term in brackets is the base SS rage generation rate (maximum 2.8 rage per second at hit- and exp-caps). The derivative is then,

Using our expressions for and from part 2, we have:

2.2. Thunder Clap Rage Cost

Thunder Clap is also not particularly difficult, since we’ve already developed an expression for :

Differentiating gives us

.

2.3. Auto-Attack Rage Generation

Finally, the expression for auto-attacks is:

Note that each melee attack generates a normalized amount of rage .

Differentiating gives us,

2.4. Combined Rage Generation Equations

Combining all four of these expressions, we have:

which simplifies to

.

The Shield Block cast rate is simply .  We could differentiate this directly, but it’s a little easier to just combine the individual differentials worked out earlier:

Which is, of course, annoying to deal with, so we abstract some:

We then plug in our expressions for and :

Combining terms, we have

The change in the rate of Shield Block casts due to a change in rage generation is simply , and we’ve already defined the expression for in part 1:

By inspection, we can now define the as follows:

And finally, we have a complete model of warrior block mechanics.  In the next post, I’ll collect all of the expressions we need in one place and plug in numbers to see how the different stats compare.

In the last installment, we calculated expressions for the normalized scale factors that represent the effectiveness of a given stat at reducing damage taken.  To finish the job, we need to calculate explicit expressions for the variables , , , , , , and , which represent how a warrior’s Shield Block cast rate varies with hit, expertise, haste, mastery, crit, dodge, and parry, respectively.

1. Rotation Modeling

The first step in this process is to determine exactly what the warrior rotation looks like.  We can make a few assumptions here:

• The warrior dumps all of their rage into Shield Block
• We don’t care about DPS, so we’ll use the highest-rage-per-second rotation

The primary source of rage generation is Shield Slam (SS), which generates 10 rage.  However, it generates 15 rage if cast during a Sword and Board (SnB) proc.  So the rotation will revolve around maximizing SS casts.  The most efficient way to do that is with a simple Priority: SS>Revenge>Devastate

In this model, we cast the abilities as soon as they’re available, following the priority order given.  If you do that, you can break the rotation down into four possible sub-sequences:

• 1: SS-Revenge
• 2: Devastate-SS-Revenge
• 3: Devastate-Devastate-SS-Revenge
• 4: SS(SnB)-Devastate-Revenge

This may look funny, but the idea is reminiscent of a Markov chain.  Every time we cast Revenge, we get a branch, and #1-4 are the only four possible branches we can enter.  For example, we always start with #1.  If that Revenge triggers SnB, we always jump to #4 (SS-Rev-SS(SnB)-Dev-Rev), and if it doesn’t we’ll always jump to #3 (SS-Rev-Dev-Dev-SS-Rev).  Thus, we can find the steady-state probability of each sequence occurring using the concept of Stochastic (or Markov) matrices.  We construct our transition probability matrix P:

In this matrix, each element represents the probability of transitioning from state to state .  To find the steady-state probabilities, we just calculate in the limit as .  In fact, we don’t even need to go very high in – the matrix is identical for :

Thus, we have a 24% chance of being in state #2, a 16% chance of being in state #3, and a 60% chance of being in state #4.  We can use this information to calculate the generated rage per second.  State 2 generates 10 rage in 4.5 seconds, state 3 generates 10 rage in 6 seconds, and state 3 generates 15 rage in 4.5 seconds, giving a net Rage Per Second (RPS) of (10/4.5*0.24 + 10/6*0.16+15/4.5*0.60) = 2.8 rage per second.  This is the maximum rage generation rotation for warriors now that Revenge has a 4.5-second cooldown.

There’s an additional complication though – we haven’t accounted for Revenge misses.  That reduces the transition probability to state #4 from to , and increases the other transition probabilities from to .  Here, is our base chance to miss (7.5% against a boss), and are our base chance to be dodged/parried, and and are our hit and expertise.  Since this term in parentheses (which is our melee success probability) will show up fairly often, let’s define a placeholder for it.  While we’re at it, we’ll define one for our spell success probability () as well:

Once we include this, the steady-state probabilities are analytically:

and their derivatives are

We can then represent this rotation by writing down the cast rates for certain abilities.

1.1 Shield Slam cast rates

Starting with the highest priority, Shield Slam:

We’ve divided this up into rates for “regular” Shield Slams and Sword and Board Shield Slams .  By deconstructing the weighted average we used above, you can show that

.

We’ll also want the variation of each of these terms, so let’s calculate them right away:

with

1.2 Revenge cast rates

We can also quickly figure out Revenge’s cast rate,

using the same technique.  Note that we’re assuming here that Revenge is always available, which is a pretty safe assumption if you’re tanking.  It turns out we won’t need either of these values, but they’re good to have lying around.  The derivatives of are identical to that of , so

.

1.3 Thunder Clap and Battle Shout cast rates

Devastate is a little trickier, because we’ll be replacing some Devastate casts with Battle Shouts and Thunder Claps.  So let’s work out those first.  Shout is easy – it’s just

.

Thunder Clap is slightly trickier.  Ideally, we would cast it every 30 seconds to keep up the Weakened Blows debuff.  However, it’s not automatic.  If it misses, we’ll cast it again as soon as it’s available (6 seconds).  So the proper way to write it would be:

.

In other words, it’s the weighted average based on hit/miss chances.  Note that I’ve assumed it misses as a spell for this rather than as a melee strike.  I’m not sure if this is correct, but it’s easy to fix if we find out that assumption is wrong.  This simplifies to

,

and the derivative  is

,

with .

1.4 Devastate cast rates

Now for Devastate.  In the scenarios above, we cast Devastate at a rate of

,

with a derivative scaling of

,

with

.

However, we need to subtract off to account for Thunder Clap and Battle Shout:

From this we can immediately see that

,

We could substitute in our expressions for and , but that doesn’t make the expression too much easier to work with, so we won’t bother.  At this point, we have a complete model of the warrior rotation.

If Shield Slam and Battle Shout were a warrior’s only sources of rage, we’d be done here.  Rage generation would simply be the rage from Shield Slams plus the rage from Battle Shouts minus the rage used to maintain The Clap.  And that would be really simple. But we’re not so lucky, because warriors also generate rage from auto-attacks.  And that leads to a number of problems.

First, we need to accurately model melee swings, which means we need to care about parry-hasting.  That’s a non-trivial problem, and will be the focus of the second half of this post.  The other issue is that Enrage increases rage generation from those auto-attacks during its effect, which means we need an accurate model of Enrage uptime.  And to do that, we need to account for all sources of Enrage – critical strikes, critical blocks, and even the interaction of Ultimatum with Glyph of Incite.  We’ll deal with the Enrage modeling next time.

2. Parry Hasting

Parry-hasting as a mechanic can be extraordinarily complicated in the general case.  I’ve worked on this problem before, and the matlab code has a function that specifically models parry-hasting.  If we wanted to treat the problem completely generally, it wouldn’t be possible to come up with a nice analytical formulation.  However, we’re going to limit our scope to a single situation – tanking a single raid boss – which makes it possible to analytically represent parry-haste.

The mechanics of parry-haste work like so: When you parry an attack, your swing timer is reduced by 40% of its un-hasted value, unless that would reduce the swing timer to below 20% of that un-hasted value, in which case it reduces the swing timer to 20% exactly.  That’s a little clumsy, so let’s consider an example.  If I have a 2.00-speed weapon, my swing timer is 2 seconds.  If I parry the boss when there’s 1.9 seconds left on my swing timer, it reduces my swing timer by 40% of 2 seconds, which is 0.8 seconds, leaving 1.1 seconds remaining on my swing timer.  If I parry when there’s 0.9 seconds left on my swing timer, it can’t reduce my swing timer by the full 40% because that would drop itbelow the 20% threshold (which is 0.4 seconds).  So instead, it drops the swing timer to 0.4 seconds exactly, giving me 0.5-seconds of parry-hasting (only 25%, instead of 40%).  If I parry an attack when there’s 0.4 seconds or less left on my swing timer, there’s no effect at all.

Thus, the average amount of parry-haste you get from a single parry is 24%.  There’s an additional complication, which is something we call “Doubly Degenerate Parry Events” (DDPEs).  This is when you parry two attacks in rapid succession, and that ends up causing some attrition in parry (the second parry is less effective, necessarily).  However, we’re going to consider a boss with a swing timer between 1.5 and 2.0 seconds, which eliminates the possibility of DDPEs.  So we can ignore that problem.

Generally, one would represent parry haste by a set of coupled equations linking the boss attack rate to the player auto-attack rate .  However, since bosses no longer benefit from parry-haste, the equations are considerably simplified, and the coupling is one-way:

Here, is the coupling constant that represents the effect of parry-haste.  If we ignore DDPEs, we can represent as:

To get some intuition here, is the binomial probability distribution representing having successful events out of trials, with a success chance of .  In our case, , the chance to parry the incoming attack.  Thus, the first term represents the parry-haste we gain if the boss only attacks once during the swing timer and we parry that attack.  The second term represents the gain when there are two boss attacks during the swing timer, and the expression in brackets is the probability that we parry exactly one of those attacks (which is 1 minus the probability that we parry neither minus the probability that we parry both).

The text expressions can be converted to analytic expressions if we define

,

which is the average number of parry-haste opportunities we have in a hasted swing timer.  The chance of having one incoming attack is then just , and the chance of having two incoming attacks is .  In addition, we can substitute in the exact form of since our cases are fairly simple.  This gives us an expression for that looks like this:

and substituting in our expression for , we finally have:

To give you some idea of how big an effect this is, assume a boss swing timer of 2 seconds, a 2.6-speed weapon, and 10% melee haste.  Then , , , and .  That takes a hasted swing timer of 2.3636 seconds and reduces it to 2.228 seconds, on average, or about 5.74% faster auto-attack speed (i.e. 5.74% haste).

What we’ll need for our derivation, in addition to the expression for and , are their derivatives:

and, saving you some algebra on :

If we combine these expressions, and define some abstraction variables, we get

where

Which is what we’ll need to develop our expression for rage generation, which will turn into an equation for the Shield Block cast rate .

It’s important to include parry-haste if we want a reasonable expression for .  Without including parry-hasting, we’d be over-valuing haste by about 10% (, while ) and we wouldn’t have the parry-specific scaling of rage generation that differentiates it from dodge.

In the next post, we’ll tackle the Enrage problem, and tie it together with parry-haste and the warrior rotation developed in this post to complete our expression for rage generation.