Yes, until you actually apply the brakes, or use engine braking, at which point you're wasting the energy you accumulated as potential energy and turning it into heat. So, of course the spread will depend a lot on how steep the hills are, how many of them there are, how much energy you can recover from regenerative braking, and how the efficiencies of your gas and electric motors change under heavy load vs. light load.
I've never driven to Alaska, if the roads up and down this pass are relatively flat it may make no difference. If they're quite steep, they might not be able to recover enough energy with their regenerative braking and they might not make it to the next town anyway, even though they're doing better than the gas car. If you're going to look at the problem holistically, you have to care about road conditions and temperature, too.
I just think it's cool they're trying. Give them the benefit of the doubt.
248 miles is measured using the EPA test, which includes a lot of braking. On open highway alone, they'll do better. Besides, they might not get wonderful mileage in a pass, but with regenerative braking on the downhills, they won't be as affected by it as a gas powered car.
I just drove through the rockies in a second-gen Prius, and the regenerative braking seemed to do a pretty good job of smoothing out the consumption: I'd get worse consumption on the uphill and better on the downhill, and it seemed to average out to just the same as what I got on the flat; within 10% if you believe the meter in the car.
This is a question that can only really be answered by a lawyer familiar with your circumstances and the laws in your jurisdiction. For example, by default, in Canada, if you're hired as a contractor to produce a work, you retain the copyright on that work (or so I was taught in my 100-level Business Law class). However, I don't believe this is true in the US. It's also not true in either country if you're hired as a salaried employee.
But really, plenty of other people will be offering legal advice, and the reality is that this matter won't go to court because it's not worth the time or money for you or the university. You can get a lawyer's opinion that you're in the clear to release your work, but even that's only so helpful to you -- if you threaten or bully your employer, that may just set them against you. (On the other hand, it may be just the thing! Maybe they need to see that you won't be pushed around. Different people respond to different tactics.)
The most elegant solution to your problem is politics. Convince your boss's boss and your boss's respected colleagues that your work would be better off shared -- people's opinions are ultimately derived from the opinions of the people they respect. You've made good use of an open-source base, right? Make sure they understand that there's value in tapping into that community. Allay their fears. Show them the positive side. Get people on your side.
If you can swing this right, it won't matter what the legalities are because the one of the university's officers will sign a waiver disclaiming interest in the code and you'll be in the clear for sure -- and your boss will be pleased at having done something good.
Sure, you should have got the signature before you started working; then you wouldn't have to spend cycles on this problem. Still, it may be fixable.
And if that doesn't work, just remember: the implementation is twice as good and ten times as quick to write when you've done it once before!
This is actually still the way it works for many higher-value items. It's not always the manufacturer that offers the information, but sites like PowerBook Medic give disassembly instructions and sell part so you can do simple repairs yourself. Some laptop keyboards can be replaced with just a pen knife!
The components are still modular, it's just the idea of what makes a component that's changed. Now it's an entire mainboard assembly with a transistor count in the billions, rather than a single tube.
Also, I don't know if you've looked inside your large appliances recently, but my washing machine had a wiring diagram tucked inside when I opened it to get at a bad bearing. My motorcycle came with a simplified one in the owner's manual and a detailed schematic in the shop manual. For machines that are simple enough where a schematic is useful for troubleshooting and repair, schematics are actually still the norm.
Sure, but you don't have to sue them. You just have to ask nicely, "could you please sign a license agreement?"
Unless they were asked, and they refused, or they insisted on conditions GW couldn't abide. I mean, companies don't usually jump straight to litigation without even sending a letter or making a phone call first, but that doesn't tell us about this particular case. The claim from Curse is that that's exactly what happened.
Reading the complaint does turn up some interesting information. Among other things, it asserts that the warhammeralliance.com domain was registered in 2009 using false WHOIS information, which would make this particular iteration of the site, at least, *way* younger than 5 years. A cursory check on archive.org, though, suggests that the site's been in existence at that URL since 2006.
It's hard to call, from here. It sounds like GW's being at least a little inept, but on the other hand the site doesn't disclaim a relationship with GW anywhere obvious. I could totally have believed it was the official GW Warhammer forum site if I were a little more naive than I am; the logo's obviously a little unprofessional, but otherwise...
The gunner was mistaken about the RPG. He's referring to the camera -- when he says it's pointed around the corner, that's the camera being used to photograph a Bradley. The report makes this clear, apparently they found photos on the camera whose timestamp agrees with the object being pointed around the corner.
The infantry just also happened to find an RPG round. The gunner did correctly identify the AK-47s, though, which is better than I did on my first watch through the video.
I dispute the "clearly shown" part, but there was definitely a guy holding something about the size and shape of an AK-47. In the ~18-minute video embedded on BoingBoing, look at the guy just above the crosshair at 3:39, and the guy left of him; those are the probable AKs that I see. Comments in the video refer to these people being near US ground forces: 4:28 in the video, "he was right in front of the Brad".
Considering the released report claims the ground troops actually found these weapons at the scene, as well as the cameras which apparently contained photos of the Bradley, the narrative that the photographers were walking around with a group of people who were intending to do violence to US forces and were near US ground forces seems at least adequately supported.
If you want to know why they weren't ducking and covering, did you see the delay between the gun firing and the hits? The bullets must have been in the air a good 2 seconds. That puts the person shooting like a kilometer away! The guys on the ground probably had no idea where the shots came from. They were too busy looking at the Bradley right next to them, and thought they were perfectly shielded.
The audio track is certainly pretty ugly, and what happened to the kids in the van is tragic -- but in context it all seems pretty understandable. Once it was decided that this war would be fought, there were bound to be tragic incidents like this.
I am, at the moment, willing to believe the government line that this was a small number of civilian casualties in the heat of battle, and I'm a lot unhappier about Abu Ghraib and Guantanamo Bay. If this is what it takes to get people talking about the real issues again, fine, but I don't see that this is one of those issues. This is the cost of war. Apparently there was probably an ROE violation when they shot the van -- which is sad, and the attitude of the soldiers is ugly, but this is no My Lai massacre.
Why do you think a rotating light won't put 10W/square meter on the wall? Those lights focus their light into a very narrow beam, I wouldn't be at all surprised if the spot they projected was in the neighbourhood of 10W/square meter. Say a 1/2 square meter patch from a 50W light at 10% efficiency?
... instead of focusing all your energies on creating fancy graphics for your latest title, why don't you try something different like making the game actually compelling and fun to play?
I guess you haven't noticed, but that's actually what's happening to the PC. That's what the article is complaining about, basically: nobody's really investing in graphics that work exclusively on the PC high end.
PC games are still a very risky market. If you're going to make a PC game (rather than a cross-platform game that also runs on the PC), you're probably not investing very much money in an expensive graphics engine or tons of art -- you're going to make a Flash game, or a tiny MMO or free-to-play game that starts small and adds content incrementally. In that arena it's far better to aim low to reduce the production costs, and to make sure everyone can actually run your game; boil the game down to its core gameplay.
The games that get big graphics budgets and engine development are cross-platform console games that sell a lot more reliably, but they're tied to yesterday's hardware.
Oh, and it doesn't help that MS ties the latest versions of DirectX to the latest version of Windows. It's super annoying to make a DX10 or DX11 game that can also run on XP, which is DX9 only. You have to make two completely independent rendering pipelines.
Are you kidding indeed. Did you mean a monitor arm?
What's more baffling is that the monitor stand sales rep didn't point out that they already exist. But then, maybe he didn't want you buying anything from another company.
Unfortunately the "always have something deliverable" part is actually one of the least useful parts of Scrum for game development, in my experience.
The concept is too vague. Any larger game has a quality bar for shipping -- there's no point if it's not at least so good. So saying "deliverable" actually ends up confusing the team; "not completely broken" is what you want to communicate, but the programmers should already be keeping the game runnable. If they weren't doing that, the designers and artists would be screaming that they can't get any work done!
I have yet to work on a game project where it wasn't implicitly understood by the programmers that unblocking the content team was top priority.
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
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.
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.
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.
Slashdot Mirror
Yes, until you actually apply the brakes, or use engine braking, at which point you're wasting the energy you accumulated as potential energy and turning it into heat. So, of course the spread will depend a lot on how steep the hills are, how many of them there are, how much energy you can recover from regenerative braking, and how the efficiencies of your gas and electric motors change under heavy load vs. light load.
I've never driven to Alaska, if the roads up and down this pass are relatively flat it may make no difference. If they're quite steep, they might not be able to recover enough energy with their regenerative braking and they might not make it to the next town anyway, even though they're doing better than the gas car. If you're going to look at the problem holistically, you have to care about road conditions and temperature, too.
I just think it's cool they're trying. Give them the benefit of the doubt.
248 miles is measured using the EPA test, which includes a lot of braking. On open highway alone, they'll do better. Besides, they might not get wonderful mileage in a pass, but with regenerative braking on the downhills, they won't be as affected by it as a gas powered car.
I just drove through the rockies in a second-gen Prius, and the regenerative braking seemed to do a pretty good job of smoothing out the consumption: I'd get worse consumption on the uphill and better on the downhill, and it seemed to average out to just the same as what I got on the flat; within 10% if you believe the meter in the car.
This is a question that can only really be answered by a lawyer familiar with your circumstances and the laws in your jurisdiction. For example, by default, in Canada, if you're hired as a contractor to produce a work, you retain the copyright on that work (or so I was taught in my 100-level Business Law class). However, I don't believe this is true in the US. It's also not true in either country if you're hired as a salaried employee.
But really, plenty of other people will be offering legal advice, and the reality is that this matter won't go to court because it's not worth the time or money for you or the university. You can get a lawyer's opinion that you're in the clear to release your work, but even that's only so helpful to you -- if you threaten or bully your employer, that may just set them against you. (On the other hand, it may be just the thing! Maybe they need to see that you won't be pushed around. Different people respond to different tactics.)
The most elegant solution to your problem is politics. Convince your boss's boss and your boss's respected colleagues that your work would be better off shared -- people's opinions are ultimately derived from the opinions of the people they respect. You've made good use of an open-source base, right? Make sure they understand that there's value in tapping into that community. Allay their fears. Show them the positive side. Get people on your side.
If you can swing this right, it won't matter what the legalities are because the one of the university's officers will sign a waiver disclaiming interest in the code and you'll be in the clear for sure -- and your boss will be pleased at having done something good.
Sure, you should have got the signature before you started working; then you wouldn't have to spend cycles on this problem. Still, it may be fixable.
And if that doesn't work, just remember: the implementation is twice as good and ten times as quick to write when you've done it once before!
This is actually still the way it works for many higher-value items. It's not always the manufacturer that offers the information, but sites like PowerBook Medic give disassembly instructions and sell part so you can do simple repairs yourself. Some laptop keyboards can be replaced with just a pen knife!
The components are still modular, it's just the idea of what makes a component that's changed. Now it's an entire mainboard assembly with a transistor count in the billions, rather than a single tube.
Also, I don't know if you've looked inside your large appliances recently, but my washing machine had a wiring diagram tucked inside when I opened it to get at a bad bearing. My motorcycle came with a simplified one in the owner's manual and a detailed schematic in the shop manual. For machines that are simple enough where a schematic is useful for troubleshooting and repair, schematics are actually still the norm.
Sure, but you don't have to sue them. You just have to ask nicely, "could you please sign a license agreement?"
Unless they were asked, and they refused, or they insisted on conditions GW couldn't abide. I mean, companies don't usually jump straight to litigation without even sending a letter or making a phone call first, but that doesn't tell us about this particular case. The claim from Curse is that that's exactly what happened.
Reading the complaint does turn up some interesting information. Among other things, it asserts that the warhammeralliance.com domain was registered in 2009 using false WHOIS information, which would make this particular iteration of the site, at least, *way* younger than 5 years. A cursory check on archive.org, though, suggests that the site's been in existence at that URL since 2006.
It's hard to call, from here. It sounds like GW's being at least a little inept, but on the other hand the site doesn't disclaim a relationship with GW anywhere obvious. I could totally have believed it was the official GW Warhammer forum site if I were a little more naive than I am; the logo's obviously a little unprofessional, but otherwise...
The gunner was mistaken about the RPG. He's referring to the camera -- when he says it's pointed around the corner, that's the camera being used to photograph a Bradley. The report makes this clear, apparently they found photos on the camera whose timestamp agrees with the object being pointed around the corner.
The infantry just also happened to find an RPG round. The gunner did correctly identify the AK-47s, though, which is better than I did on my first watch through the video.
I dispute the "clearly shown" part, but there was definitely a guy holding something about the size and shape of an AK-47. In the ~18-minute video embedded on BoingBoing, look at the guy just above the crosshair at 3:39, and the guy left of him; those are the probable AKs that I see. Comments in the video refer to these people being near US ground forces: 4:28 in the video, "he was right in front of the Brad".
Considering the released report claims the ground troops actually found these weapons at the scene, as well as the cameras which apparently contained photos of the Bradley, the narrative that the photographers were walking around with a group of people who were intending to do violence to US forces and were near US ground forces seems at least adequately supported.
If you want to know why they weren't ducking and covering, did you see the delay between the gun firing and the hits? The bullets must have been in the air a good 2 seconds. That puts the person shooting like a kilometer away! The guys on the ground probably had no idea where the shots came from. They were too busy looking at the Bradley right next to them, and thought they were perfectly shielded.
The audio track is certainly pretty ugly, and what happened to the kids in the van is tragic -- but in context it all seems pretty understandable. Once it was decided that this war would be fought, there were bound to be tragic incidents like this.
I am, at the moment, willing to believe the government line that this was a small number of civilian casualties in the heat of battle, and I'm a lot unhappier about Abu Ghraib and Guantanamo Bay. If this is what it takes to get people talking about the real issues again, fine, but I don't see that this is one of those issues. This is the cost of war. Apparently there was probably an ROE violation when they shot the van -- which is sad, and the attitude of the soldiers is ugly, but this is no My Lai massacre.
Why do you think a rotating light won't put 10W/square meter on the wall? Those lights focus their light into a very narrow beam, I wouldn't be at all surprised if the spot they projected was in the neighbourhood of 10W/square meter. Say a 1/2 square meter patch from a 50W light at 10% efficiency?
I guess you haven't noticed, but that's actually what's happening to the PC. That's what the article is complaining about, basically: nobody's really investing in graphics that work exclusively on the PC high end.
PC games are still a very risky market. If you're going to make a PC game (rather than a cross-platform game that also runs on the PC), you're probably not investing very much money in an expensive graphics engine or tons of art -- you're going to make a Flash game, or a tiny MMO or free-to-play game that starts small and adds content incrementally. In that arena it's far better to aim low to reduce the production costs, and to make sure everyone can actually run your game; boil the game down to its core gameplay.
The games that get big graphics budgets and engine development are cross-platform console games that sell a lot more reliably, but they're tied to yesterday's hardware.
Oh, and it doesn't help that MS ties the latest versions of DirectX to the latest version of Windows. It's super annoying to make a DX10 or DX11 game that can also run on XP, which is DX9 only. You have to make two completely independent rendering pipelines.
Are you kidding indeed. Did you mean a monitor arm?
What's more baffling is that the monitor stand sales rep didn't point out that they already exist. But then, maybe he didn't want you buying anything from another company.
Unfortunately the "always have something deliverable" part is actually one of the least useful parts of Scrum for game development, in my experience.
The concept is too vague. Any larger game has a quality bar for shipping -- there's no point if it's not at least so good. So saying "deliverable" actually ends up confusing the team; "not completely broken" is what you want to communicate, but the programmers should already be keeping the game runnable. If they weren't doing that, the designers and artists would be screaming that they can't get any work done!
I have yet to work on a game project where it wasn't implicitly understood by the programmers that unblocking the content team was top priority.
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.
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!)
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.
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...
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.
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.