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.
With games like Braid you can afford to do that because as cool as the game is, it's just a platformer.
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 think you may have taken this too far. Graphics and sound can contribute to or detract from fun, but in the end it is fun that keeps people buying a game. A game that looks great, but plays poorly will not survive, but a game that plays fantastically might be around for years later.
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.
Heck take a look at Dwarf Fortress for that matter. The latest update alone (and now the upcoming minecart and hauling patch) are adding enough content, for most sequels. Never mind the new content arising from the interactions between all the modules.
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 agree with you but I think with big studio games it isn't always the case. The graphics can carry a mediocre game very far. On the other extreme they can crush a really fun game if it doesn't look "current generation" or has other technical issues.
Planescape Torment is fantastic. I still play Fallout2 these days. I love that game :)
My experience matches the previous poster. I used to abhor video games of any kind. Then I was given an XBox for good work or something, and started checking them out.
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.
I loved Planescape! I remember how excited I was the first time I got to an absolute dead end and died. I was getting ready to restore from a save when I woke up on a table... "wait.. this is how you advance?!?!?" So cool, I've still not played an RPG that threw as many curveballs as that one.
You'd be surprised at the work that it takes to make a well-running platformer. 2D games can use tons of texture memory, and often end up with long loading times. Making a game 2D with really diverse visuals and good animated sprites without being laggy or having long loading times does require some attention to optimization and architecture.
Hm. Tell me more about Unreal script and its interpreter. Tell me more about the Source and Gold Source engine. Tell me more about Flash & Scaleform.
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. :)
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'm not sure Bethesda is exactly a counterpoint. I would take issue with the phrase "just a platformer." I think you could also say that Bethesda games are "just RPGs." The point is that in both cases the games have unique game mechanics that make them good. Games that need really high-quality code to be worthwhile are very ordinary genre titles. No one is going to care about a shooter that has mediocre graphics, there have been hundreds of them over the past couple decades.
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.
I really meant to say technically just a platformer. Braid is much more than that as a game but in terms of technical complexity it isn't all that complex. Even the creator says they had the actual gameplay/mechanics sorted out very quickly.
The thing about game programming is as best I can tell, traditionally you ship it and you are done. Enterprise software, on the other hand, has required update cycles, maintenance and support for a long time now.
This is changing, of course, with the growing presence of services like Steam and Battle.net, but it isn't the mode yet.
The life cycle is definitely much shorter compared to average enterprise software, but it's never just been "ship and you are done". Even before the internet, patches and updates were distributed on game magazine cd's and support telephone numbers were listed in the back of the game manuals. Support and maintenance for your average game is a couple of years, typically.
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.