Unless your definition of mature is old, I'm not sure what you are talking about. At the large publishers stuff like unpaid overtime is built into the budget from day 1, game developers are typically paid quite a bit less than their counterparts in the business sector, and agile development practices are rare.

They build very expensive, monolithic pieces of software. It is pretty much the exact opposite of where software development has been going for the past 10 years.

Earlier in the history of the industry games were ligher weight, more iterative and more exploratory. Over time that changed. Sure thats changing back again with indie games, but that's still a small part of the market.

I'm just wondering out loud, could your corner of the world be moving in that direction?

Most games are trainwrecks inside. They are /just good enough to ship/ and often no better. They are fragile, fickle things that for the most part have a market lifetime much shorter than the time it took to develop the title. You get your money back -- if you do -- in the first few months of sales.

Games are pragmatic and hard, cheap bastards that chew up teams and spit them out.

It's fun. :-)

I'd love to know what you base this opinion on.

Every game I've shipped has been far more stable than the majority of applications I use on a daily basis today. Most of those codebases where then used in other titles, aside from the very game-specific parts.

Sony/Nintendo etc require that your game runs for 1-3 days without a crash, on a platform without virtual memory, before they'll put it on a disc that cannot be patched (well, until this-gen of consoles. Now it's just expensive to patch).

Quite a bit different from platforms such as iOS where developers get upset that Apple take five days to approve updates for for free (fail a Sony submission and you'll be paying $$$$$)

> They are /just good enough to ship/ and often no better.

From one point of view, this is viciously optimized. I'm reminded of a quote along the lines of "the ideal racing car would cross the finish line intact and immediately disintegrate." The point being, find the minimum weight necessary to accomplish your goal, and spend as close to that minimum as possible. In games, the "weight" you're minimizing is the effort and focus spent on production quality, in order to be able to spend more on game design and performance, and ship faster.

This is what I've been suspecting after reading dozens of tutorials and examples on all manner of game-related APIs and libraries. It seems like game programmers as a whole care less about code organization, style, and all the other values that are exalted in other fields.

You're probably being unfair there. The programmers who work on games are often very smart, very capable people who genuinely want to make a good product. A lot of so-called professional programmers could learn a thing or two from games developers about everything from writing high performance code to co-ordinating large development teams via the value of developing in-house tools to make development work more efficient.

But the games programmers are screwed by the simple fact that the market will accept games that are buggy/require insane hardware/etc. and pay for them, will usually not attempt to return them if they simply don't work but will rip them apart in on-line commentary if the game sucks, and will rip them off at the first opportunity if the game is cracked.

That means the business guys who are, quite rightly, calling the shots, are interested in basically the first few days after launch and nothing else. That in turn means there is no need to bother with things like code quality and long-term maintenance. Better to spend the money on a cinematic trailer and DRM that takes one more day to crack.

This will continue as long as people continue to accept buggy games, dubious policies like shipping incomplete games and then filling in the blanks with paid-for DLC, and so on. And right now, while there are clearly plenty of people like me who would spend a lot on good games that worked properly and didn't come with pseudo-malware attached, it seems there are plenty more people who just don't care.

You want them to write games for people like me. (Thanks! :-)) Unfortunately, most of the big games shops are going to follow the money.

I'd have to content that my own games (Crash + Jak) are far far less buggy than the typical web or desktop application. We had a VERY low tolerance for bugs. I NEVER EVER shipped with a known crash bug (there were some I didn't know about of course). As entertainment we always felt that the consumer had zero tolerance for bugs. Something like MS Word is riddled with serious bugs that don't get fixed major release after major release. We had a huge staff of in house QA and even more external.

Well, FWIW, I'm glad someone is still making games with some eye on quality.

Personally I basically gave up AAA games around four years ago, after three big disappointments.

Crysis should have been great but had all kinds of problems even on high-end hardware.

Supreme Commander should have been great, except that a major selling point was its world-scale maps but if you actually played a full on game on such a map you went over 2GB RAM and crashed it on 32-bit XP.

Oblivion should have been great, with a lot of power in the game engine and some interesting ideas, but they forgot to bring the fun part.

Those were probably the three most eagerly anticipated PC titles of their generation, and while I did complete Crysis and have spent plenty of time on Forged Alliance, the enjoyment was severely damaged by the frustration with all the problems.

Since then, it seems like all I hear about is ever more intrusive DRM screwing things up and ever more profiteering via DLC and exclusive content deals. I've given up on contemporary AAA titles entirely until this sort of silliness goes away, and I content myself with things like puzzle games and titles from GoG that are actually fun to play.

The sad thing is, I'm betting the programming teams behind Crysis and SupCom could have improved the trouble spots and given everyone a much more enjoyable gaming experience with a bit more time, but I bet the suits pushed them to ship when it was "good enough". As for the DRM and DLC in more recent titles, that's just management madness through and through.

I play only a small number of games and these were very good:

Mass effect 1 & 2 on xbox360. Starcraft 2 on mac. Halo series was alright.

Try playing on a console, it'll be more stable.

I agree with most of your post, but I don't think the problem is bugginess.

The real problem is the short-term fix nature of games. As you say, they're (mostly) not designed to be one-shots, with the majority of players playing through the game for a couple of weeks each, within a period of a few months of each other. That is why bugginess is tolerated, not the other way around. It's not worth the time to fix non-critical edge-case problems in situations. By the time the bug can be fixed, and tested, it'll only be useful to, say, 10% of total players.

In multiplayer games (and other games where the player is expected to engage with the game for months at a time) then you find that there are frequent updates and bug fixes.

Such is the reason the only game I play is a Quake clone (Urban Terror). It is mostly bug free, runs on cheap hardware, and most importantly: it is very fun (due to the great gameplay.) It also has a great community (with a lot of hackers/nerd types.

I wonder if it's a different story with longer-running MMORPG's like WoW, FFXI, etc. Wouldn't the situation force the development process to be more stable and follow best practices?

I worked at Riot Games (makers of League of Legends) for a while. In some ways, it was much better: good, iterative practices, tracking technical debt, etc. In other ways, it was no different: long hours, little regard for anything but the release, etc.

Now that they've been released for a while, it would be interesting to see how things have changed.

Even following best practices, the top priority of the project should be to fulfill the players' expectations and realize the designers' vision. That's not as compatible with technical excellence at every stage of the project as you'd hope it would be.

On well-planned projects, best practices of development help achieve that priority throughout the project. However, the more problematic development becomes, the more things come into conflict with that top priority. And in practice, planning is almost never good enough to prevent that as the project wears on. Project management that can push back the day when that vicious cycle kicks in is invaluable.

Usually, in reality, the top priority is to ensure the short-term viability of the project or (worse) the studio or (much worse) the studio management. It's like Robocop's hidden directive, sadly. That diversion of focus, especially early in a project, is totally poisonous.

If anything, MMOs are more susceptible to these kinds of existential threats than most projects. They're incredibly challenging feats for even a massively skilled development team. The ability to produce an MMO is actually a fairly good way to measure how well-buffered a development environment is from this kind of insecurity.

I think what's sad when you compare the games industry to others like finance or telecommunications, (based on my experience) a typical (large) game company does way way more testing than say a big bank or telco.