http://the-witness.net/news/2011/06/how-to-program-independe...
In a course I took junior year of college, my project partner (now cofounder) and I worked on a zombie outbreak simulation game. Towards the height of the project, we were probably tearing up and laying down a thousand lines of code a day, keeping in touch over the phone and fixing build errors and weird behavior.
Years later, I can't look at that code without wanting to gouge out my eyes. It makes me physically sick. That said, it worked and worked well for the task at hand.
Game programming is weird like that, and Blow's talk has a section where he talks about the relative merits of dumb structures and algorithms for developers that just have to get the thing to work. It's an interesting perspective.
Big production games don't have the same luxury as most reviews will focus on graphics/sound etc. If it runs like crap and looks average no one is going to accept that no matter how much fun it is.
I played Planescape Torment many years after it was released because I kept hearing about it. Comparing it to graphics in other games that I played at the time the graphics were poor. But it had a tremendous story and was a lot of fun, so I played it through and still recommend it to others even though it is now even more dated.
Planescape Torment is fantastic. I still play Fallout2 these days. I love that game :)
Project Gotham Racing looked awesome, and played well. Same for Gears. Chromehounds looked crap, but played insanely well. I've spent more time playing Chromehounds than I have any other game, and I play CoD a lot these days.
But the game still looks like you are staring at the matrix
---------------------
The looks vs function seems to arise often as a video game related discussion. Its not though - it applies to many other systems - take the Bloomberg terminals that your average IB kiddie has to pore over.
There are so many different commands that people have to get used to - eqs, bnd, eco, nws, MA, etc. But after the learning curve, people do adapt.
In certain cases, it is possible to get away with a tough interface, which has its own internal consistencies. OF course you won't survive the mass market, but in niche markets with a user base advanced enough, you have decent amounts of wriggle room.
I cannot count how many times Fallout x has crashed or bugged out on me, but I still have poured more hours into those games than pretty much any other.
I'd say if it's really a good game, the code quality isn't that big an issue. If I'm pissed off when the game crashes, that says good things about the quality of the game. If it's just sort of addictive, I'll probably be relieved when it crashes.
The fact is, if it ships and runs reasonably well, nobody gives a damn if you are running bogosort every frame. That's the great (and terrible!) thing about game programming.
And, really, on the PC at least, the hardware is so stupidly overpowered for most things that you can get away with heinous algorithms and overengineered/underspecced systems.
I know this, because web developers do it every day. :)
This is changing, of course, with the growing presence of services like Steam and Battle.net, but it isn't the mode yet.
In any case, Braid was just okay. The level where the flow of time depended on the direction that your character was traveling was great, but the rest of the game was forgettable. There was about as much gameplay/story integration as a Final Fantasy game, and the story itself was mostly overwrought. But considering that the game cost me one dollar to purchase, I'd say it was worth it. :)
Fred Brooks cited 10-12 lines of code per day, constant across languages and projects he surveyed. As far as I know, it's not been shown to have changed since then.