New technology requires rapid iteration from a lot of stakeholders, in a search to find something that is workable, balanced, fun, expandable, etc., which sounds "agile" to me. Established technology seems more like something you can give marching orders to the art department and have a fixed production schedule.

This agrees with my (more recent) experience, but the fact is unless you have your own supply of cash to burn, your money source is going to want milestone deliveries, and probably will not tolerate much deviation from a fixed schedule. That means that no matter how bullshit it is when you first draft it, your development is going to be driven by the overall waterfall development arc your milestone commitments lock you to...

Not that it's a bad development model, in fact I think it's what most developers use in practice because it works: make an overall plan that says when you'll deliver, but figure out the details of what you're delivering through agile iteration.

It's easy to lose track of the fact that good software is written by good teams.

I've worked on a couple of game teams that used scrum, and I'm kind of with you in that I don't think it made a whole lot of sense. However, nobody on our teams believed scrum precluded longer-term waterfall-style planning -- so we did that too, we just used scrum for the week-to-week divvying up the work. My impression is that a functional, experienced team can make something workable out of pretty much any process, we certainly did.

Those were traditional fire-and-forget commercial titles, though. Scrum makes a lot more sense for a long-life-cycle online game where you're adding features on a regular basis for 5 years post-launch. This is actually very similar to the context where (I understand) scrum is usually employed: internal information systems that see regular revisions for years after they're put in service.

But selective breeding is an entirely different beast than the GMO process. Selective breeding allows corn to vary according to the "natural" laws of the corn itself.

The other responses are also correct, but I really wonder why you think that this is meaningful, even if it were true. Lots of completely "natural" things are incredibly toxic and dangerous to us, either by coincidence or so we wouldn't eat them. Just because something is natural doesn't mean you can assume it's safe.

What, did you actually take George Carlin seriously?

The reason you're supposed to wash your hands after going to the bathroom has nothing to do with getting sick yourself. We teach kids that their own shit is dirty because it's the easiest way to get them to stop playing with it, but the truth is everything in it is already inside you anyway. It's not particularly dangerous to you.

The reason you wash your hands after wiping your ass is to keep you from giving your asymptomatic cholera (or hepatitis, or etc.) to OTHER people.

Please wash your hands with plain soap and water for 30 seconds after using the toilet, whether you're preparing food or just touching everything in your damn house before I come over.

You do realize that's just a bunch of handmade animations someone put together? That's the kind of stuff you put together to make a pitch, not a playable game. It's not a bad pitch, but that's the kind of work one talented artist (and maybe a programmer to help get it going in-game) could do in a month or two.

There are worlds of difference between that and a full, playable game.

Man, realize what you're asking. You're asking *anyone* who just wants to get together with some folks and hack out code in their spare time to basically form a business partnership with all their contributors. Then, they won't be able to take patches from random contributors (because they'd have to get a dual-licensed patch and form a financial relationship with the contributor), or link to any other GPL software (because of same)... at that point they might as well forget the GPL entirely.

Or maybe you think the licensor should do the legwork -- you'd rather try to track down the >1000 contributors to the Linux kernel and cut each one of them a cheque yourself next time you want a closed-source Linux license? Good luck!

Plus, you must be pretty naive to think that money won't ruin relationships between developers. How many partnerships have you been in? People really are assholes. Why poison something fun you do in your spare time with the stress of having to disburse licensing fees, including tax paperwork and documentation to convince your co-contributors that you're not shafting them?

Still, if we as a society decide we want to have compulsory software licenses, I'm sure there's a way we can make it work. We could form an administrative body to handle fees, and make it an offense to distribute binaries without registering the source -- and make it go both ways, make commercial developers offer source licenses to anything they distribute, too. There'd have to be a stock, say, per-non-comment-line rate... of course, I'm in Canada and you're probably not, so there'd have to be an international treaty... ...hopefully you're getting the point by now. You're not actually asking for a simple thing, at all. Calling people assholes for not going out of their way to give you what you want kind of makes you an asshole.

