Slashdot Mirror
Are Complex Games Doomed To Have Buggy Releases?
An anonymous reader points out a recent article at Gamesradar discussing the frequency of major bugs and technical issues in freshly-released video games. While such issues are often fixed with updates, questions remain about the legality and ethics of rushing a game to launch. Quoting:
"As angry as you may be about getting a buggy title, would you want the law to get involved? Meglena Kuneva, EU Consumer Affairs Commissioner, is putting forward legislation that would legally oblige digital game distributors to give refunds for games, putting games in the same category in consumer law as household appliances. ... This call to arms has been praised by tech expert Andy Tanenbaum, author of books like Operating Systems: Design and Implementation. 'I think the idea that commercial software be judged by the same standards as other commercial products is not so crazy,' he says. 'Cars, TVs, and telephones are all expected to work, and they are full of software. Why not standalone software? I think such legislation would put software makers under pressure to first make sure their software works, then worry about more bells and whistles.'"
What exactly is the downside to forcing a company to give refunds for the broken merchandise that it sells?
"His name was James Damore."
"Cars, TVs, and telephones are all expected to work, and they are full of software. Why not standalone software?"
What's the definition of work anyways? Most products sold nowadays suck. I just got rid of a laundry machine that was 40 years old. I'll be lucky if the new one lasts 1/4th as long. I bought a LCD monitor that worked until the 1 year warranty was up. My cellphone functions, but its software is crummy and buggy. It even freezes up sometimes. (No, it isn't a smartphone.)
Software is more like writing a book. Some books are written with superior quality "code." The "computer" reads that code, and depending on how well that code was written, the "computer" can read it more quickly and determine the proper function faster. (In this case, correctly interpreting the knowledge inside the book.) Some books are total shit. For example, just about every book that's used in education. Especially ones written by professors. They don't "work."
I do have one sentiment. I absolutely think that games should be returnable. But that's from an idealistic standpoint. I fully understand many, many people are going to play the game all the way through then return it to Wally World.
AST:
'I think the idea that commercial software be judged by the same standards as other commercial products is not so crazy,' he says. 'Cars, TVs, and telephones are all expected to work, and they are full of software. Why not standalone software? I think such legislation would put software makers under pressure to first make sure their software works, then worry about more bells and whistles.'"
Next he will be claiming that it is safer to use a properly modular operating system.
http://michaelsmith.id.au
It's not just games: most consumer electronics nowadays are a mix of software and hardware and often enough it's the software part that is released unfinished (read: buggy).
Software on non-life-critical applications has been given a free ride for two long - if it's not acceptable that a DVD player refuses to start at odd moments or randomly stops working, why would the same be acceptable in a computer game (which is just another for of entertainment) or an OS?
As somebody working in IT, who has worked in the industry in both IT Services and IT Products, I've seen again and again the main behaviours that lead to buggy software releases:
a) No real software development process resulting in unpredictability with regards to the real finish date.
b) Bad requirements definitions, stuffed with incomplete, inconsistent and unclear "desires", with way too much time wasted in "would be nice" requirements leading to last minute requirements changes as people discover the missing/bad bits.
c) Little or no real testing, mostly done by amateurs (or worse, developers).
d) Hard deadlines set by sales and marketing which, coupled with the points above, results in releases of unfinished products.
The reason why this happen is very simple: companies can get away with this, so management (from top to bottom) can get away with being disorganized, unstructured, "shoot-from-the-hip" cowboy-like, non-proactive and outright incompetent.
(yes, I AM sour about this)
Funny enough, buyers of software products and services are so used to be royally done by the industry that some of the worst offenders in this space are actually the larger IT companies, not the smaller ones: in a playing field were buyers expected and valued quality in software, the higher-quality companies would outcompete and outgrow the low-quality ones, and yet what we see is the opposite.
So Andy Tanenbaum is now a mere "tech expert"? That's a big step down from "CS god."
For the uninformed, ast wrote a kinda good book on operating systems called "Operating Systems: Design and Implementation." I believe this one guy from Finland wrote an OS called Linux based on another OS called Minix discussed in that book (and even got into the flamefest of the century with the Finnish guy!). And then there's a bunch of other stuff you may or may not know about, such as the Amoeba distributed OS, a free anonymous p2p network called Turtle, and probably a few other knick-knacks along the way.
Seriously, give the Man due credit.
I bought Mass Effect only to find out that the game simply does not run. My computer is as close to flawless as it could possibly get, it's been running for years and has successfully played many games with many different engines, I have done workarounds for crashes and bugs and all sorts of things, it's a tried and true PC.
Just an anecdote from the other side of the fence, and not saying this is necessarily your case. Certainly not defending Mass Effect, I've never tried the game personally.
We've had numerous users report serious defects in our products over many years, and faced all sorts of threats and insults, only for the fault to be eventually traced to the user's "tried and tested hardware." Each program that you may use exercises different components of your PC in different ways. Sometimes subtle differences can make a massive difference in results; the difference between working fine and not even starting up. Should the developer pay because you have some mildly faulty ram?
We've also seen vastly different behavior from hardware/drivers built to the same spec but sourced from different manufacturers, or from the same manufacturer but over different periods. Sometimes these deviations are within the spec but not covered by reasonable testing; often these deviations are outside the spec completely. Should the developer pay because one or more of your components do not follow the specs, or deviate significantly from what was standard practice at the time the software was developed?
As a user, I have to agree that it sucks when products don't work as advertised. I agree that there should be a mechanism for complaint against any vendor, whether their product be physical or virtual. But I'm not sure that I agree that there should be an absolute right of refund at the user's discretion. That's just open for abuse - whether deliberate or incidental.
I'm also not particularly fond of DRM and yet that would seem to be the only way that a vendor could offer true "returns" of a software-only product.
It's probably worth noting that I'm not claiming that all bugs are the user's fault; but it's certainly not the case that all bugs are the application developer's fault, either.
The quality of the code is a function of its cost, too.
For example, the code written for NASA hardware (i.e.: space shuttles), have more documentation than the size of the hardware itself (so, we're looking at a large pile of documents next to the shuttle). It's tested for years, it only works on tested CPUs (i.e.: 20 years old proven 8086s), and the actual "waterfall" method (which is generally a disaster for any other project) is properly applied.
That total brings the cost of each source code line to average $1000. (Same for medical appliances, etc).
The cost of a commercial off the shelf software is much (much much) less than $100.
But, even under such strict control, we had to debug the Mars rovers due to unforeseen bugs during their initial flight.
Anybody here on Slashdot can do the math, and fill in the gaps to calculate the future price of games (for a reference they are $60/unit now).
They were tested and verified; thousands and thousands of other people played Mass Effect with no problem. Nobody is using you as a Beta. It is not possible to test all combinations, and moreover the fix, when you find one, will be on your end, because if it were the code everyone would be experiencing the same difficulty. The inability of even technically competent gamers to grasp this basic point is the best argument against enforced refunds in my opinion. People are able to tell when a phone doesn't work; with a game all they know is that it isn't working. You can't tell where the problem lies, so you just blame the game reflexively. Natural, but very often wrong. If the company wants to give you a refund that's fine but you'd both be better served if you weren't so adamant that the game was the problem and actually worked to find the real culprit; you might get to play a great game and the company would retain your money and your custom.
You do realize that every single game that runs fine for you is running terribly for someone else. If a bug isn't very widespread it probably isn't the game's fault. Some games really are buggy messes but Mass Effect isn't one of them.