Inside a developer...

[jun]

<DIV>Guys/Gals,</DIV> <DIV> </DIV> <DIV>First, I don't work for SOE, nor do I develop on any EQ platform.  But as I have mentioned before, I am a developer/programmer.  I just want to let you know that I haven't met a single developer in 16 years of developing software that doesn't care about how customers feel about their work.  As a matter of fact, the assumptions that we don't care shows how little people really know about us in general.</DIV> <DIV> </DIV> <DIV>We are people just like you.  We take a great deal of pride in our products.  Why?  Because the software we are creating is 'our' work... it isn't something you can pull off of an assembly line and put together yourself.  We pour a great deal of ourselves into our creations.  We place our hardwork, dedication, and good names behind it.  You will not find a single customer of 'my' software more passionate about its growth and achievements as mine are!  Period.</DIV> <DIV> </DIV> <DIV>It is extremely difficult and frustrating for people who are not programmers to understand and grasp all the complexities that go into the software you use.  I can tell you this, if you had half the knowledge it takes to write the software logic, you would eliminate thousands of hours of design/code time from the very start.  The majority of my code in any of my software is something I term as 'defensive code'.  It is the counter-logic I HAVE to program in just to keep people from breaking my programs.  By breaking I mean, to keep people from doing things in the application it wasn't originally designed to do.</DIV> <DIV> </DIV> <DIV>It sounds rediculous, but it is very true.  I have to physically code in error-checking functionality just to ensure someone isn't putting in special characters or letters where the program expects to see NUMBERS ONLY.  In addition to this, I MUST write in even more code to explain to the user what they are attempting to do is incorrect.  As you can imagine, the more complex the functionality the application provides, the more 'defensive-coding' I must write in.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Now take that and apply it to EQ 2.  It is a much grander platform than my simple software solutions, with a much larger (and more vehement) dynamic user base.  The core functionality of the program must be MILLIONS and MILLIONS of lines of code.  What may seem like a miniscule change from your perspective could potentially alter THOUSANDS of different aspects in the program.</DIV> <DIV> </DIV> <DIV>Yes, the majority of these programs are built in sections (modules) and very dedicated teams are responsible for enhancements/changes to those modules.  The only problems is, even if they made your requested changes to the class, they would still have to go through an extensive test period to evaluate how those changes will effect the entire platform.</DIV> <DIV> </DIV> <DIV>So for people to assume developers sit around and waste time developing/enhancing functionality (or classes in this case) that will not be used, they are sadly mistaken.  Give them a little more credit than that.  That's like saying Lockeye is screwing up our fantasy-role playing game because he added an NFL Linebacker class.  He won't do it.  None of the game producers would even sanction something as rediculous as that.</DIV> <DIV> </DIV> <DIV>You would be amazed at how little 'control' the developers actually have over the concept and design of an application.  Generally speaking, its fate resides in the hands of the 'business owners' and the project leaders.  The 'coders' are just the people that program their directives into the software... nothing more.  So if targeting someone for hate threads is what people are after... find out who the project managers are and blast away at them instead of the guys/gals coding their fingers off to present you with this application.</DIV> <DIV> </DIV> <DIV>Myself, I will continue to provide as much positive and meaningful feedback as I can towards the progression of the game.  Yes, I would definately like to take a narrow view and opinionate all my comments with regards to the Illusionist class.  But, as a developer, I know that is not even close to the correct view.  No, our threads and comments will not go ignored forever.  The Devs have acknowledged that there are issues with the class and its abilities.  They have also expressed their intentions to review and provide changes where necessary to improve the class's growth and development.</DIV> <DIV> </DIV> <DIV>Is that going to happen overnight... I realistically doubt that.  Will changes to changes occur... I realistically expect that to happen.  I am not suggesting people fall down and worship the Dev staff at all.  I am saying you should express your concerns for your character's abilities and have the patience to see what effect/change they make will have.</DIV> <DIV> </DIV> <DIV>Personally, I am quite amazed with speed in which changes occur in this game.  Wow, weekly patches on code that must be in the millions of lines, spreading across several departments... simply staggering in my estimations.  Do those guys rate a pat on the back with such accomplishments after a mere year's worth of development?  Heck yeah!</DIV> <DIV> </DIV> <DIV>Point is that getting upset because the changes you expect are not evident in these patches does not mean things are not being done to remedy our class situations.  They take time, in some cases, they take a lot of time.  It simply depends on how widely those changes can affect the entire game.</DIV> <DIV> </DIV> <DIV>PS.  Yes, it makes me sad to see gamers like Manyak and so many others leave the game... we are lessened by their loss.  I am more frustrated that I cannot better explain things and ease the tension of waiting... obviously, it has become too intense for a great many Illusionists to bear.  I only hope you guys will hang on and find a little enjoyment from our class in the meantime.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>VR,</DIV> <DIV>Kailen - 59 Illusionist Faydark</DIV>