(Incidentally, Stallman would love the idea of compulsory source licensing. That's EXACTLY why he created the GPL -- if we had compulsory source licensing for commercial software, it would be entirely obsolete.)

What you may not appreciate, as an engineering graduate, is that a computer science degree is a science degree, not an engineering degree. 2-year technical diploma programs are sometimes closer to engineering degrees than computer science generally is.

The (admittedly anecdotal) evidence I've seen is that at least at institutions local to me, engineering programs include training like project planning and estimation, teaching you to keep a log while you're investigating so you can double-check you covered all possibilities, as well as including several practical project courses. Computer science, on the other hand, while it does focus on math and the math behind logic, doesn't include all this practical training that's essential to your actual job as a programmer.

I have contemporaries who tell me that beyond C++ 101 you can get through a CS degree without writing any code -- which is perhaps appropriate for an academic who's interested in group theory, but not for someone I'm going to hire.

So while I'd rather work with someone who's had that rigor and practical knowledge drilled into them, there's no guarantee that's what you're getting when you hire a computer science bachelor's graduate. Which is why I think we need 4-year software engineering professional degrees, but then while we're at it maybe I could get a pony too..

Your physics makes no sense. Why is this modded informative? The ground is not a magical reference point!

If two cars travelling in opposite directions at 40 MPH slam into each other, that's exactly equivalent, in terms of energy dissipation and momentum transfer, to one car travelling at 80MPH slamming into a stationary vehicle. Each vehicle, in its own reference frame, sees another vehicle travelling at 80MPH.

Think about it: if two identical cars crash, and one is stationary, then for a moment (before they come to a stop due to friction against the pavement) they'll be moving together at half the speed of the moving car before the crash. One car goes from 80MPH to 40MPH (40MPH difference); the other goes from 0MPH to 40MPH (40MPH difference).

This is exactly equivalent to going from 40MPH to 0MPH (40MPH difference).

When you're working out simple kinematics like this you should be starting with momentum, which is linear with velocity. You can work out how much energy is released afterwards; you'll see that it works out:

(1/2) * (1500kg) * (36m/s) ^ 2 = 972 kJ - Amount of kinetic energy in the moving car at 80MPH
(1/2) * (1500kg) * (18m/s) ^ 2 * 2 = 486 kJ - Amount of kinetic energy left after the crash: 2 cars at 40MPH
972 kJ - 486 kJ = 486 kJ - Amount of kinetic energy dissipated in the crash

(1/2) * (1500kg) * (18m/s) ^ 2 * 2 = 486 kJ - Amount of kinetic energy in 2 cars at 40MPH
(1/2) * (1500kg) * (0m/s) ^ 2 * 2 = 0 kJ - Amount of kinetic energy left after the crash: in 2 cars at 0MPH
486 kJ - 0 kJ = 486 kJ - Amount of kinetic energy dissipated in the crash

(Yes, kinetic energy is 1/2 mv^2, not mv^2!)

If the ARM had equal processing power, but five times the battery life, they'd have a compelling product.

Well, it sort of does. Battery life and CPU power are actually somewhat convertible.

When the CPU isn't doing work, its power consumption drops considerably -- if you have two CPUs with the same designed maximum consumption, but one has twice the computing power available, then for the same workload that processor will use (a little bit more than) half the energy.

Of course the real picture is not so rosy, because a CPU that uses that little power to start with is probably accounting for less than half of the total power consumption of the system, and of course the workload is likely to increase if you have more CPU available (people watch video fullscreen instead of windowed, games will generally render as fast as they can and use all available CPU, etc.).

Actually, car trips should show a similar curve, since city driving has the highest risk of accidents. Once you get on the highway your accident risk goes down considerably. Of course, if you do get in an accident, the chance it'll be fatal for you goes up if it's on the highway -- the fact that car accidents are not usually fatal is an extra wrinkle in the whole thing...

It would be interesting to actually run the numbers.

Obviously much of game design is not really "science", but other design fields still do carefully analyze existing works, try to identify which elements specifically mattered, etc.;

Not to detract from your main point, but give them some credit, game designers totally do this. The field is still relatively young, and you're right that there's not the same body of literature yet as there is for, say, graphic design, but that's got more to do with the fact that you can't get tenure at a major university teaching game design yet than anything.

The game designers I work with can certainly break down what makes a game addictive and fun. Give them a chance and they'll talk your ear off about compulsion loops and memorable moments...

They're already at the mercy of the holder of the key for signing games. Unless they want their release restricted to homebrew / modchipped consoles, there would be no difference.

Indeed. Retailers and publishers have a bit of flexibility on pricing now, but in practice the console makers have a pretty big influence on how much games end up costing. Old games don't get cheaper because of some competitive thing between game retailers, it's a market segmentation strategy, and it makes just as much sense in future electronic retailing monopolies as it does to the current system.

Once you sort out the chaff, the article reduces to the last couple of paragraphs where the author complains that he won't be able to trade used games in anymore. The archivist in me does despair a little about this, the increasing effectiveness of DRM in games, and the fact that of the games without serious DRM, more and more are online and require a working server -- in 100 years will anyone be able to play WoW? WoW maybe, but any of the less popular MMOs, probably not.

That said I think the author's mostly complaining because he's cheap. You got a game for 74 cents? Great! Go you. The developers that went on to not sell more copies of those three games you traded in probably love you.

Why is Hollywood so much better at it?

If I had to guess, I'd say probably fewer people in the critical path -- a couple actors, a writer, and a director, rather than a producer and team of 5-20 designers (including lead and narrative) -- and the fact that you're generally producing less hours of content with a film, so each hour can be more polished, and that you live and die on story and humour, rather than gameplay.

But I'm not in film, and although I've been in games for a while and know a bit about how things are generally done, I've only seen my slice of the industry in depth.