-
Posts
4 -
Joined
Reputation
10 GoodPersonal Information
-
Location
Winnipeg, Manitoba, CA
-
Interests
Programming, Law
-
Occupation
Programmer
-
The thing about PvP that irks me more than anything else is the bias against healers. Forget about everybody else, OK. One 'toon. Healer spec, healer gear. The exact same expertise gives me AS A HEALER, twice as big a damage bonus as healing bonus. That has absolutely nothing to do with gear, the nature of the battle, or the abilities of allies or enemies. That's BUILT-IN SYSTEMATIC BIAS - specifically against healers. In the Popular MMORPG That Shall Not Be Named, they had it right. Player on player, one on one, matched gear, a healer could make a DPS work for it. In a solo duel, a healer could drag the fight out for a solid 20 minutes - and even win if they were a little more skilled or caught a lucky break. Not a death machine by any stretch, but a match for certain - they couldn't win by sheer force of arms, but they could wear the enemy down by just out-surviving them. Not so in SWTOR. In SWTOR PvP, healers are worthless and weak, and the PvP game is SET UP to make them that way. One on one, a healer doesn't stand a chance - even briefly. Healers get butchered on PvP token distribution, too, so it even takes longer to gear up. Check any battle summary sheet you want. The healers are down there in the bottom half - no matter how well they did or how well the battle went. So the question, I suppose, is this: What problem does Bioware have with healers in PvP? It has to be something for them to bias the entire PvP system 2 to 1 against healers, so what is it?
-
I'm fairly certain these exist somewhere, but I would really like to see them available for viewing. I'd like to see statistics on attempts/kills, by boss, by operation, by type. So, for example, EV Story mode 8 and 16 man, Hard mode 8 and 16 man, and Nightmare mode 8 and 16 man for each boss in each operation, post total attempts versus total kills, ideally by week. The reason I would like to see this specifically is because A) I'm certain the data already exists somewhere, and B) I'm pretty certain that it would be wildly skewed in some places. For example in Karaga's Palace, I'm certain that the Fabricator attempts/kills ratio would be considerably higher than for *any other boss in the instance*, at any level. In Eternity Vault, I'm pretty sure Soa would be likewise skewed, but not as badly. Now, upon seeing the data, if the Fabricator's stats are somewhat higher than the other encounters, but only by say 25%, then that could just be a more difficult encounter - perhaps designed that way. If those stats reveal a discrepancy of 300 or 400%, though, that's not a *difficult* encounter - that's a *broken* encounter. Something is wrong with it and it needs to be fixed. This would also benefit the game itself. If those statistics showed one encounter wildly out of whack, then you have empirical evidence that it needs to be fixed - there's something wrong with it. If the community could see that data as well, I'm pretty sure you would get a lot of suggestions about exactly what is wrong with the encounter. I'm pretty sure that the vast bulk of those suggestions would focus on one or two particular things. With that kind of feedback, your game designers would know exactly where to focus their efforts, as opposed to what I believe is happening right now - just hoping the problem will fix itself, or randomly tweaking things here and there in an attempt to find what is wrong by essentially throwing darts at it. Or the worst possibility - the thing is simply being ignored because there's no hard proof that something is wrong in the first place. Having specific things to look at could speed up the correction process significantly, thus improving player satisfaction with the game, and decreasing the amount of effort Bioware programmers had to commit to trying to correct the issue. In the case of patches, if such data were summarized and collected on a week by week basis, it might even aid in bug-tracking and debugging efforts. If one boss has historically been running at an attempts/kills ratio of say five to one, and after a patch that suddenly jumps 200%, then that's pretty good empirical proof that the patch broke something in that encounter. Again, the community could assist in determining exactly what it was. In short order, the bug could be localized in time and space, and perhaps even isolated to a specific phase or mechanic. Suddenly the programmers know exactly where to look. In fact, as a programmer, given that level of detail I would probably be able to tell you within a class or two exactly where it was, and perhaps exactly what it was - assuming I knew about it in a timely fashion. Give me the exact same information a month later instead of a week later, and there's a pretty good chance by then I've been into so many other things that I haven't the vaguest idea where to even start, and I'm looking at a week of grovelling through the code-base just to remind myself what I was up to. That's the benefit of statistics. My raid group might face that broken encounter on four successive weeks before we were sure it was broken. But we're not the only raiders. If 500 raid groups experience the same problem in the first week, they can't tell each other about it easily, but the numbers can tell the overall story for them. The sample size is large enough to make a valid statistical deduction. Once the raiders all know that the encounter is broken, they can probably give good intelligence on exactly why in short order. Left to themselves, however, a single group would likely write it off the first couple of times as a fluke, or a glitch, or maybe a network problem. It could be two or three weeks before it became obviously persistent enough to be perceived as a genuine issue. What do you think? Depending on complexity, it may be possible to extend the data to Flashpoints, but the problem with Flashpoints is that I can take my L50 into Esseles and run it solo with no problem - the data might be skewed. Hard Mode Flashpoints, on the other hand - there it might be useful as well.
-
5 Changes that should be made to SWTOR (Constructive Thread)
YrthWyndAndFyre replied to Zybak's topic in General Discussion
In the Raid-Frame style of party frames, it would be cool if any companion pets showed up in that raid-frame, too. Right now, the only companion pet I can heal easily is my own, but normally the tank wants his pet out. The only way I can heal it is to find it, click on it in the pet in the display, and then heal it. That takes way too much time so it's usually necessary to just let the tank's pet die. Then the tank gets mad, and since he's not a healer, it's hard to explain that his pet is expendable while mine is not simply because I have a targeting frame for my pet. I can target and heal it in a second, while for his, I have to run up to it (usually), change my view to be looking almost straight down, click on it, heal, then change my view back and resume normal healing - all tolled it can take upwards of 8 seconds. Without knowing the specifics of how those raid frames are programmed, it seems like it would be a simple enough change. In the regular frames, the party member's pets show up. -
5 Changes that should be made to SWTOR (Constructive Thread)
YrthWyndAndFyre replied to Zybak's topic in General Discussion
I'm so tempted rant and rail here, but I will try to keep a civil tongue, so bear with, please. First, Interface Design 1.01: 1) Yes/No, True/False type buttons should *always* be oriented in exactly the same way. True/Yes on the left, False/No on the right or vice versa, it makes no difference as long as it is always the same in every dialog that uses that type of response system. Mixing it up just causes problems. People get used to them being in a particular order and if that order ever changes, people wind up doing bad things to themselves by reflex. 2) Having said that, you never place the "I want cookies" button right next to the "Kill my pet cat Sniffles" button. If the effect of two buttons on the same dialog are wildly disparate (I/E one very good, one very bad) then put the two buttons as far apart as possible, to reduce the chance that you will die of a mis-click. On Bonus Quests: I've seen any number of quests where all of the objectives are spelled out: Kill 10 of these, 20 of those, and collect 8 of that. Nice and simple, and you can complete the elements in parallel. It's nice. Then there are the staged bonus quests where you must 1) Kill 10 of these. Then 2) kill 20 of those. Then 3) Kill 15 more of these. Then 4) Collect 5 of that. Then 5) Kill 2 of the other. And on and on and on and on and on. And before you say, "Quit repeating that, it's stupid and redundant.", welcome to the point:rolleyes: It's hugely frustrating, because you finish an objective and get the, "Ah, done!" high, then BAM! Nope. Sorry. Not done. More to do. Back to the grind, slave. After about the third one, the thing going through my mind is, "Is there an end to this?" It's a mechanic put in place specifically to *punish success*. Or specifically to waste time. Either way, it's not fun. Its also a mechanic that basically forces you to go through the same area killing the same things over and over again for no reason. If there are several people doing it at the same time, then it's a huge time-waster, because some people are killing things just to get to early stage items that you actually need to kill to finish later stage items, so they're killing your objectives for the sake of *convenience*. It would be nicer if they were like the quests where all of the requirements were specified up front and you can do them in parallel. On Chain quests: This is another mechanic borrowed from the MMORPG that Shall Not Be Named. You pick up a quest, travel all the way across the zone and complete it. Then you go back, two more quests are available - and they're in the same area you just left. So you go all the way back across the zone, do the next two, go back and turn them in. Then three more quests pop up that are the same. For heaven's sake just give all the quests for the same area at once, so we can go there, do them all, and come back. Running cross-country is not, to my mind, "play". It's just time-wasting. To a certain degree it is necessary to maintain the integrity of the environment, but be-bopping back and forth across the exact same turf over and over again is just tedious:( The strange thing is, in many places it's done exactly like that. If you're headed to an area, all of the quests for that area are available before you leave. But in other places (Tatooine Bonus Series comes to mind) they're set up as chain quests, so you basically spend an hour speeding back and forth between the town and the objective zone over and over. On Ganking: There are innumerable places where you must pick things up that are guarded. Typical scenario: You run in, engage the guards, and while you're defeating them, somebody cruises by and grabs the thing that you were trying to get. You can't get the thing because, "You can't do that while in combat." I've had to kill the exact same set of guards four times over to get something just because people were ganking the objective while I was in combat. Would it not be possible to tie those objectives to the mobs, so that only the person fighting the mob can pick it up for 60 seconds after the guard-mob is dead? That way if I don't want it, somebody else can take advantage of the fact that I left it unguarded for them, but if it's my objective, then I have a reasonable chance to take what I rightfully earned. Or, alternatively, allow me to grab the item while I'm in combat. Then I can engage the guards, have my companion hold them for the two seconds it takes to claim the objective, then finish the guards off. Either way, it would provide a means by which these thieves could be thwarted - and yes, that is what they are - thieves. There are nice honorable people who will respectfully stand aside and wait until you leave before they take it for themselves, and others that will sweep in and grab it while you're clearly *heading over to pick it up*