[tawek]

<DIV>Junzu,</DIV> <DIV> </DIV> <DIV>As folk will know from my other posts, I agree with you.  Perhaps that's not surprising, as I too am a software developer.  Sometimes, someone has asked what one of my programs does, and, to my embarrassment, my explanation makes it sounds extraordinarily simple ... yet I know the huge effort and emotional investment it took to get the thing working.</DIV> <DIV> </DIV> <DIV>No one but an idiot would regard EQ2 as simple.  It must be a mammoth creation.  I shudder to think of the nightmares the quality people have making sure the many changes don't introduce disasterous bugs.  I can imagine the all-nighter sessions desperately fixing bugs which threaten to undermine the whole game.  I can imagine the intense emotions these programmers have about their creations.</DIV> <DIV> </DIV> <DIV>Then I read posts full of biting sarcasm and personal attacks on these same developers ...</DIV>

[stargazer5678]

Sorry, a bit off topic, but does anyone know what technology they are using to develop?

[Darmash]

Do not mistake the "devs" who define the game mechanics with the "coders" who are the ones who know something about programming. The first ones are responsible for any change in the game mechanism, good or bad, fill the databases with the spells items and recipes data. The last ones spend the long nights on buggy code to try to understand what happens, and honestly some issues they solved looked very very tricky. <div></div>

[Aelore]

EQ2 is definately written (if not exclusively, then at least 95%) in C++ -- my educated guess is that they use a version of Visual Studio for development.  It's very well designed and extremely object oriented  (ie, you will find that most everything is part of a c++ class in some way, although there are simple structs and utility functions used throughout).   I also know that they use the STL (Standard Template Library) a *LOT* throughout the code.  Almost all arrays (including strings) are STL objects. Audio is Miles...and it's DirectX for the visual (whatever the heck version of that we're up to now on that).   I'm also not 100% positive, but I'm pretty sure that the database used with EQ2 is an Oracle designed database (as I KNOW they used oracle for SWG, I'm assuming they did the same for EQ2). That's all I can think of off the top of my head ..hehe. <div></div>

[Impetus]

<span><blockquote><hr>Darmash wrote:Do not mistake the "devs" who define the game mechanics with the "coders" who are the ones who know something about programming. The first ones are responsible for any change in the game mechanism, good or bad, fill the databases with the spells items and recipes data. The last ones spend the long nights on buggy code to try to understand what happens, and honestly some issues they solved looked very very tricky. <div></div><hr></blockquote>Yeah, most of the complaints are not about bugs with our spells, they are about choices that the spell designers make. For example, the root nerf had nothing to do with any bug. It was Lockeye turning down its effectiveness 5 notches. Our stuns and stifles not affecting epics, that's not a bug and has nothing to do with the complexity of the code. That's Lockeye putting in the "does not work on epics" line in all of our spells.</span><div></div>

