yes, i wont.
after 2 weeks where i spent 4 hours a day to look for a bug in a matlab code, i may finally found it... after 2 weeks, 4x7x2 = 48 hours of debugging, losing sleep thinking to then find the "error". And even now i still dont know why 3 lines of code, the most simple ones you can imagine are doing that.
bugs are strange and when you are payed, 48 working hours for a simple bug arent accepted.
i wont ever again complain
0
Comments
There is an old story about an retired engineer helped fixing an equipment of his old company. An equipment of his old company was malfunction and nobody could figure out what the problem was So, they got this retired engineer to come back to help. He fixed it. In his invoice, there were 2 items:
1. $1 for replacing a s_crew.
2. $4999 for knowing where to find that s_crew.
And sometimes, fixing one bug, creates 5 new bugs. Some of which may be even worse than the original bug.
Any of my comments not posted in orange are based on my own personal opinion and not official.
Any messages written in orange are official moderation messages. Signature images are now fixed!
RIP Real Tiamat, RIP Real Demogorgon RIP real Temple of the spider. Why remove non bis content to give to bis players ????
FORCING the majority of your player base to play 4 mod old dungeons and trial will have a bad result on player base
Changes are getting so bad i would rather prefer no new changes (RIP ICE FISHING in winter fest)
Having said that, it is nigh on impossible to produce code that is bug free. The industry average is roughly 15-50 bugs per 1000 lines of code (KLOC). Some bigger companies, who have oodles of people to throw into code reviews, testing, process development, etc. have managed to get that down to 10-20 bugs per KLOC before final acceptance testing and in some cases as few as 2 bugs per KLOC released. Then there are a few companies that have gone way beyond where the results of an error are life threatening (think Space Shuttle) that have achieved error rates as low as 0 errors in 500 KLOC. Not that there are still no errors mind you just very few.
The lower rates are achieved by HUGE amounts of testing and retesting and reviewing and re-reviewing and then reviewing again and then testing again. All of that takes enormous amounts of time, resources and money (money as in not for free).
Bugs are NOT the result of crappy coding in most cases. Bugs are a result of a situation that was not considered when the specification was written. Once code is released into the wild and all kinds of deviants get ahold of it and do things to it that you would never consider a sane person doing, those situations come to light. Of course at that time it is very time, money, resource consuming to fix the issue. All very well if you have nothing else to do with your day but fix those problems, but if you are developing more content, that tends to consumes those very same resources that are needed to fix the errors. Solution: Get more resources! Resources cost money (again money as in not free)!
Of necessity if you want to have a F2P game you are not getting oodles of money so you have to allocate the resources to where you are going to see the most income from those resources (think basic economics in the world). Do you get more money from fixing a bug that is somewhat a nuisance or do you get more money from new content?
The argument is "Yeah, but people leave if there is a bug." True, you are correct sir! But, the rebuttal, if 10 people leave because of a bug and 100 people join because of new content, where do I put the resources? As long as the bug does not make the game unplayable, with the above scenario, you put the money in new content.
Now as far as Neverwinter goes, you have to have a relatively small development group, testing group and review group because it is F2P. There is no room there for huge amounts of testing and reviewing. There answer, preview shard!!!! Have the deviants that are going to be playing it test it! Great, but even if they find every bug out there, you still need resources to fix them and where is the money? Fix a bug because a TR has a drippy nose or release new content?
Next argument, there is no new content. Once you have a dungeon, every other dungeon is the same thing with different skin and different stats. HE, dungeon run, new monsters, new gear, etc. All the same as the old stuff with new stats and new skins. EVERY game out there is the same way. World of Warcraft, Elder Scrolls Online, Everquest...every new release is just the old content with new skins and new stats. Once the mechanics of the game are set there is usually little new variety. It is the nature of the beast.
So why don't they sit down and come up with some innovative new content. Goes back to the money. Are people more willing to sit through new skins and stats or do they want something innovative? Innovative the users scream! Guess what you are now at the beginning of your development cycle again and you have to go through all of that again. Reskinning and restatting take far less time and since you are reusing existing code, fewer bugs as a result.
Write a few tests to test out the error trapping. Errors are what you expect to happen when you code. See above, most bugs are from unexpected occurrences, not expected ones.
Multiple all this by millions of lines of code and you can see the issues that a development team are facing.
Sorry to get so wordy, but there are 1000s of posts spouting off about "Why don't they fix XYZ?" and people need to understand that it takes time and money to fix these things. In a F2P environment, neither of these is in great supply.
Just my 10 cents worth, flame on!
The second problem might be when you must search through an operating system's worth of code to find something to be fixed.
The third problem might be that it takes days to fix three lines of code.
In any case, this isn't my problem. Assuming this is an any way accurate, they need to be more efficient with their code.
I must say in my company our whole development team will loose there job if we let through the amount of errors that this company does. Not to mention the lack of repairing it in time.
Letting your customers suffer through bugs cost company money. We code for the Government that means financial penalties, so we cannot afford to have our clients have any down time or cannot just say we will remove this feature(dungeons) and add it back at another time. That will cost the company $100 000's. Yes that is the types of fines we get hit with. We had to delay(simular to Strongholds) a project release for 1 week, that cost the company $15 000 per day on late fees.
So yes money does influence the dicision making process, but the development team that does not properly follow the SDLC will cost the company more money(Hence the mass exodus in this game).
As for unforseen items coming up. If there is a strong project plan these unforseen items will not be in the project plan and thus should not be implemented.
This is not a flame and yes me and my team do alot more than hello world apps. We code and maintain projects written in C,C++, Assembly(very often, mostly when working with farming hardware), C# ,Java (i hate it ... think it is for amateurs) with mainly Ms SQL and Oracle for databases. We are not an inhouse team that are allowed to ignore certain protocols just to get the product to market.
RIP Real Tiamat, RIP Real Demogorgon RIP real Temple of the spider. Why remove non bis content to give to bis players ????
FORCING the majority of your player base to play 4 mod old dungeons and trial will have a bad result on player base
Changes are getting so bad i would rather prefer no new changes (RIP ICE FISHING in winter fest)
this would be understandable if there were actually new content. and not just a bunch of cutting and pasting.
Fortunatly, this mod looks like someone did his homework. :-)
4x7 = 28x2 = 56 hours
No suprise you didn't find the bug.
Great post man, kudos!
What vjarl wrote is the rhetoric of failure.
The NW game coders - the actual people coding the game - aren't just "crappy coders". They are people trying to keep their jobs by building what they're told to build, using the tools that were already in place and running long before any of them joined the team. Which is why the story told by @plasticbat and the post by @kreatyve are so relevant.
"That is if the code was well written and documented from the start." Right - error trapping, development plans and "test driven development" are great for a team that has the luxury of documentation, maybe a project manager who knows why certain things were done in the beginning, and client with a clear focus on what the end result will be. I just don't think that's the case here.
**disclaimer - this does not mean I will fail to complain about any bugs in the future, but only if they affect me.
Another problem coders run into is things can work perfectly in a preview or beta test, and then when it goes live there's some little screw up somehow that produces a bug. That's what drove me the most nuts when that happened, and then the complaints came in about how it was "supposed to have been fixed". It was, just the fix didn't carry over for whatever reason in the universe.
Translating working code between Windows and Linux was worse. That made me cry when it wouldn't work.
Then there are the bugs that occur that you never would have thought of such as "this door blocks you from running through with the code that only allows you to open it when out of combat, BUT if you stand on this rock facing that column then do a backwards jump you can shave off 5 minutes of this dungeon anyhow".
There are people out there that enjoy "breaking" everything possible just to see what can be done, or get some sadistic joy out of being able to complain about bugs.
Keep reporting bugs through appropriate channels, certainly. A small complaint can alert Devs to a real problem. Just always use a please and thank you if you would be so kind?
Thanks.
"Why is it dragons only use ketchup? I'd like a little wasabi please. Us silvers like a variety of condiments."
"Don't call them foolish mortals. One, they don't learn from it. Two, It just ticks them off." - An Ancient Red Dragon
Unleash The Wolves- HR Lvl 70 (PVE)
<font color="Aquamarine">"Non-Pay-To-Win"</font>
I hunt GWF "Magik" on sight.
1) team size
2) with how many games team working.(publishing.
3) QA, testers. After all test servers are area where most bugs should be traced and fixed before they slip to live server.
Next, all games looks nice when u didn't play them. Give me at least one mmorpg game where forum are no threads about bad class balance, game is too bugged/broken. And also statements like ,, Other games have less buggs and so one..
As for topic..
Guys, The team who manage this game are not some kind random guys.
“The masses have never thirsted after truth. Whoever can supply them with illusions is easily their master; whoever attempts to destroy their illusions is always their victim.
Gustave Le Bon.
==================================================
Was and is a nice game...
Left because bots took over...
The answer seems to be: go where the money goes. Is it enough? No it isn't.
Every new module attracts less players than the previous one: this is clearly reported here (the Steam population can be considered a good sample of the overall universe)
http://steamcharts.com/app/109600
If you read the Steam data and you know a bit about system dynamics, then you can see some analogies.
The system dynamic archetype is called "Attractiveness principle" (https://en.wikipedia.org/wiki/Attractiveness_principle).
The Reinforcing Loop = "release new contents/modules" -> New players (proportional to + revenues)
The limiting factors are "bugs/low quality" and "content recycling/deleting/nerf"-> Players quit (proportional to - revenues)
The red line in Figure 4 shows how it works, but you have to apply heavier weights to see the overall smooth but constant negative trend: every new module attract new players, but the difference between the number of new players and number of quitting players is negative and this negative gap increases at every module release at different pace...at the end you have the steam chart on the long run.
The next limiting factor will be the incoming OP/DC/lol set nerf...it will be interesting: in my guild 4 (paying) players have already announced that they quit the game the day it goes live (they invested a lot in their builds/toon and the nerf has a negative RoI for them).
"
Effective strategies
Here is a list of possible effective strategies to deal with Attractiveness principle in praxis based on
Knowing the growth is limited is the first step.
The insight is complicated by mutual interaction of limits, so analysis of their relation should be a priority. Such an analysis can also reveal possible synergies that can be achieved by allocating resources to carefully chosen limits.
Consider replacing limited resources by another ones.
Dominant strategy is to monitor the limits and using tradeoff analysis for deciding which of them it is convenient to reduce or remove to obtain desired results.
Define the acceptable level of (un)attraction.
Slowing actions are not usually appearing at the same time so it is important to manage them through the time.
Try to inhibit the limits before they even start to act like limits.
As limits start to have impact on various levels of results it is important to keep the right timing – intercept the moment when the limit starts playing its role but not waste the resources to avoid its impact unless it is necessary."
PS: I see this from the player's perspective: a bug is a synonym of "poor quality" regardless how difficult is to manage it.
Oltreverso guild leader
Maga Othelma - DC | Svalvolo - SW | Dente Avvelenato- GWF
"Last request - microtransactions for alllll old skins for zen/weapon appearance changes, 500 zen to make ur wep glow the color/enchant you want it... You will make more off that one item than any other zen item ever made." freshour
"beckylunatic" Gateway AH should have column headers to sort by buyout, bid, end time, quantity, etc. These disappeared iirc with the module launch. It's obnoxious.