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.

Speaking as someone in the industry...

Nobody but the cheapest developers recycle assets. Slight differences in pipeline, technology, art direction, etc. conspire to make it not happen even if you're trying to share assets between projects.

Also, decent writers will work for peanuts. One or two narrative designers who are being paid as much as a mid-level designer make little difference to the bottom line on a team of 50-200 developers. Getting everyone to agree on who the good writer is, well, that's harder... getting a substantial team of designers who all have different senses of humour to form some kind of consensus and maintain a shared, consistent vision with the writer, that's nigh impossible.

no ISO body has deprecated functions like close(2), open(2), read(2), and write(2)

That's correct, because ISO C++ never included those functions in the first place. POSIX != ISO C. (Not that MSVC is on any kind of reasonable schedule for keeping up with ISO standards, but that's a whole different issue...)

Basically MS is deprecating their own terrible implementation of some POSIX compatibility. This is actually required for ISO C compliance: the compiler is not supposed to define a bunch of extraneous functions in the global namespace, because they might conflict with your names. Once those functions are removed entirely (and I believe you can #define them away right now) you can implement your own compatibility functions for software you're porting to Windows.

Now, this is all entirely separate from the SDL warnings GP is complaining about, which show up when you use standard ISO C functions like strcpy, sprintf, and apparently now memcpy. Which, honestly, I wish weren't quite so irritatingly implemented, although I'm torn because using those functions really is terrible.

It's not really that worth getting up in arms about, though, because JESUS CHRIST there's a compiler flag to disable the warnings, just put it in your makefile and quit bitching already!

You don't. An adder is a peice of hardware.

Since we're being smartasses, actually you do, because the 6502 only has an 8-bit adder implemented in hardware. If you want to add 32-bit numbers you need to write a sequence of add-with-carry instructions.

Also I don't know why you'd want to use a broom at all to clean up damp pet food, I always use paper towels. Icky.