[tawek]

<DIV>I've been more a coder than designer, but I've done some.  And I can tell you the stress and heartache that goes with coding something can be as nothing compared to designing and managing the whole creation process.  While I have great admiration for the coders of EQ2, the really amazing people are the leaders who've brought it all together, and contuinue to keep it together.</DIV> <DIV> </DIV> <DIV>To make something like EQ2 must take more than professional skill, but a passion for what they are creating.  As people who are passionate about their work, I'm sure they are pleased to see passion on the part of gamers who enjoy it.  But let's keep that passion positive.</DIV>

[Aelore]

Then again, this is how the world works:  if you charge people for a service, they will complain/rebel if they do not like what they're getting.    Granted, it shouldn't be negative; however, there is nothing wrong with a consumer being demanding.   And, frankly, that's mostly what I see on these boards:  consumers demanding for a better product. There is also an issue of the fact that when you have THIS many consumers.  If the load is too demanding to fix what they've been complaining about for almost a year (that's a significant chunk of time), then it is time to hire more help or else replace help with more efficient employees. That's harsh, but that's life in a capitalistic (sp?) society.  <div></div>

[Kurg]

<P><FONT color=#ffff00>@junzu</FONT></P> <P><FONT color=#ffff00></FONT> </P> <P><FONT color=#ffff00><STRONG>I have highest respect for the devs, and I m deeply impressed how great this game is and how beatiful the zones are build</STRONG>... BUT</FONT></P> <P><FONT color=#ffff00>that still leaves me with the question, why they keep nerving us further and further on?</FONT></P> <P><FONT color=#ffff00>And I really think that isn´t the idea from some Coders/Programmers... they just do what they are told to. So it isn´t certainly thier fault. But somebody in SOE must think, that Illusionists and Echanters as a whole are much too powerful and need to be nerved. Which isn´t true at all, as we all know.</FONT></P> <P><FONT color=#ffff00>If they had let the status after LU#13 alone everything was ok. Not that our class would have been without problems and errors - far from it - , but we had the ability to solo quite well and we could help each group we were part of. Raids were always a other topic. </FONT></P> <P><FONT color=#ffff00>So... IF software changes are so difficult and hard to test and so, WHY DID THEY CHANGE US? WHY COULDENT THEY LEAVE US ALONE? </FONT></P> <P><FONT color=#ffff00></FONT> </P> <P><FONT color=#ffff00>~shrugh~ ... I guess I m to stupid to understand</FONT></P>

[zit]

<BR> <BLOCKQUOTE> <HR> junzu wrote:<BR> <DIV> </DIV> <DIV><FONT color=#ccff00>You would be amazed at how little 'control' the developers actually have over the concept</FONT> and design of an application.  Generally speaking, its fate resides in the hands of the 'business owners' and the project leaders.  The 'coders' are just the people that program their directives into the software... nothing more.  So if targeting someone for hate threads is what people are after... find out who the project managers are and blast away at them instead of the guys/gals coding their fingers off to present you with this application.<BR> <HR> </DIV></BLOCKQUOTE> <P>well, seems ppl use the term "developer" in different meaning.</P> <P>from my understanding in context of eq2 the "Devs" actually are the ones who you call "project managers" here. they are the ones who make the concepts for different classes, not the ones who get told to code the spells. so i woud think they have all the control there is. they are not the ones who get told the spell needs changed but they are the ones who decide themselves enchanter AE mez is too powerful and needs nerf.  </P> <P>they still may have some superior above them and get told general base lines like they have to make the game more casual friendly or what ever. but they are the ones who work out the concept as how in detail these changes should look like and what a class should be able to do and what shouldnt, in short what identity a class should have. and for some classes they obviously lack the vision.</P>

[jun]

<P>Kurgor,</P> <P>If my post implied that I thought you were 'to stupid to understand'... you have my apologies.  That was not my intentions with the post at all.  I was simply trying to point out that changes to a 'program' this large were not simple to do.  If anyone else feels my post was a personal attack... please let me know and I will try to make things right.</P> <P>Fortunately for me, I get to wear all the 'hats' in my current employment position.  So I have a healthy respect for just about every function there is in project design/implementation/testing and migration.  Most people on a project only concern themselves with thier piece of the pie.  Coders add/edit source code based on change request forms.  They really don't need to know/understand what that change allows an end-user to do.  They will only become concerned if it breaks the compiler at design time, or possibly creates a run-time error.</P> <P>Project managers (in my estimation) only really concern themselves with time lines, resources and workloads.  They have to make sure coders are making additions or changes where they were specified, in the time frame allowed for those changes.  If something goes wrong, they become the communication hub back up the chain to notify the system architects that a problem has occured that may impact the project timeline.  Even then, someone above the Project Manager must decide what steps need to happen.  Lol... I picture some guy with Microsoft Project Manager as a permanent desktop wallpaper... sliding time blocks back and forth, moving resources around and reassessing the whole timeline on a daily basis. /em hands the PM a bottle of Puerto Rican Rum.</P> <P>So, in steps the System Architects (at least what I call them).  These are the folks that have the overall big picture.  They understand what impact the code break will have in the system.  They know if the release can go forward without the afore mentioned piece of code.  They know if several 'other' critical pieces need to be pulled out (commented out) because the broken piece was dependant upon the others.  The architects are usually able to assess the issue, advise the project manager to reassign more resources (coders) to repair the issue, or simply inform them which pieces of the code that need to be taken out prior to the release.</P> <P> </P> <P>Now, depending on where/when the problem was discovered is also critical.  Did the testers catch it (on a test server) before the migration managers pushed the code to the live server?  Or did the end-users catch the problem on the live server?  The difference is, once the change has made it to the live server... the 'cat is out of the bag' at this point.  A couple of things usually happen... first, end-users discover the 'bug' and report it or exploit it.  Secondly, if the problem appears to affect a vast majority of the system, the servers will go down to get the issue fixed.  Much to our disliking, but none-the-less a necessary evil in order to correct things.</P> <P>If the issue is discovered on the test platform, depending upon the interdependencies of the functionality, it will either be pulled completely out of the patch, or minor adjustments made prior to the patch release.  From my point of view, NOTHING is as important as the test environment (whether it is in-house (modular or integration testing), or the test server end-users play on).  This is the area(s) where ALL defective code, and/or concept distortions should be caught and dealt with prior to any 'Live' releases.</P> <P>Typically, testing is severly limited.  Considering the size and flexibility of EQ 2, I can understand why.  If the program were smaller and much less complicated, a tester could easily test the outer limitations of new functionality with the utmost confidence.  Somehow, I don't think they are able to given the rapid release schedule SOE has.  Quite simply, a new change comes into the system and a test format looks something like this.  The new spell should allow X character to do THIS, and THIS.  It should not allow THAT, or THIS OTHER thing to occurr.  And that is as simple as it gets with regards to testing.</P> <P>I will agree that for the smaller, less dynamic systems, that form of testing would suffice and typically catch a great deal of issues both conceptual and functional in nature.  However, there are far more dynamic scenarios involved in this system that almost negates the benefit of those types of simple testing scenarios.  And because of the vast array of dynamics involved, I would say THAT is the primary reason we (as Illusionists) seem to be nerfed.</P> <P> </P> <P>Honestly folks, with the game complexities as they are, it is almost impossible to determine what the end effect a single adjustment will have in 'every' possible scenario.  Heck, we are but a few that have actually survived the changes to the upper level of our class and WE cannot agree what is the best way to play the class.  Each of us have our own style of play, our own set of hotbars (tailored to our individual capabilities).  That in itself is extremely sexy!  Not in a perverted way, but as in the definition that 'anything that is visually pleasing to the eye'.</P> <P>Point is, changes take time (if implemented correctly) and adjustments to those changes must take place.  Becoming upset at the initial changes (in the case where they seem unnecessarily harsh) is natural.  We develop a personal attachment to our character's abilities and react based on that.  I still hold to the idea that 'whomever' is responsible for the changes is not doing so out of pure malicious intent.  Rather, attempting to find a 'balance' in an ever changing program.</P> <P>As sick as this may sound, I would LOVE to sit in SOE's EQ 2 story board room for a week or so and gain a greater understanding of where Illusionists fit into the game in their present form... and our future one.  I will admit that the complexities of the design intrigues me beyond simple explanations.  But, as I mentioned before, I do not work for them... or any platform they design on.  I don't even know if my skillsets as a professional match their job requirements.</P> <P>I have long since obtained a taste for the bigger picture and would not be satisfied with simply sitting in a cubicle plugging away at my 'specific' lines of code.  I have done my time in the under belly of C++ in the form of insurance quote engines that do nothing but calculate numbers applied to specific state/provincial/federal guidelines.  I have likewise done my stint in the simple UI (user interface) teams adjusting field lengths, page layouts, color schematics (or user-defined where functionally capable), and so on.</P> <P>I guess my greatest joy in development comes from dealing with people like yourselves... the end users.  While the other areas I have talked about are both rewarding and probably financially satisfactory, the feedback from the people I program for has become one of my most sought after rewards.  Anyone with a good managerial skills and multitasking abilities (not to belittle them in anyway) can crunch a timeline to beat a release date.  Not very many people can sit in the 'hot seat' and take the bad with the good when facing the end-users and management.  Weirdly enough, this is where I like to be (its no wonder I chose and Illusionist eh?).</P> <P> </P> <P>VR,</P> <P>Kailen - 60 Illusionist Faydark (Woot!  I ding'd)</P><p>Message Edited by junzu on <span class=date_text>12-05-2005</span> <span class=time_text>01:26 PM</span>

