Which part of the process of the development goes wrong so that these bugs happened?

b92303008rwb17_ESO

For starters, I am not at all trying to bash anyone here. I am not working in gaming industry but in the past decade I honestly have not seen any major PC video games, whether them being RPG, strategy or simulation, with so many game breaking bugs/exploits/mechanics lasting so long unfixed. There must be something wrong in the process of development and I am really curious about what that is. I believe there are many others that have the same questions as I do.

Simply put, I think the most of the arts, quests designs, music and voice acting are absolutely amazing. These are the main reasons I stick with this game. I also like some of the class and ability concepts and designs even though they are not flawless. So how on earth did so many beautifully crafted elements together turn out to be such a mess as a whole at last?

I understand this game is huge in terms of magnitude or complexity and there are no doubt many talented devs at ZOS. But many other games' devs somehow manage to solve the problems of their equally huge games in a more or less shorter time than ZOS does. How did these equally talented people make so many stupid mistakes?

Let me say this again. I am not bashing anyone here. I just hope people working in the industry or with some kinds of insider knowledge can shed some light on this misery. What do you think?

Xantaria

To me it seems like money is spent on the wrong ends and/or there are communication issues between the Q&A team and the rest of Zenimax. Also a lot of the code for mechanics is probably outdated and doesn't work flawlessly with the newer code which creates new bugs etc. Probably they would have to rewrite the whole combat code to fix everything.

cjthibs

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

PinoZino

lol

sadownik

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

LordSemaj

One possibility is lack of money.

If you can't afford a real software engineer and instead hire a college kid who knows how to script in LUA to work on your prebuilt game engine's fancy GUI while also demanding he hurry up and work at an accelerated pace so that proper testing or debugging can happen, leaving bug detection to QA, PTS, or the players themselves, then you're going to end up with more bugs than someone who budgeted enough money towards prevention.

At the same time, if you're that broke, you probably don't have a high budget assigned to bug resolution. Instead you have the same lone part-time college kid getting hammered by hundreds of complaints about code he didn't even write attempting to frankenstein a solution from what he has to work with rather than waste time and money rewriting the conflicting code segments to work better.

Basically, it's like if your car started leaking oil... you can either pay some guy to take apart the engine, find the leak, replace the pipe, and put it all back together in functional order... or you can tie a rag around the spot it's dripping from and call it done.

cjthibs

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

sadownik

cjthibs wrote: »

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

I appreciate your remarks from professional side which i admit i have no idea about (my only experience with "coding" was BASIC on Atari 65, ah sweet childhood), but there is really something strange about Z. Big company with big project and huge budget and yet, as a long time gamer i can really tell that comparing to other productions both the state at launch and especially the rate at which they deal ( or often rather try to deal) with the problems is lacking (that is a big understatement). Its like they got their software from some derelict alien space ship and they dont have control over it.

Rhakon

I guess it could be outsourcing causing the problems and waiting times for fixes...

They send a problem to india or such other low-wage countries and wait for a fix, then the fix comes back and have to be tested, when they are not satisfied it goes out again.....
When the fix is working it has to be implemented in the actual build, along with other fixes causing new problems combining them.
To foresee this uncontrolled chain reactions is impossible because the separate parts coming from the outside.
This is why it takes so long to fix and change important things in the game.

It seems Zos can only tweak some numbers ingame, but when it comes to code or engine issues they need to wait for help from outside.

maybe this is ***, but i think to find a glimpse of truth in this thoughts.

regards

sadownik

Rhakon wrote: »

I guess it could be outsourcing causing the problems and waiting times for fixes...

They send a problem to india or such other low-wage countries and wait for a fix, then the fix comes back and have to be tested, when they are not satisfied it goes out again.....
When the fix is working it has to be implemented in the actual build, along with other fixes causing new problems combining them.
To foresee this uncontrolled chain reactions is impossible because the separate parts coming from the outside.
This is why it takes so long to fix and change important things in the game.

It seems Zos can only tweak some numbers ingame, but when it comes to code or engine issues they need to wait for help from outside.

maybe this is ***, but i think to find a glimpse of truth in this thoughts.

