So how does the OS know the application is an "installer"?
Suppose I wanted my installer to offer an option to convert my existing document files to a new format? Could I do that? Would the OS let me? How would I ask the user permission? Wouldn't the average user just say 'yes' if they were asked?
Even supposing the installer is prevented from doing anything bad, how do you prevent the application once installed from doing bad things? If it has permission to read and write.doc files, say, then there are still plenty of malicious things it can do (like nuking all my documents when it's run).
Fundamentally, my point still stands. In order to be useful, applications need sufficient permissions to do bad things, because it's not really possible to technologically tell the difference between good and bad in every case. A word processer has to be able to edit documents, so something posing as a word processor will have permissions to trash documents, and so forth.
Again, the root cause is that the system and the user have no way of knowing that an application is trustworthy. This is a distinct problem from that of fine grained permissions.
This thing was posing as an installer. That's the kind of program which has a perfectly legitimate right to be updating files, perhaps deleting a few, and generally touching a fair amount of stuff on your system. How would your utopian OS have sandboxed things?
Unless you expect the OS to securely prompt you for every single file-system interaction an application makes (which is obviously unusable), then you have to give certain categories of permissions to combinations of users and applications. In this case, the user genuinely believed that the application was an installer for a legitimate piece of software, and so would likely have granted permission for it to mess with his file-system anyway.
The real problem is that the user was tricked into granting permissions that he shouldn't have. A more granular permissions regime would not have helped with this problem.
Your suggestion that you should be able to run hostile code, see what it does, and rollback is an interesting one, but it does assume a rollback scheme capable of restoring your entire file-system on-demand after any operation. Which seems to me to be slightly impractical to implement for every single file-system transaction. Also, you're again assuming that the user knew the application might be hostile - but the problem is that he assumed that it was trustworthy.
You say that OSes should be able to run hostile code in complete safety, but how do you know what is hostile? Do you treat all code as hostile until told otherwise? Do you treat any code as non-hostile? How would it work if all code were considered hostile? Again, remember that in this case the user would have happily told the system that the code was not hostile.
Surely the main motivation is to help keep their legitimate customers safe. Unpatched systems which act as vectors for worms and viruses hurt everyone, so allowing pirate copies to be patched improves things for their legitimate customers.
What you say makes no sense. Why would a publisher want a title to fail? The publisher has invested money in development. If they can't recoup that investment, they've lost money, so it's in their interest to make the developer succeed.
I know that we work pretty hard to try to make a developer successful once we've signed them. Sometimes titles get cancelled because they're running off the rails. Sometimes they fail after release for all the various reasons that can happen. Sometimes the causes of those things are the developers' fault, sometimes the publisher's fault. But I've never, ever, encountered a situation where we deliberately set up a developer to fail. In fact, I get dinged pretty heavily if projects I'm working on fail.
Bonuses and royalties are never unconditional promises. They're based on performance of the title in the marketplace, which is a metric the publisher is interested in optimizing for just as much as the developer is.
When you sign a developer with "an idea" you are funding the development of that idea. Sometimes that development just doesn't work out and the title is cancelled. But the publisher is taking all the risk in that situation - in most deals the developer only pays back the advances if the title is placed with another publisher.
I am not a physicist, but I was a mathematician a while ago, and while relativity wasn't my specialty I did learn enough about it to be pretty sure that mathematically speaking, travelling faster than light is equivalent to being able to travel back in time.
That applies to a wormhole or any other mechanism of executing a spacelike rather than a timelike path. It has nothing to do with the physical mechanism of how you arranged the travel, just the fact that you did.
If you draw a spacetime diagram with an appropriate choice of inertial frame, in which faster than light travel is allowed, then it's possible to draw a path where you end up back at the same point in space but at an earlier time. Which would open up all the usual cans of worms that entails.
Basically, if the observer sees you arrive before you left, then that's enough to set up a paradox. In particular, he could observe you arrive, and then prevent you from leaving in the first place - now what happens?
Well, according to relativity, travelling faster than light is equivalent to travelling backwards in time. Since travelling backwards in time gives rise to all sorts of paradoxical situations, it's often ruled out as a physical possibility.
If travelling backward in time were possible, one would have to invent some interesting physical mechanisms to explain the paradoxes that could arise. The 'many-worlds' quantum formulation can sidestep these issues to some degree, but in general I think most physicists consider backwards time travel, and hence equivalently faster-than-light travel, to be impossible.
If you're referring specifically to a cola drink, as opposed to soda/pop generally, then it's pretty common to say 'coke' more or less everywhere (everywhere English-speaking, anyway), regardless of whether you were actually drinking Coke, Pepsi, or SomeOtherBrandOfCola.
According to relativity, how long it would take depends on who is doing the measuring.
For someone travelling close to light speed, the subjective time from their point of view to cross the galaxy could be very small (and approaches zero as their speed approaches light speed).
From the point of view of an observer stationary relative to the galaxy, the fast moving traveller would take thousands of years to cross the galaxy, even at the speed of light.
Of course, differences in perceived time intervals, and hence radically different aging of characters when accelerated to large relative velocities, tends to screw up (soft) sci-fi plots, and so it just gets ignored for the sake of a comprehensible plotline. (Although there are some good 'hard' sci-fi novels in which this is a key plot device.)
As for what the perception of time would be like for something travelling at 1.5 times the speed of light, my relativity is a little rusty, but IIRC time would appear to run backwards for such a traveller, and someone observing such a traveller would observe them arrive at their destination before they left their point of origin. There are obviously big problems for causality in such a scenario, which is why relativity is usually interpreted as prohibiting things travelling faster than light.
I've worked on both sides of the house - as a developer as a publisher. Currently, I'm working for a publisher, doing technical management for third party developers. The bottom line is that it's all about balancing risks versus rewards. So, yes, it's not just about making a great game, you have to convince your publisher that you're not going to introduce so much risk that the business case doesn't make sense any more.
Now, that doesn't mean you can't do innovative and interesting projects. Those are marketing risks, to be sure, but the potential upside is huge (and senior management loves big potential upside). What gets developers killed far more often is not market risk, but production risk. In other words, the risk that they have a great idea but they're going to fuck up the execution in some way. And there are plenty of ways developers, especially inexperienced ones, can do that:
Technical: They have crappy processes and unproven technology which will lead them to slip dates and run over-budget. They might have difficulty shipping on the target platform (on a console this is completely fatal, and on a PC you lose big chunks of your target market if you have to make the minimum acceptable spec too high).
Design: They have a great 'big idea', but can't quite execute on the thousand little decisions along the way that make things work.
Management: They fail to schedule properly for key areas. It's amazing how many schedules I've seen from developers that just completely omit whole features that are in the design doc, oops. They have poor communication, both internally and externally.
Proving to the publisher that you don't represent too large of a risk in all of those areas is vital, no matter how good your game idea. Above all, be as transparent as possible with your publisher, especially if you're a relatively new developer, because if you won't let me see your processes, source-code or design docs, and won't let me talk to your people, then I'm just going make the default assumption that those things are fucked up. (You'd be amazed how many developers don't fully grok this point.)
1. The low-entropy start for the Universe is certainly something that concerns physicists, but it's something that theories are being developed to explain. For example, some formulations of the inflationary model offer some explanation. Might I suggest a quick read of 'The Fabric of the Cosmos' (recently reviewed on Slashdot, I'm too lazy to include a link) which covers this stuff very well?
2. What do you mean by 'reliable physics'? Do you perhaps mean 'deterministic physics'? Those would be called classical physical theories (such as those of Newton, Maxwell and Einstein). Today, we also have quantum theory, which has been experimentally verified to a high degree of accuracy, and which is distinctly non-deterministic. Quantum theory tells us that probability is inherently woven into nature.
In any event, it's clear that the ultimate question of origin will always be unanswered. Even if a mechanism for the big-bang were identified, there would always be the question of 'why that mechanism'. Ultimately, why is there anything in existance at all? If you like to tag the (in principle unknowable) answer to that question 'God', then go right ahead. But it's not a very useful answer, in fact it's entirely information free. And it certainly in no way implies the usual religious meaning attached to the word.
Re:Windows?
on
Gimp Hits 2.0
·
· Score: 1, Insightful
And this sort of knee-jerk flame points up exactly why the OSS crowd continues to fail to 'get it' when it comes to certain classes of professional tool. (Hint: nobody in the real world gives a flying fuck what a programmer or sysadmin thinks is or isn't important in an image manipulation app.)
Speaking as someone who has written quite a few custom tools for artists, I can tell you that when your customer is an artist, quite often it absolutely is more important how something looks than what it does.
Now, you can either complain about how that makes no logical sense and refuse to take it on board, or you can make software that your target users will like and use. The bottom line is that if customers want something that you don't think they should want, no matter how illogical it appears to you as a programmer, then by definition they are right and you are wrong.
Yes, I know. But my point is that what once was luxury, is now being crushed by better value competition. Happened to Cadillac, could, and perhaps is, happening to Apple.
No. In fact, the idea that black holes can store information tends to correlate with the evaporation theory. If black holes couldn't store information, then they couldn't have entropy. On the other hand, if they have entropy, they must have a temperature, and if they have a tempertature they must radiate. Luckily, Hawking radiation supplies a mechanism for a black hole to radiate, and so a black hole has a temperature, and hence it's possible for it to have entropy.
I think Hawking made the bet as a hedge. He wanted to lose the bet, because that would mean he was right and that black holes contained information. If they didn't, then that could cause problems for his radiation theory, but at least he'd get some encyclopedias out of the deal.
I think you have your video game history backwards.
The first video games didn't have much story to speak of. And some of them are still considered classics today. Think of Defender, Pac-Man or Robotron. Looking further back in history, think of games in general, like Chess or Backgammon. No story there either.
Games are games. They don't need story. Adding story can make a different kind of experience, and sometimes a compelling one, but let's not pretend that it's in any way required for a good game.
And I don't think there's anything sad about that at all. What's sad is people trying to impose conventions from other media (like the need for story) onto a medium that doesn't always need it.
I think the Blizzard games are perfect examples of where the story doesn't matter much to the game itself. When I'm playing Starcraft or Warcraft III online (which I do frequently), I really could not give a flying fuck about the story (even if I could remember what the hell it is). I care about the fact that they're almost perfectly balanced strategy games, which require skill, tactics, planning and a quick hand on the mouse. They're hugely fun games, and the story doesn't matter a damn when I'm playing them.
Your example games make it even more evident how out-of-touch you are with modern gaming. Chess and Tetris? What the hell? Do you think they are the paramount of gaming? Are you 50? Why are you even reading Slashdot Games?
I assume this is a troll, but I'll bite anyway.
I'm 29
I've been making video games since 1992, and I'm still doing that today. I don't think I'm out of touch with the industry.
Chess and Tetris are perfect examples of gaming classics. Just because they're old, doesn't mean they're great. I'm told that modern dramatists still regard that Shakespeare fellow quite highly, even though he's been dead for hundreds of years, because of the timeless quality of his work. Chess and Tetris, I would argue, are the equivalent of Hamlet or Macbeth to the gaming world. Appreciating the classics does not make one 'out of touch'.
Yes, but it is implied. The complexity of the aviation industry provides plenty of depth for flight simulators, for example. I'm not sure where aviation history relates to Starcraft, say, but I'll go with you for a moment. Sure, there is a story to Starcraft, but when you're playing the game, especially online versus human opponents, is it important? Do you really care what it is? I would argue no.
Puzzle games tend to not have characters, either, That would be my point. They're often totally abstract, but they're still games. Some of them are gaming classics. They don't require story.
This seems to say that entertainment is for those people with only a brain stem and no cerebrum. No, it's to say that following through a linear narrative is only one tiny subset of the rich range of entertainment possibilities available to human beings. Games only overlap partially with that subset, and cover many other areas too.
My point is that story is only important for a relatively small subset of games. For many other games it's there in the background, but not central to the success of the title. And for yet others it's not present at all.
The balance depends on the kind of game. The engineering is getting pretty tough, because games are becoming more complicated.
Story lines, I don't think are that tricky, or important, at least for many game genres. To quote John Carmack: Story in games is like story in porn movies, you expect it to be there, but it's really not that important.
Game design is hard, because that's the thousand little decisions you have to make that separate the great from the merely average. There's just no substitute for talent here.
Content creation is hard, in the sense that you need an awful lot of it. And because there's a lot of content, then managing that content becomes a problem in itself - but that's basically an engineering problem. Artistic talent is certainly required in content creation, but ultimately this is not something that's become harder, just something that you need a lot more of.
It's also that there's a huge gulf between "having an idea for a game" and "being a game designer". Frankly, any idiot off the street can come up with a halfway decent idea for a game (it might not be terribly original, but it could probably turn into a reasonable game). The talent in game design lies in the thousand little decisions you have to make in turning the raw idea into an actual game. It's those little details that matter, and that separate a great game from an average game, and an average game from a bad game.
And I think you're missing the point of software. Software exists to make your lump of hardware useful for something other than a doorstop. In order to do that, it has to be useable by the people who want to use it. And unless you're writing a compiler, it's completely unreasonable to expect the majority, or even a significant minority, of your users to have software development skills.
When those users complain about the crappy interface to your software, they are giving you feedback about your software. That's an important part of the development process. It may not be as l33t as writing C, but it's still part of software development. These people do not have the skills to fix the problems themselves. Nor is it in any way reasonable to expect them to aquire them in order to use your software.
Furthermore, even if they do have the skills, it's still pretty unrealistic to expect them to fix the problem. Even the most prolific developer cannot possibly fix single-handed every bug or annoyance they encounter in every piece of software they ever use. The ramp up times on new codebases are just too high.
Slashdot Mirror
FYI, I suspect the chronically late Psychonauts was missing because is it also the cancelled Psychonauts.
Because DX 10 hasn't been released yet? Wouldn't it be nice to have something you can actually start using right now?
So how does the OS know the application is an "installer"?
.doc files, say, then there are still plenty of malicious things it can do (like nuking all my documents when it's run).
Suppose I wanted my installer to offer an option to convert my existing document files to a new format? Could I do that? Would the OS let me? How would I ask the user permission? Wouldn't the average user just say 'yes' if they were asked?
Even supposing the installer is prevented from doing anything bad, how do you prevent the application once installed from doing bad things? If it has permission to read and write
Fundamentally, my point still stands. In order to be useful, applications need sufficient permissions to do bad things, because it's not really possible to technologically tell the difference between good and bad in every case. A word processer has to be able to edit documents, so something posing as a word processor will have permissions to trash documents, and so forth.
Again, the root cause is that the system and the user have no way of knowing that an application is trustworthy. This is a distinct problem from that of fine grained permissions.
Oops, apologies for missing closing bold tag (next time, I'll use the preview button...).
This thing was posing as an installer. That's the kind of program which has a perfectly legitimate right to be updating files, perhaps deleting a few, and generally touching a fair amount of stuff on your system. How would your utopian OS have sandboxed things?
Unless you expect the OS to securely prompt you for every single file-system interaction an application makes (which is obviously unusable), then you have to give certain categories of permissions to combinations of users and applications. In this case, the user genuinely believed that the application was an installer for a legitimate piece of software, and so would likely have granted permission for it to mess with his file-system anyway.
The real problem is that the user was tricked into granting permissions that he shouldn't have. A more granular permissions regime would not have helped with this problem.
Your suggestion that you should be able to run hostile code, see what it does, and rollback is an interesting one, but it does assume a rollback scheme capable of restoring your entire file-system on-demand after any operation. Which seems to me to be slightly impractical to implement for every single file-system transaction. Also, you're again assuming that the user knew the application might be hostile - but the problem is that he assumed that it was trustworthy.
You say that OSes should be able to run hostile code in complete safety, but how do you know what is hostile? Do you treat all code as hostile until told otherwise? Do you treat any code as non-hostile? How would it work if all code were considered hostile? Again, remember that in this case the user would have happily told the system that the code was not hostile.
Surely the main motivation is to help keep their legitimate customers safe. Unpatched systems which act as vectors for worms and viruses hurt everyone, so allowing pirate copies to be patched improves things for their legitimate customers.
Disclaimer: I work for a publisher.
What you say makes no sense. Why would a publisher want a title to fail? The publisher has invested money in development. If they can't recoup that investment, they've lost money, so it's in their interest to make the developer succeed.
I know that we work pretty hard to try to make a developer successful once we've signed them. Sometimes titles get cancelled because they're running off the rails. Sometimes they fail after release for all the various reasons that can happen. Sometimes the causes of those things are the developers' fault, sometimes the publisher's fault. But I've never, ever, encountered a situation where we deliberately set up a developer to fail. In fact, I get dinged pretty heavily if projects I'm working on fail.
Bonuses and royalties are never unconditional promises. They're based on performance of the title in the marketplace, which is a metric the publisher is interested in optimizing for just as much as the developer is.
When you sign a developer with "an idea" you are funding the development of that idea. Sometimes that development just doesn't work out and the title is cancelled. But the publisher is taking all the risk in that situation - in most deals the developer only pays back the advances if the title is placed with another publisher.
I am not a physicist, but I was a mathematician a while ago, and while relativity wasn't my specialty I did learn enough about it to be pretty sure that mathematically speaking, travelling faster than light is equivalent to being able to travel back in time.
That applies to a wormhole or any other mechanism of executing a spacelike rather than a timelike path. It has nothing to do with the physical mechanism of how you arranged the travel, just the fact that you did.
If you draw a spacetime diagram with an appropriate choice of inertial frame, in which faster than light travel is allowed, then it's possible to draw a path where you end up back at the same point in space but at an earlier time. Which would open up all the usual cans of worms that entails.
Basically, if the observer sees you arrive before you left, then that's enough to set up a paradox. In particular, he could observe you arrive, and then prevent you from leaving in the first place - now what happens?
Well, according to relativity, travelling faster than light is equivalent to travelling backwards in time. Since travelling backwards in time gives rise to all sorts of paradoxical situations, it's often ruled out as a physical possibility.
If travelling backward in time were possible, one would have to invent some interesting physical mechanisms to explain the paradoxes that could arise. The 'many-worlds' quantum formulation can sidestep these issues to some degree, but in general I think most physicists consider backwards time travel, and hence equivalently faster-than-light travel, to be impossible.
If you're referring specifically to a cola drink, as opposed to soda/pop generally, then it's pretty common to say 'coke' more or less everywhere (everywhere English-speaking, anyway), regardless of whether you were actually drinking Coke, Pepsi, or SomeOtherBrandOfCola.
According to relativity, how long it would take depends on who is doing the measuring.
For someone travelling close to light speed, the subjective time from their point of view to cross the galaxy could be very small (and approaches zero as their speed approaches light speed).
From the point of view of an observer stationary relative to the galaxy, the fast moving traveller would take thousands of years to cross the galaxy, even at the speed of light.
Of course, differences in perceived time intervals, and hence radically different aging of characters when accelerated to large relative velocities, tends to screw up (soft) sci-fi plots, and so it just gets ignored for the sake of a comprehensible plotline. (Although there are some good 'hard' sci-fi novels in which this is a key plot device.)
As for what the perception of time would be like for something travelling at 1.5 times the speed of light, my relativity is a little rusty, but IIRC time would appear to run backwards for such a traveller, and someone observing such a traveller would observe them arrive at their destination before they left their point of origin. There are obviously big problems for causality in such a scenario, which is why relativity is usually interpreted as prohibiting things travelling faster than light.
Uh, why would Microsoft break STL programs on purpose? How would that benefit them?
I've worked on both sides of the house - as a developer as a publisher. Currently, I'm working for a publisher, doing technical management for third party developers. The bottom line is that it's all about balancing risks versus rewards. So, yes, it's not just about making a great game, you have to convince your publisher that you're not going to introduce so much risk that the business case doesn't make sense any more.
Now, that doesn't mean you can't do innovative and interesting projects. Those are marketing risks, to be sure, but the potential upside is huge (and senior management loves big potential upside). What gets developers killed far more often is not market risk, but production risk. In other words, the risk that they have a great idea but they're going to fuck up the execution in some way. And there are plenty of ways developers, especially inexperienced ones, can do that:
Technical: They have crappy processes and unproven technology which will lead them to slip dates and run over-budget. They might have difficulty shipping on the target platform (on a console this is completely fatal, and on a PC you lose big chunks of your target market if you have to make the minimum acceptable spec too high).
Design: They have a great 'big idea', but can't quite execute on the thousand little decisions along the way that make things work.
Management: They fail to schedule properly for key areas. It's amazing how many schedules I've seen from developers that just completely omit whole features that are in the design doc, oops. They have poor communication, both internally and externally.
Proving to the publisher that you don't represent too large of a risk in all of those areas is vital, no matter how good your game idea. Above all, be as transparent as possible with your publisher, especially if you're a relatively new developer, because if you won't let me see your processes, source-code or design docs, and won't let me talk to your people, then I'm just going make the default assumption that those things are fucked up. (You'd be amazed how many developers don't fully grok this point.)
1. The low-entropy start for the Universe is certainly something that concerns physicists, but it's something that theories are being developed to explain. For example, some formulations of the inflationary model offer some explanation. Might I suggest a quick read of 'The Fabric of the Cosmos' (recently reviewed on Slashdot, I'm too lazy to include a link) which covers this stuff very well?
2. What do you mean by 'reliable physics'? Do you perhaps mean 'deterministic physics'? Those would be called classical physical theories (such as those of Newton, Maxwell and Einstein). Today, we also have quantum theory, which has been experimentally verified to a high degree of accuracy, and which is distinctly non-deterministic. Quantum theory tells us that probability is inherently woven into nature.
In any event, it's clear that the ultimate question of origin will always be unanswered. Even if a mechanism for the big-bang were identified, there would always be the question of 'why that mechanism'. Ultimately, why is there anything in existance at all? If you like to tag the (in principle unknowable) answer to that question 'God', then go right ahead. But it's not a very useful answer, in fact it's entirely information free. And it certainly in no way implies the usual religious meaning attached to the word.
And this sort of knee-jerk flame points up exactly why the OSS crowd continues to fail to 'get it' when it comes to certain classes of professional tool. (Hint: nobody in the real world gives a flying fuck what a programmer or sysadmin thinks is or isn't important in an image manipulation app.)
Speaking as someone who has written quite a few custom tools for artists, I can tell you that when your customer is an artist, quite often it absolutely is more important how something looks than what it does.
Now, you can either complain about how that makes no logical sense and refuse to take it on board, or you can make software that your target users will like and use. The bottom line is that if customers want something that you don't think they should want, no matter how illogical it appears to you as a programmer, then by definition they are right and you are wrong.
Yes, I know. But my point is that what once was luxury, is now being crushed by better value competition. Happened to Cadillac, could, and perhaps is, happening to Apple.
Perhaps that's a very apt comparison. After all, Cadillac is having its lunch eaten by BMW, Mercedes and Lexus.
No. In fact, the idea that black holes can store information tends to correlate with the evaporation theory. If black holes couldn't store information, then they couldn't have entropy. On the other hand, if they have entropy, they must have a temperature, and if they have a tempertature they must radiate. Luckily, Hawking radiation supplies a mechanism for a black hole to radiate, and so a black hole has a temperature, and hence it's possible for it to have entropy.
I think Hawking made the bet as a hedge. He wanted to lose the bet, because that would mean he was right and that black holes contained information. If they didn't, then that could cause problems for his radiation theory, but at least he'd get some encyclopedias out of the deal.
I think you have your video game history backwards.
The first video games didn't have much story to speak of. And some of them are still considered classics today. Think of Defender, Pac-Man or Robotron. Looking further back in history, think of games in general, like Chess or Backgammon. No story there either.
Games are games. They don't need story. Adding story can make a different kind of experience, and sometimes a compelling one, but let's not pretend that it's in any way required for a good game.
And I don't think there's anything sad about that at all. What's sad is people trying to impose conventions from other media (like the need for story) onto a medium that doesn't always need it.
I think the Blizzard games are perfect examples of where the story doesn't matter much to the game itself. When I'm playing Starcraft or Warcraft III online (which I do frequently), I really could not give a flying fuck about the story (even if I could remember what the hell it is). I care about the fact that they're almost perfectly balanced strategy games, which require skill, tactics, planning and a quick hand on the mouse. They're hugely fun games, and the story doesn't matter a damn when I'm playing them.
Your example games make it even more evident how out-of-touch you are with modern gaming. Chess and Tetris? What the hell? Do you think they are the paramount of gaming? Are you 50? Why are you even reading Slashdot Games?
I assume this is a troll, but I'll bite anyway.
I'm 29
I've been making video games since 1992, and I'm still doing that today. I don't think I'm out of touch with the industry.
Chess and Tetris are perfect examples of gaming classics. Just because they're old, doesn't mean they're great. I'm told that modern dramatists still regard that Shakespeare fellow quite highly, even though he's been dead for hundreds of years, because of the timeless quality of his work. Chess and Tetris, I would argue, are the equivalent of Hamlet or Macbeth to the gaming world. Appreciating the classics does not make one 'out of touch'.
Yes, but it is implied. The complexity of the aviation industry provides plenty of depth for flight simulators, for example.
I'm not sure where aviation history relates to Starcraft, say, but I'll go with you for a moment. Sure, there is a story to Starcraft, but when you're playing the game, especially online versus human opponents, is it important? Do you really care what it is? I would argue no.
Puzzle games tend to not have characters, either,
That would be my point. They're often totally abstract, but they're still games. Some of them are gaming classics. They don't require story.
This seems to say that entertainment is for those people with only a brain stem and no cerebrum.
No, it's to say that following through a linear narrative is only one tiny subset of the rich range of entertainment possibilities available to human beings. Games only overlap partially with that subset, and cover many other areas too.
My point is that story is only important for a relatively small subset of games. For many other games it's there in the background, but not central to the success of the title. And for yet others it's not present at all.
Bullshit. Story is important in pretty much one genre: RPGs. For everything else, it's only sometimes required, and rarely important.
Is story important in RTS games?
Is story important in puzzle games?
When was the last time you gave a shit about story in a sports game?
Games are not typically linear pieces of narrative, i.e. stories. Games are pieces of entertainment.
Chess is the greatest turn-based strategy game ever devised. It has no story.
Tetris is the greatest puzzle game of all time. It has no story.
The balance depends on the kind of game. The engineering is getting pretty tough, because games are becoming more complicated.
Story lines, I don't think are that tricky, or important, at least for many game genres. To quote John Carmack: Story in games is like story in porn movies, you expect it to be there, but it's really not that important.
Game design is hard, because that's the thousand little decisions you have to make that separate the great from the merely average. There's just no substitute for talent here.
Content creation is hard, in the sense that you need an awful lot of it. And because there's a lot of content, then managing that content becomes a problem in itself - but that's basically an engineering problem. Artistic talent is certainly required in content creation, but ultimately this is not something that's become harder, just something that you need a lot more of.
It's also that there's a huge gulf between "having an idea for a game" and "being a game designer". Frankly, any idiot off the street can come up with a halfway decent idea for a game (it might not be terribly original, but it could probably turn into a reasonable game). The talent in game design lies in the thousand little decisions you have to make in turning the raw idea into an actual game. It's those little details that matter, and that separate a great game from an average game, and an average game from a bad game.
And I think you're missing the point of software. Software exists to make your lump of hardware useful for something other than a doorstop. In order to do that, it has to be useable by the people who want to use it. And unless you're writing a compiler, it's completely unreasonable to expect the majority, or even a significant minority, of your users to have software development skills.
When those users complain about the crappy interface to your software, they are giving you feedback about your software. That's an important part of the development process. It may not be as l33t as writing C, but it's still part of software development. These people do not have the skills to fix the problems themselves. Nor is it in any way reasonable to expect them to aquire them in order to use your software.
Furthermore, even if they do have the skills, it's still pretty unrealistic to expect them to fix the problem. Even the most prolific developer cannot possibly fix single-handed every bug or annoyance they encounter in every piece of software they ever use. The ramp up times on new codebases are just too high.