[jun]

<P>"<FONT color=#ffff00>So... IF software changes are so difficult and hard to test and so, WHY DID THEY CHANGE US? WHY COULDENT THEY LEAVE US ALONE?"</FONT></P> <P><FONT color=#ffffff>Sorry, went down a rathole on my previous post.  Most importantly, we are changed like everything else, it is part of the evolution of the game and its abilities.  As for why we couldn't be 'left alone', I can't really answer that without knowing much more about the game.  Perhaps the changes were necessary to our 'future' roll in the game.  Perhaps they were made to recalibrate based on changes to both other classes abilities and/or mob changes.  I can assure you that the interdependencies between the characters, zones, mobs and dynamic events are all entangled.  Its sort of the type of question/answer session you get into in your theology classes in college when the professor asks, 'Do you live ON the planet, or In it?'</FONT></P> <P><FONT color=#ffffff>I for one, prefer to live IN it... having a role in its success or failure in general.  It all comes back to 'how do I fit in?' with regards to the greater scheme of things.  At present, the communication from SOE's representatives and ourselves is somewhat lacking and that 'idea' is not really evident with respect to the changes taking place.</FONT></P> <P><FONT color=#ffffff>So basically, your guess is as situationally relevant as mine is... or any other Illusionist in the forum for that matter.  The only thing I can say is that LU13 seems to be the pivot point for a large number of changes because it was responsible for introducing an entirely 'new' combat system.  How many classes do we have in EQ 2?  How many spells/abilities does each class have?  How do they interact with those from another class?  How do they fit into the new system?</FONT></P> <P><FONT color=#ffffff>Based on the new combat system... How does it work?  What new functionality can be designed to co-exist with it?  What will make it better?  Why the need for a new system at all?  I can take a blind stab at this last one.  The most likely reason for a 'new' combat system is because the old one had too many limitations to allow for future growth in the system.  Honestly, there are only so many layers (wrappers) you can write around old functionality before it becomes so diluted that the designers loose thier grasp of what is and is not possible.</FONT></P> <P><FONT color=#ffffff>A realistic approach would be to design a completely 'new' system that is much more 'generic' in functionality.  This way, you can write coded modules that plug into this generic combat object.  This will allow for much more dynamic growth, and greater flexibility for the future lifespan of the game.  I'm not saying this IS what happened, or WHY it happened at all.  I'm just guessing along with the rest of you. <img src="/smilies/3b63d1616c5dfcf29f8a7a031aaa7cad.gif" border="0" alt="SMILEY" /></FONT></P> <P><FONT color=#ffffff>So for as many why questions as you can come up with, I am certain there are an even larger number of possible answers (if SOE would take the time to explain) could be given.  Based on historical evidence, I don't see that happening often.  There simply isn't time available for the people who 'really' know, to perform both functions.  Which leads us to an inevitable choice, should they 'do', or should they 'teach'?  Given those two possible choices, which would you prefer?  Personally, I would stick with the 'do' path and have the changes progressing to an ultimate safisfatory conclusion.</FONT></P> <P><FONT color=#ffffff></FONT> </P> <P><FONT color=#ffffff>VR,</FONT></P> <P><FONT color=#ffffff>Kailen - 60 Illusionist Faydark</FONT></P> <P> </P>