regards

You might be very right. I was reading some months ago the opinions of supposed employees and former employees and the issue of to much depending on outsourcing was quite commonly mentioned. I wish i remember where i found it.

CapnPhoton

First you say you are not basing anyone...then make a few open ended compliments...then you bash them...then you close by saying again that you are not basing anyone, the whole time not saying what your problem with the game REALLY is...

Was this a satire or something?

CapnPhoton

First you say you are not basing anyone...then make a few open ended compliments...then you bash them...then you close by saying again that you are not basing anyone, the whole time not saying what your problem with the game REALLY is...

Was this a satire or something?

Darlgon

cjthibs wrote: »

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

Ok.. I have heard this numerous times. As a old time 4.0 Netware Admin and PC support guy, I have pretty extensive knowledge of programming in Basic, especially login scripts, and a small knowledge of UNIX and Fortran. (Had to build a Unix to PC interface to get mainframe printing to a PC attached printer, but, thats another story.) I HAVE to ask this, as I have heard what you say for years in many games.

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

b92303008rwb17_ESO

CapnPhoton wrote: »

First you say you are not basing anyone...then make a few open ended compliments...then you bash them...then you close by saying again that you are not basing anyone, the whole time not saying what your problem with the game REALLY is...

Was this a satire or something?

I think I exercised self control when criticising and there is really no point in specifying what flaws the game currently have since it is quite obvious on the forum. I was hoping to see some technical comments or insider knowledge when I made this post. Simple as that.

jcasini222ub17_ESO

One thing i've been always curious about is why we don't have an 'open' testing enviroment. Take for example the battle spirit change along with battle leveling. In an open running test enviroment you could have played around with the setting, try one, try the other, try both. It would be possible to try out different blocking regen rates. You could mess with skills, really try things out and they never need to make it to live necessarily but to try out ideas on what (I assume just based on pts and the beta's) would be a larger sample pool than their internal testing group. If the idea doesnt work so be it, its just a test enviroment. I much rather gamechanging or gamebreaking bugs be caught in a testing enviroment than live.

Nothing against their testing group or saying players could do a better job. Just flummoxes me why an open testing enviroment isn't utilized.

Mojmir

jcasini222ub17_ESO wrote: »

One thing i've been always curious about is why we don't have an 'open' testing enviroment. Take for example the battle spirit change along with battle leveling. In an open running test enviroment you could have played around with the setting, try one, try the other, try both. It would be possible to try out different blocking regen rates. You could mess with skills, really try things out and they never need to make it to live necessarily but to try out ideas on what (I assume just based on pts and the beta's) would be a larger sample pool than their internal testing group. If the idea doesnt work so be it, its just a test enviroment. I much rather gamechanging or gamebreaking bugs be caught in a testing enviroment than live.

Nothing against their testing group or saying players could do a better job. Just flummoxes me why an open testing enviroment isn't utilized.

isn't this what PTS is for?
not implying specifics but,
IC was on a test for a month, feedback was given.from what I read a lot of feedback was ignored.

jcasini222ub17_ESO

PTS is a good start but I'm talking more of an open ended test enviroment where changes can be applied not only with 'game update' in mind but general game in mind. So they can tweak and adjust whenever they please not as dependant on hard release times. Just the battle spirit/battle leveling changes I think could have used their own months of testing time.
Or

For 2 weeks try out blocking without regen
Another 2 weeks blocking with 25 percent regen
Another 2 weeks at 50 percent regen.

I honestly don't expect them to make sweeping changes in the span of a month, retool alot of stuff and for it to go smooth.

Under an open ended testing enviroment whenever they feel like 'hey maybe we should address x' they can go and try out their idea.

In a month frame getting it to 'work' is more important than getting it to 'work properly'.

Hopefully thats clearer

Darlgon

Mojmir wrote: »

jcasini222ub17_ESO wrote: »

One thing i've been always curious about is why we don't have an 'open' testing enviroment. Take for example the battle spirit change along with battle leveling. In an open running test enviroment you could have played around with the setting, try one, try the other, try both. It would be possible to try out different blocking regen rates. You could mess with skills, really try things out and they never need to make it to live necessarily but to try out ideas on what (I assume just based on pts and the beta's) would be a larger sample pool than their internal testing group. If the idea doesnt work so be it, its just a test enviroment. I much rather gamechanging or gamebreaking bugs be caught in a testing enviroment than live.

Nothing against their testing group or saying players could do a better job. Just flummoxes me why an open testing enviroment isn't utilized.

isn't this what PTS is for?
not implying specifics but,
IC was on a test for a month, feedback was given.from what I read a lot of feedback was ignored.

TECHNICALLY, Zos uses an internal test group for that, their employees and Q&A. (remember the remark on ESO Live about them testing controler/PC interface?) That said, its been since Beta since i heard of an Alpha test of the game mechanices before it would hit PTS. The PTS test.. sigh.. frankly, not sure why they bother. To make sure the game does not make players unable to login? We know the load tests of Cyrodiil are a joke, since it runs on a smaller server. The things they change from that... i never understand how they picked to fix small stuff and leave huge bugs and known exploits for 9 months or more.

Yolokin_Swagonborn

Their Quality Control system is just not robust. In most industries, launching a product with a known defect is a huge no-no. You can get your entire accreditation pulled for a stunt like that. Here it seems to be par for the course.

But building a robust quality system is tough for any business in any industry. More resources are always spent on the value-added parts of production and less on quality assurance. ZOS seems to be in the news all the time for firing quality and other staff. It shows.

There is also a difficult quality/customer service loop that I can tell is lacking. You have to be able to capture issues as they come in (from a vast number of sources in this case), catalog them, categorize them in terms of severity, then put them back in the production pipeline to be fixed, then follow up to see they have been fixed. This usually takes a robust system, training and protocols to function. Most companies don't have a system for this. They have a person for this. All the problems land in one person's lap and they are responsible to work with all the different teams to get fixes. Every functional team also has a person dedicated to handle incoming internal issues and this flaw is duplicated. Some people are more receptive than others, and it just becomes a very inconsistent mess.

Trying to change quality assurance from a people oriented process to a procedural one is like pulling teeth. trust me. But without a good system, very well meaning people are quickly overwhelmed by the sheer mass of problems that can occur.

LordSemaj

Darlgon wrote: »

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

Programming has evolved well beyond this, old timer. Rather than relying on goto lines, object-oriented programming lets anything interact with anything. Game designers usually go even simpler and use lightweight script languages that perform the complex routines under the hood and give the game designer simple procedural syntax like "AddNewPlotFlag" calls or the common display methods, all of which would be way more advanced if you were interfacing with the monitor directly like an operating system.

So effectively, the entire program can be a subroutine of itself and that can lead easily to crashes. Modern programs work more like the Internet with each function being its own IP address with a cloud of information getting shared back and forth between them. In fact, TIMING can be an issue due to dependent threads running concurrently, but luckily that's a matter for the software engineers building the game engine and not the dime-a-dozen quest makers.

JamilaRaj

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

The question was not, however, why is bloody mess hard to maintain, but why is the code apparently such bloody mess.

PinoZino

It's like a complete noob who's suggesting the neurologist to tackle the Amygdala first during some brain surgery.

But hey, some inmates want to run the asylum.

tordr86b16_ESO

I wouldn't be surprised if they outsourced much of their work to 3rd world countries. It's not theory but fact, heard them talking about language barriers from outsourcing on one of their ESO Live episodes.

Darlgon

tordr86b16_ESO wrote: »

I wouldn't be surprised if they outsourced much of their work to 3rd world countries. It's not theory but fact, heard them talking about language barriers from outsourcing on one of their ESO Live episodes.

Guess I missed THAT one.

PinoZino

tordr86b16_ESO wrote: »

I wouldn't be surprised if they outsourced much of their work to 3rd world countries. It's not theory but fact, heard them talking about language barriers from outsourcing on one of their ESO Live episodes.

Those people their English is usually good enough present times.
And they all have more than one liaison officer.

Worked several time on projects with dev teams in USA, Europe and India. When one went to bed, the other waked up and continued analyzing and developing. With a solid methodology and nice management software it is no big deal anymore.

Btw, you can have 'language' and ‘cultural’ barriers inside a single building of a company too.

Everyone who have worked in an office can testify that often the left hand doesn't know what the right hand is doing, that they don't speak enough with each other and sometimes use another jargon, style or approach.

Peel_Ya_Cap_517

Darlgon wrote: »

cjthibs wrote: »

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

Ok.. I have heard this numerous times. As a old time 4.0 Netware Admin and PC support guy, I have pretty extensive knowledge of programming in Basic, especially login scripts, and a small knowledge of UNIX and Fortran. (Had to build a Unix to PC interface to get mainframe printing to a PC attached printer, but, thats another story.) I HAVE to ask this, as I have heard what you say for years in many games.

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

Hey, this guy installed a printer one time, LISTEN TO HIM!

cjthibs

Peel_Ya_Cap_517 wrote: »

Darlgon wrote: »

cjthibs wrote: »

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

Ok.. I have heard this numerous times. As a old time 4.0 Netware Admin and PC support guy, I have pretty extensive knowledge of programming in Basic, especially login scripts, and a small knowledge of UNIX and Fortran. (Had to build a Unix to PC interface to get mainframe printing to a PC attached printer, but, thats another story.) I HAVE to ask this, as I have heard what you say for years in many games.

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

Hey, this guy installed a printer one time, LISTEN TO HIM!

I'm pretty sure you have absolutely no idea what he just said.

Peel_Ya_Cap_517

cjthibs wrote: »

Peel_Ya_Cap_517 wrote: »

Darlgon wrote: »

cjthibs wrote: »

sadownik wrote: »

cjthibs wrote: »

Art and the logic that drives the game can't really be compared in terms of complexity.
Art, when finished, is finished, it isn't going to break other parts of the game because it's static, code on the other hand is constantly evolving and interacts with all of the other code.

Whenever you're dealing with code, be it belonging to a game or business software, you're dealing with a large set of logic statements that are constantly looping through and will interact with each other in ways that aren't anticipated.

Debugging is not a simple, 'Oh there it is, now it's fixed.' Often you have to isolate bits here and there and figure out exactly why things are behaving the way they are. Quite often the reasons things behave in weird ways are not obvious, and they are not explicitly written that way. It may be caused by something way down the line that, at first glance, has nothing to do with the process it is breaking. And even when there is a simple fix, that fix may cause this entire process of unintended behaviors to start all over with another process.

What you're really dealing with is a huge web of interdependent logic statements that are impossible for one person to fully understand.

Well and? I think any person withaverage intelligence knows that coding can be difficult, but OP was asking why ESO stands out so much in terms of quiality controll.

Your otherwise insightful message reminds me of my ex - asked her why she cheated on me and got a long speach about realtionships in generall.

How am I supposed to know that? I don't work at ZoS. Nobody knows how their specific process works, unless they've seen it in action. In fact, it's a bit pointless to speculate about it.

As someone who does deal in a similar arena, 90% of the people I see posting here on matters relating to the code itself are the worst kind of users. Development/Design is one of the most thankless jobs out there precisely because no one understands it outside of that arena. They assume that it is not -really- that complex, and every fix should be able to be rolled out same-day.

There is nothing in this world more irritating than someone who has never looked at the product you deliver from the inside yet still has the gall to suggest how you should fix a problem and set timelines for you.

Do I think anyone deserves a free pass? No, but I have also seen situations where a bug, in some unintended way, is actually making the rest of the program work. Where fixing said bug will cause a cascading failure, or cause completely unexpected issues down the line somewhere, and a rewrite of many subsystems is necessary in order to fix the bug and save the program. (Among other oddities.)

In the end we've got to accept that ZoS is capable and is working on these issues. Doing anything else will drive you crazy because what you're really doing is investing yourself in something you've got no control over.

Provide valuable and meaningful feedback, and leave the actual work to them.

Ok.. I have heard this numerous times. As a old time 4.0 Netware Admin and PC support guy, I have pretty extensive knowledge of programming in Basic, especially login scripts, and a small knowledge of UNIX and Fortran. (Had to build a Unix to PC interface to get mainframe printing to a PC attached printer, but, thats another story.) I HAVE to ask this, as I have heard what you say for years in many games.

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

Hey, this guy installed a printer one time, LISTEN TO HIM!

I'm pretty sure you have absolutely no idea what he just said.

Hey, this guy also understands how to install a printer, LISTEN TO THEM ZOS!

PinoZino

Darlgon wrote: »

Ok.. I have heard this numerous times. As a old time 4.0 Netware Admin and PC support guy, I have pretty extensive knowledge of programming in Basic, especially login scripts, and a small knowledge of UNIX and Fortran. (Had to build a Unix to PC interface to get mainframe printing to a PC attached printer, but, thats another story.) I HAVE to ask this, as I have heard what you say for years in many games.

Is the problem that the code is all twisted up? I mean, we were taught to take our code, put it in sub categories and subroutines to make it easier to troubleshoot. Your description makes me think that standard coding practice is make line 1 go to line 1099, which says, go to line 14099, which says go to line 25999, which then says go to line 2.

Present times they have stuff like Object-Oriented Programming.

They don't do 'goto 14088' anymore, more likely it is something as 'boss.startfight()'.

And next to the beauty of OOP, they have fantastic tools to track, debug and test errors.

Trust me, their task is a bit more complicated as connecting a printer.

Darlgon

LordSemaj wrote: »

Technical answer to a technical question, that obviously the plebe on the street would not understand.

PinoZino wrote: »

Another technical answer to a technical question, that obviously the plebe on the street would not understand..

Thank you both. This is why I asked Will Burton, the programmer they had on ESO Live #24 which languages he programmed in. When I "look under the hood", i look deeper than the OOP, which of course is beyond something us users at home can see. (He uses C# C++ PHP Python and Java, btw. Visual Studio and Sublime are applications he uses. ) Will was, btw, such a refreshing contrast to Rich on this last broadcast.... Oh well, that horse has been beat to death.

The question of, which part of the process where this goes wrong?, the thread title, may not be visible at the OOP level, which is why it takes so long to fix things. It may be a flaw in the underlying software, and not visible at that level.

HOWEVER, from a management view, there should be flowcharts, or logic diagrams. Some kind of documentation... that almost seems to be missing. Comparing the snowballing bugs may reveal a common flaw that needs to get fixed on that level, which ties all these objects together. And, naturally I cant pull Will up to ask him. Sigh.. Oh well, enough of a detour into the base code.

Back to your regularly scheduled hand-wringing and chest-beating.

Belidos

b92303008rwb17_ESO wrote: »

For starters, I am not at all trying to bash anyone here. I am not working in gaming industry but in the past decade I honestly have not seen any major PC video games, whether them being RPG, strategy or simulation, with so many game breaking bugs/exploits/mechanics lasting so long unfixed. There must be something wrong in the process of development and I am really curious about what that is. I believe there are many others that have the same questions as I do.

Simply put, I think the most of the arts, quests designs, music and voice acting are absolutely amazing. These are the main reasons I stick with this game. I also like some of the class and ability concepts and designs even though they are not flawless. So how on earth did so many beautifully crafted elements together turn out to be such a mess as a whole at last?

I understand this game is huge in terms of magnitude or complexity and there are no doubt many talented devs at ZOS. But many other games' devs somehow manage to solve the problems of their equally huge games in a more or less shorter time than ZOS does. How did these equally talented people make so many stupid mistakes?

Let me say this again. I am not bashing anyone here. I just hope people working in the industry or with some kinds of insider knowledge can shed some light on this misery. What do you think?

Firstly, there are almost no "game breaking" bugs in this game, people use that term way too much (mostly to describe something they don't like about a game that they don't personally like), a game breaking bug is a bug that stops you from playing full stop, there are the odd reports of people being unable to play, but it's quite rare.

Secondly, if you have not seen in the last decade any major games that don't match or exceed the number of bugs this game has, then all I can say is try playing some other games because they're out there, and they're out there by the dozen.