[jun]

<P>"Then again, this is how the world works:  if you charge people for a service, they will complain/rebel if they do not like what they're getting.    Granted, it shouldn't be negative; however, there is nothing wrong with a consumer being demanding.   And, frankly, that's mostly what I see on these boards:  consumers demanding for a better product.<BR><BR>There is also an issue of the fact that when you have THIS many consumers.  If the load is too demanding to fix what they've been complaining about for almost a year (that's a significant chunk of time), then it is time to hire more help or else replace help with more efficient employees.<BR><BR>That's harsh, but that's life in a capitalistic (sp?) society."</P> <P> </P> <P>So very true.  Customer complaints/requests are the driving force behind the lifespan of any service.  Negativity has its place in the customer forum as much as positive feedback does.  So keep that feedback coming (good or bad) in any form you can possibly give it.</P> <P>Here are my thoughts with regards to your resources .vs workload.  With respect to programming, the easiest fix is not achieved by simply throwing more resources at it.  In this particular case, the more hands in the CAKE, the more PIE you will get as a result.  If you are referring to pulling 'existing' developers over to another issue, while they probably maintain a general 'domain of expertise' in the software, you will still be stealing from Peter to pay Paul.  In other words, you will be prolonging a fix in another area just to get this one done.  The result is generally the same in this situation, someone, somewhere isn't getting their fix done.</P> <P>Pulling in 'new' developers only extends the time frame of the implementation.  Honestly speaking, the ramp-up (learning curve) for a new developer is generally 1 to 2 months per release version.  It is as relevant for a new coder to know 'where' the program started, as it is for them to know where its heading.  So to augment the staff with another body could potentially prolong things (for a period of time).</P> <P>It does take time (some longer than others) for a new coder to be able to get their feet on the ground when dealing with a system as complex as this one probably is.  I am pretty sure that the staff on this project is VERY aware of what their limitations are with regards to new changes .vs bug fixes.  After all, we wouldn't want them to 'stop' coding upcoming changes/expansions entirely and fix some old content.  One realistic view is that they fix things that are outright broken for everyone across the board, then they get into fixes that affect things on a singular level, and so on.  While at the same time, other people are coding away on 'new' content.</P> <P>Any way you choose to look at it, the show must go on.  The program must continue to generate new interest AND revenue.  You have people coming and going as a result of this balance.  You have some happy, while others are upset (to say the least).  Would you be as angry as you are now if (hypothetically speaking) they stopped ALL future development and focused all their resources on resolving existing issues?  Even on content you no longer find a purpose to revisit?</P> <P>So let me get this into perspective.  They are working on 'old' content ONLY.  Nothing towards new expansions/adventure packs.  Just on things that exist now.  You would be happier with that than the possibility of 'new stuff' with fixes to the older stuff as it is possible?  I really find that difficult to understand.  I myself have become irritated that something was not performing as was intended as I was leveling up; But more than likely, I side-lined the efforts with the express intentions of revisting it when it was repaired.  Hence, I have tons of quests that are green still in my journal.</P> <P>Now I find myself faced with another choice, do I delete them simply because the reward is not really worth my time at my present level, with my present gear?  Or do I go back to a grey'd out zone and complete the task for nostalgic reasons alone?  Well, its a personal choice at that time.  Most go back simply because they have reached a point where there is little or nothing left ahead (until the next expansion) and seek something to do.  Others start all over again armed with knowledge of the 'best' quests to complete and zones to play in.</P> <P>So from my point of view (not saying yours is wrong), I would prefer they continue to develop new content, fix the major breaks (on a grand scale) and drive on.  Can I live with Sgt. Whats_His_Name at Gnollslayer's Keep not talking to me and updating a repeatable quest?  Sure I can.  If a rabid bear came down from the woods and swallowed him whole, I probably wouldn't miss a step.  I know that there are NPC quest givers like him a dime a dozen in just about every zone I will enter.</P> <P> </P> <P>VR,</P> <P>Kailen - 60 Illusionist Faydark</P><p>Message Edited by junzu on <span class=date_text>12-05-2005</span> <span class=time_text>01:08 PM</span>

[RpTheHotrod]

<DIV>"You would be amazed at how little 'control' the developers actually have over the concept and design of an application."</DIV> <DIV> </DIV> <DIV>Very true. My brother is a developer, and I work with him on some projects.</DIV> <DIV> </DIV> <DIV>A lot of it is the "big guys" that have no common sense in any form or fashion that call the shots. That's where a lot of the big problems come from.</DIV> <DIV> </DIV> <DIV>Think of it as Saddam coming over to the United States and trying to lead. Things just wouldn't work out. Saddam would have no clue how to run this country. He doesn't even know how it's run. Same thing...you got clueless big heads who have no idea how things should be run, or what makes something good, making all the calls. Half the time, the calls are made to make them money, despite the consequences against everyone else.</DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV>HOWEVER, in EQ2's case... "developers" don't exactly mean the actual coders. Devs often refer to some of the big guys who DO make these decisions. Sometimes, the bigger head guys make the calls for money, but most of the ingame calls, such as balance and whatnot, are made by these "Developers" (again, not the coders...but the actual team lead type people).</DIV> <P><SPAN class=time_text>Another reason why people have little faith in the developers is some of the random stuff that shows up. Example: What, for a long time, has been a major problem for ShadowKnights? They can't keep aggro worth squat. Even lower level "other tanks" out-aggro SK. SK also has lower power than other tanks due to having to spam taunts to merely attempt to keep aggro, which often fails. So, what does the patch do? It nerfs the SK taunt.   Instead of correcting the problem, they make the problem bigger.</SPAN> <P><SPAN class=time_text>They also nerf without consideration of the consequences, evident on the hotfix that was required after nerfing root. If they were smart, they would have realized that every root class is not the same and do not gain the same "overpowered" ability than others. If they were smart, they would have made roots work normally on non heroics, and a chance to break on heroicis and above. As for each class, they should have made root have a higher chance to break according to the damage being dealt. Common sense, really. Example....what do you think would have a higher chance of root being broken? A huge 1500 nuke by a wizard? or a small 21 damage DoT tick from an illusionist?  They should not have the same chance of breaking.</SPAN></P><p>Message Edited by RpTheHotrod on <span class=date_text>12-08-2005</span> <span class=time_text>03:19 PM</span>