If that's a major chore for you, may I suggest investing in a test suite, so that you don't have to go through manually and test all your patches?
Yes, that would help with testing, but also multiplies the work: now you have patches and the new test suite to maintain and shepherd through upgrades.:)
Testing patches actually wasn't the main obstacle. The far bigger time sink was when some patched piece of functionality moved over to a different location in the codebase. Then the engineer had to go and become familiar with their changes, find how things got rearranged, and adopt the patch to the new code. That's a lot of unnecessary work just to maintain the status quo.
As for whether we needed to upgrade so frequently - yeah, we actually did. Hopefully the OP doesn't, though.:)
Maintaining custom patches for a foreign codebase is going to be painful, proportionally to the number of patches, and how badly spread out they are through the codebase.
Consider this: every time the Rails team changes things, you'll have to go through your patches and make sure they still apply correctly. And if, heavens forbid, they do some major refactoring, you'll have to spend the time figuring out what functionality got moved where, and re-apply the patches as necessary.
My project was maintaining a custom set of patches for a major open source library for a while, and it was fairly labor-intensive: every time the library provider released a new version, a senior engineer spent a good part of a day going through the codebase and repatching it, testing the new version, etc. The problem was, however, that they released new versions frequently, and we needed them as soon as they were released.
If your patches aren't going to migrate upstream, I'd be very wary of spending a lot of time maintaining them as the core library keeps evolving. Try to measure how much time it would take to update your local patched Rails when they release a new version (especially a major one, if you can), and project future work estimates from that.
For us, we ended up sacrificing functionality for development speed, and we switched to a less capable library that worked right out of the box without endless patching.
Lots of people get confused about the various caveats in how 32-bit machines handle more than 32-bits worth of physical address space:
x86 processors have been able to access 36-bit physical address space for a long time now (since the Pentium Pro?), but many motherboards flat out don't support it
Even when they do, the OS needs to turn it on explicitly. Windows needs to be started with the/PAE switch to extends its physical address space
Even with PAE in place, the virtual space is still 4GB per process.
And out of the box, Windows limits user virtual address space to 2GB; getting more requires the infamous/3GB switch
So yes, there's a lots of parts that people don't necessarily understand. Besides, facts would get in the way of a good flame fest.:)
Easier still: write up your findings, and send them to the copyright office to get them registered, which is really cheap. Then license your copyright to anyone who wants it. Voila!:)
Worse yet, it's a repository that anyone can change at any time.
When I review conference papers, I regard any references to Wikipedia articles as red flags, and request that they be fixed. The problems are two-fold.
One, anyone can write anything in them, which makes them worthless as authoritative sources - it's like citing newspaper articles, great for bits of cultural background knowledge, but I can't expect much accuracy, since I can't tell if the author knows anything about what they describe. Better sources have authors whose careers and reputations will be damaged if they don't research their articles correctly, and editors who go through those articles with a fine-tooth comb looking for any mistakes. But Wikipedia makes itself deliberately anti-authoritative, by allowing any information to be published, and eschewing the editorial process altogether.
Two, anyone can change them at any time, which makes them worthless as sources for future scholarship - by the time the future reader looks up the citation in the Wikipedia, chances are the article will have changed. (And yes, adding version numbers to references can fix that, but authors never choose to do that.)
A 50MB distro is called "damn small"? Damn. I remember when Slackware 1.x core came on a couple of floppy disks. And if you wanted a good text editor, you had to find one on Archie and get it yourself. But we were happy in those days.:)
From the article: "In short, "open sourcing" projects like Half-Life 2 would likely lead to much better games, which would result in much better sales and happier end-users."
This is like saying GM should open-source the blueprints for all their car engines. It's ridiculous. Valve put untold millions into HL2 development, and there's absolutely no incentive for them to just open the source, and there's a strong disincentive: if they were to open it, everyone could just build a highly competitive game on top of it without paying a cent. And what's gonna pay for the programmers? The original game's sales? Will they be high enough given the man-hours that went into the engine, especially since the new competing games would likely cannibalize the sales of the original game?
The HL SDK already opens up most of the engine (sans some of the graphics and networking, I believe), and budding game programmers can cut their teeth on that (that's how Counter-Strike came about). But since it's still copyrighted, and the new game requires licensing with Valve, which helps them recoup the costs of developing it in the first place, and fund the development of the new engine.
To ignore the economic constraints of development is breathtakingly naive.
I've been lurking here a long time, and still wonder when exactly this fundamentalist turn happened.
About 1997, no?:) Slashdot has always been a flippant, slightly myopic Linux-geek site, full of l337 undergrads and opinionated sysadmins. Like a meeting of some gigantic Linux User's Group, it's both exciting and stupefying.:)
Amen to that!:) When do these people find the time to do this thrifting? After work, and instead of the hundred other things that need to be done around the house? Sheesh, that's why I work: to be able to afford good-quality tools that will save me time.
The same goes for software - Linux is great for futzing around, but I'd rather work for a few hours and buy software that *just works*, than spend even more time recompiling drivers and getting the damn thing to run properly. It's bad enough that I have to deal with grumpy computers for my day job, thank you very much.
I think it's necessary to raise the question of what exactly has changed since the late '60s.
An article that actually analyzes these issues would make a spectacular read.
Alas, instead of doing that, this article only picked out a few random, specific pieces for discussion, and made a few observations about them. The questions you mention didn't seem to be reflected in the finished piece at all. And the flippant tone and lack of breadth or depth suggest a rather unflattering modus operandi.
TMMM is a complicated book about complicated processes; spending two pages discussing only a few of its elements does it no justice at all. But the questions you mention are very much worth asking, and should not be abandoned because of a rough start on one article.
I wholeheartedly hope that the author would take another look at his article, and maybe write another, this time really comprehensive, in-depth analysis of how and whether the practice of programming changed since TMMM. Maybe even publish it as a series of articles on the site. A comprehensive analysis of Brooks's postulates would be a most welcome contribution.
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
Indeed. The Brooksian concerns may be situated in a different era, but the reviewer's derision betrays a pervasive lack of understanding of the underlying constraints - and that within those constrainsts, Brooks actually makes some damn good points.
For example, the APL story, where the reviewer ridicules the anachronistic idea of renting memory for software. And yet, he completely misses Brooks's larger point - that the cost of ownership for software is not just from the code itself, but from code plus the infrastructure it requires. Once we generalize it to modern kinds of infrastructure (e.g. bandwidth costs), we see the lesson is just as valid, and just as ruthless to those who haven't learned it.
Not to mention other instances of missing the forest for the trees. Sure, Brooks may have foreshadowed XP and other strange team development approaches. But his points were much more fundamental - that team efficiency is sublinear with respect to team size and non-monotonic, that it peaks at fairly small team sizes, and then starts decreasing, etc. Indeed, this analysis did not merely foreshadow development styles - such analysis made them possible at all.
But the author is a self-professed neophyte, so maybe this review should be taken with a grain of salt.:) However, it does make one wonder why O'Reilly would publish it. Are they that desperate for contributions?
Motivation is the gain for scientific knowledge. Reviews will be better because 50 eyes are better than 3.
I'm sorry, but that's simply not true. 50 people with mediocre knowledge of an area are next to useless compared to 3 experts, who can actually evaluate the work. Quantity does not beget quality (as even casual observation of/. readily demonstrates:).
Nominate reviewers in the scientific community. Rate articles, and if they get a high enough score they are posted to the main page. The few with the highest scores each month are "Published" in a special monthly addition.
Heh, yes, that's pretty much how peer review works right now. Except instead of "posted on the main page" people say "published in the journal", and instead of "highest scores" they say "best reviews".:)
Well, there's much good to be said about dead trees.:) On one hand, paper journals are great for archival purposes - you can go to your local library, and dig up publications from a hundred years ago. At the same time, the internet is entirely too impermanent - what if Springer Verlag publishes a journal, and then they go bankrupt in 10 years? The chances of the publications disappearing or becoming unavailable are pretty high. But endangering the access to all the accumulated knowledge simply because of economic accidents is not an acceptable risk in the scientific community.
So a joint paper/electronic model seems like the right balance. Most journals do that already - libraries subscribe to dead tree versions, and individuals can access the papers online, usually through a school-related discount subscription. Seems to work quite well although, paradoxically, it increases the cost per unit (because now you're printing far fewer issues).
But there's simply no incentive for publishing houses to make the online content completely free. Professional organizations can do it themselves (e.g. the AI Access Foundation), where they publish online papers themselves, and contract with a publisher to print each entire volume as a book. Non-profits like these will probably be the harbingers of new method of distribution for scientific findings...
the lengthy article finally asserts: "And that's where were headed, like it or not. No physical media. No rentals. No used games. No sharing games among friends. Limited hardware upgrades. Pay-to-play. Unless something seriously changes the course of the industry, this is the future."
and even at the end of the painfully apocalyptic argument, he still hasn't managed to convince me this will be a bad thing at all.
games without physical media - wonderful! i lose the warm comfort of actually owning the shiny disc, but i gain the ability to install and play the game whenever and wherever, without worrying about lugging the media with my laptop, having to have the CD in the disc drive, losing it, etc.
no rentals? now that's absurd. of course there will be rentals. publishers aren't so dumb that they don't realize many gamers don't actually want to buy everything; that they're willing to pay a cheaper rate to try a game out for a short while. and an automatic delivery system like steam would make it easy to do just that.
indeed, steam would be much better for the independent developers than the current blockbuster-style rentals, of which the author is so fond. at a rental shop, when i rent a PS2 game the profit goes to the shop. over steam, however, the developer could arrange to rent their games, earning the profits themselves, and only paying valve for the use of their infrastructure.
then the author's attacks shift to DRM. "limited hardware upgrades" and "no sharing among friends" pop up in a frequent, if circumspect, manner. and here he's finally getting it. the new approach goes to great lengths to prevent piracy.
what bothers me, however, is that the author seems convinced that anti-piracy measures are bad. why? while i understand the motivations of the typical high-schoolers who want the ability to copy and trade as many games as they can, only the most ridiculous ones would argue that piracy is actually a positive social force for which our techologies should accommodate.
that's just patently absurd. people who make the games need to get paid. and our technologies need to prevent people from stealing the fruits of others' years of hard work.
first off, long term maintenance will be a problem. once you move on to a better job, the owners will have to deal with the networking themselves. so build them a system that's hands-off (ie. doesn't need patches:), or that then can administer themselves.
i'd stay away from deploying your own linux-pc-based solution for as long as you can. a hardware box that includes all functionality would clearly be best, even if slightly more expensive. eg. a wireless router with bandwidth management. something that, once set up, remains easy to use. unfortunately i don't know of any specific models that would do exactly what you want. you could always talk to the manager of some starbucks, or borders bookstore, and ask them what they use.:)
second, i like the idea of not going with the subscription model. my local coffeehouse just deployed wifi (using facefive), and when they did a test run for free, it caused quite a stir - a lot of people were coming in for the internet, and i think buying more. then they switched to the subscription model (only barely cheaper than starbucks), and it stopped.:(
and while anecdotal evidence proves nothing, i just mean to say that a tip-jar model, even if it doesn't bring explicit income to cover wifi costs, should cause increased traffic, especially from students. this should translate to higher sales, and most likely also longer table occupancy. you should do a test run for three months, and see whether it pays off.
It's curious that no one mentioned the problems of imagery and ambiguity. This is the stuff that feeds poetry; but it poisons programming.
What I mean is - good poetry strives on association, connotation, and ambiguity. First, with linguistic surface features. We can bring about feeling or imagery by only hinting at it. Sometimes we don't even need to hint, but merely picking the right sounds. [1] And this requires an extraordinary amount of intuition about how we read.
And then there are higher-level ambiguities, such as when by deliberately masking elements of the situational frame (who is speaking? to whom are they speaking? what are they speaking about?) we can achieve multiple meanings, which will lead to completely different interpretations of the entire piece.
But this goes completely against the rules governing computers, which require their commands to have absolutely clear semantics. You just can't give the computer ambiguous code; indeed, ambiguous code doesn't exist (except when the ambiguity is in the inexperienced programmer's head; the computer always knows exactly what it means).
there's a joke along those lines. if you ask a pole whom to shoot at first, germans or russians, what will he say?
germans first. business before pleasure.
for example the warsaw uprising, which i bet the mod doesn't even consider. when poles started an uprising against nazi occupants in warsaw, the red army was right outside the city - but instead of helping they sat on their hands and waited for germans to massacre half of warsaw.
and then my friends wonder why we have such a massive chip on our collective shoulder.:)
I guess I have to scrap my 'Europe-during-the-black-plague-simulator."
actually, there exists a board game called black death. it's a plague strategy game set in 15th-century europe.
each player takes on a role of a different pathogen, with the goal of wiping out as much of the population as possible. but you have to be careful, because you mortality rate will work against your ability to propagate, and you may burn yourself out too quickly.
heh, yes, that has to be one of the worst bbc taglines i've seen.:) but what the article is trying to say is quite worthwhile: that people who make video games need to concentrate on making them fun for people who won't put up with the broken affordances of today's products. and in doing so, they'll have to fix them.:)
to make this somewhat on topic, i'd actually say that i have to disagree with the article. i think if you concentrate and try to push it out to a demographic thats not familiar with gaming, they'll just resist it more than they normally would.
if you push present products onto an unsuspecting populace, then yes, they will, as they should. but what about if you start fixing games, so they actually appeal to more than the standard asocial obsessive-compulsive type?:)
video games are often broken. for example, time investment. games often require sinking several continuous hours at a time, and not many people can afford that (students excluded:). developers that want to target working adults need to fit games into their lives, not the other way around.
another example are broken reward/punishment schedules: negative conditioning cycles are commonly hidden in mundane game elements, such as in having to reload a level until you get it right. pavlov would be proud.:)
and then there's juvenile storytelling, which is a huge turn-off. most people don't bother with pulp fantasy because it's puerile; why should they bother with even worse RPGs?:)
there are, of course, more problems than that, and they are complex, and without easy fixes. and maybe they will get addressed eventually, if hardcore gamers only stopped touting them as features...:)
Now, if the Open Source movement sees its installed base of desktop users reach a critical mass, it can enable a new generation of game designers, who will be shut out of the existing game industry because there is nothing else for them there.
noble sentiment but, sadly, naive. open source will not help game designers. (to say nothing about leading the next hardware revolution!)
games are extraordinarily expensive to make, but the cost isn't driven up by software. modern games require a team of specialists to build or adapt the basic engine, a very talented team of artists to produce the graphic and sound assets, perhaps a team of level designers and scripters, and of course people responsible for high-level gameplay design - to say nothing of production, marketing, and other people on the business side of the fence. all these people bring their expertise into play, and that ends up being really expensive.
can open source help with this? no, not really.
suppose we live in the best possible world, where all of the software used in game production is open-sourced - all game engines, all physics and AI engines, all modeling tools, all graphics software, everything. even in that world, games would retain high production costs - because the cost of making games is not in the tools, but in using the tools to produce content. what's worse, our world isn't too far from that ideal world - many tools are already open-sourced or otherwise available (quake engine is free, torque is available for minimal costs, some modeling tools are free, etc). you could create a game today using only free tools. but revolutionary new games by garage designers are still nowhere to be found. again, this is not surprising. the cost of making new games is not in the tools, it's in the many man-years it takes to produce a polished game using those tools.
the days of shareware garage games aren't over - people will always enjoy simple games, as the success of snood and cell phone games demonstrates - but they have been permanently demoted to a secondary role in the industry. gamers want well-designed, highly-polished games, and are willing to pay for them. this is not a domain that open-source can assist or compete in.
trying to define AI is always problematic. very much like trying to define philosophy.:)
the classic sense of AI might have been that of search and planning. but for the last 20 years or so, many non-search and non-symbolic approaches have been treated as equals in the discipline, including:
behavior-based robotics
affective computing
software agents
...and of course particular techniques like neural networks, bayes nets, markov model approximations, etc.
castelfranchi's introductory article in that issue actually mentions the various schisms against classic AI, which have come to be successfully reconciled with and included in the discipline.
but your're absolutely right, cog sci is more concerned with mimicking human cognitive processes. which is why AI cannot simply be a branch of it.:)
Slashdot Mirror
Yes, that would help with testing, but also multiplies the work: now you have patches and the new test suite to maintain and shepherd through upgrades. :)
Testing patches actually wasn't the main obstacle. The far bigger time sink was when some patched piece of functionality moved over to a different location in the codebase. Then the engineer had to go and become familiar with their changes, find how things got rearranged, and adopt the patch to the new code. That's a lot of unnecessary work just to maintain the status quo.
As for whether we needed to upgrade so frequently - yeah, we actually did. Hopefully the OP doesn't, though. :)
Maintaining custom patches for a foreign codebase is going to be painful, proportionally to the number of patches, and how badly spread out they are through the codebase.
Consider this: every time the Rails team changes things, you'll have to go through your patches and make sure they still apply correctly. And if, heavens forbid, they do some major refactoring, you'll have to spend the time figuring out what functionality got moved where, and re-apply the patches as necessary.
My project was maintaining a custom set of patches for a major open source library for a while, and it was fairly labor-intensive: every time the library provider released a new version, a senior engineer spent a good part of a day going through the codebase and repatching it, testing the new version, etc. The problem was, however, that they released new versions frequently, and we needed them as soon as they were released.
If your patches aren't going to migrate upstream, I'd be very wary of spending a lot of time maintaining them as the core library keeps evolving. Try to measure how much time it would take to update your local patched Rails when they release a new version (especially a major one, if you can), and project future work estimates from that.
For us, we ended up sacrificing functionality for development speed, and we switched to a less capable library that worked right out of the box without endless patching.
So yes, there's a lots of parts that people don't necessarily understand. Besides, facts would get in the way of a good flame fest.
Easier still: write up your findings, and send them to the copyright office to get them registered, which is really cheap. Then license your copyright to anyone who wants it. Voila! :)
Worse yet, it's a repository that anyone can change at any time.
When I review conference papers, I regard any references to Wikipedia articles as red flags, and request that they be fixed. The problems are two-fold.
One, anyone can write anything in them, which makes them worthless as authoritative sources - it's like citing newspaper articles, great for bits of cultural background knowledge, but I can't expect much accuracy, since I can't tell if the author knows anything about what they describe. Better sources have authors whose careers and reputations will be damaged if they don't research their articles correctly, and editors who go through those articles with a fine-tooth comb looking for any mistakes. But Wikipedia makes itself deliberately anti-authoritative, by allowing any information to be published, and eschewing the editorial process altogether.
Two, anyone can change them at any time, which makes them worthless as sources for future scholarship - by the time the future reader looks up the citation in the Wikipedia, chances are the article will have changed. (And yes, adding version numbers to references can fix that, but authors never choose to do that.)
A 50MB distro is called "damn small"? Damn. I remember when Slackware 1.x core came on a couple of floppy disks. And if you wanted a good text editor, you had to find one on Archie and get it yourself. But we were happy in those days. :)
Exactly. It'll pay a prof and several grad students for a year or two. Not a lot of money.
Besides, Darpa is funding a large number of different AI projects right now, as they have been for the last, I don't know, few dozen years... Why is this newsworthy?
Check out this picture, it's worth a thousand words. The key got leaked very early on, and it was one of the keys blacklisted starting in SP1.
From the article: "In short, "open sourcing" projects like Half-Life 2 would likely lead to much better games, which would result in much better sales and happier end-users."
This is like saying GM should open-source the blueprints for all their car engines. It's ridiculous. Valve put untold millions into HL2 development, and there's absolutely no incentive for them to just open the source, and there's a strong disincentive: if they were to open it, everyone could just build a highly competitive game on top of it without paying a cent. And what's gonna pay for the programmers? The original game's sales? Will they be high enough given the man-hours that went into the engine, especially since the new competing games would likely cannibalize the sales of the original game?
The HL SDK already opens up most of the engine (sans some of the graphics and networking, I believe), and budding game programmers can cut their teeth on that (that's how Counter-Strike came about). But since it's still copyrighted, and the new game requires licensing with Valve, which helps them recoup the costs of developing it in the first place, and fund the development of the new engine.
To ignore the economic constraints of development is breathtakingly naive.
I've been lurking here a long time, and still wonder when exactly this fundamentalist turn happened.
:) Slashdot has always been a flippant, slightly myopic Linux-geek site, full of l337 undergrads and opinionated sysadmins. Like a meeting of some gigantic Linux User's Group, it's both exciting and stupefying. :)
About 1997, no?
Funny, isn't there a Microsoft Research project that did this already?
Oh yeah, so there is, along with papers explaining how it works. So much for giving credit for prior work.
Amen to that! :) When do these people find the time to do this thrifting? After work, and instead of the hundred other things that need to be done around the house? Sheesh, that's why I work: to be able to afford good-quality tools that will save me time.
The same goes for software - Linux is great for futzing around, but I'd rather work for a few hours and buy software that *just works*, than spend even more time recompiling drivers and getting the damn thing to run properly. It's bad enough that I have to deal with grumpy computers for my day job, thank you very much.
I think it's necessary to raise the question of what exactly has changed since the late '60s.
An article that actually analyzes these issues would make a spectacular read.
Alas, instead of doing that, this article only picked out a few random, specific pieces for discussion, and made a few observations about them. The questions you mention didn't seem to be reflected in the finished piece at all. And the flippant tone and lack of breadth or depth suggest a rather unflattering modus operandi.
TMMM is a complicated book about complicated processes; spending two pages discussing only a few of its elements does it no justice at all. But the questions you mention are very much worth asking, and should not be abandoned because of a rough start on one article.
I wholeheartedly hope that the author would take another look at his article, and maybe write another, this time really comprehensive, in-depth analysis of how and whether the practice of programming changed since TMMM. Maybe even publish it as a series of articles on the site. A comprehensive analysis of Brooks's postulates would be a most welcome contribution.
Picking on Fred Brooks' TMMM by noting it's anacrhonisms is about the most juvenile thing I can imagine. I can only surmise that the alleged reviewer was forced to read the book by somebody he did not like, and while he read the words he certainly didn't extrapolate the lessons to his present day situations.
:) However, it does make one wonder why O'Reilly would publish it. Are they that desperate for contributions?
Indeed. The Brooksian concerns may be situated in a different era, but the reviewer's derision betrays a pervasive lack of understanding of the underlying constraints - and that within those constrainsts, Brooks actually makes some damn good points.
For example, the APL story, where the reviewer ridicules the anachronistic idea of renting memory for software. And yet, he completely misses Brooks's larger point - that the cost of ownership for software is not just from the code itself, but from code plus the infrastructure it requires. Once we generalize it to modern kinds of infrastructure (e.g. bandwidth costs), we see the lesson is just as valid, and just as ruthless to those who haven't learned it.
Not to mention other instances of missing the forest for the trees. Sure, Brooks may have foreshadowed XP and other strange team development approaches. But his points were much more fundamental - that team efficiency is sublinear with respect to team size and non-monotonic, that it peaks at fairly small team sizes, and then starts decreasing, etc. Indeed, this analysis did not merely foreshadow development styles - such analysis made them possible at all.
But the author is a self-professed neophyte, so maybe this review should be taken with a grain of salt.
Motivation is the gain for scientific knowledge. Reviews will be better because 50 eyes are better than 3.
/. readily demonstrates :).
:)
I'm sorry, but that's simply not true. 50 people with mediocre knowledge of an area are next to useless compared to 3 experts, who can actually evaluate the work. Quantity does not beget quality (as even casual observation of
Nominate reviewers in the scientific community. Rate articles, and if they get a high enough score they are posted to the main page. The few with the highest scores each month are "Published" in a special monthly addition.
Heh, yes, that's pretty much how peer review works right now. Except instead of "posted on the main page" people say "published in the journal", and instead of "highest scores" they say "best reviews".
Well, there's much good to be said about dead trees. :) On one hand, paper journals are great for archival purposes - you can go to your local library, and dig up publications from a hundred years ago. At the same time, the internet is entirely too impermanent - what if Springer Verlag publishes a journal, and then they go bankrupt in 10 years? The chances of the publications disappearing or becoming unavailable are pretty high. But endangering the access to all the accumulated knowledge simply because of economic accidents is not an acceptable risk in the scientific community.
So a joint paper/electronic model seems like the right balance. Most journals do that already - libraries subscribe to dead tree versions, and individuals can access the papers online, usually through a school-related discount subscription. Seems to work quite well although, paradoxically, it increases the cost per unit (because now you're printing far fewer issues).
But there's simply no incentive for publishing houses to make the online content completely free. Professional organizations can do it themselves (e.g. the AI Access Foundation), where they publish online papers themselves, and contract with a publisher to print each entire volume as a book. Non-profits like these will probably be the harbingers of new method of distribution for scientific findings...
the lengthy article finally asserts: "And that's where were headed, like it or not. No physical media. No rentals. No used games. No sharing games among friends. Limited hardware upgrades. Pay-to-play. Unless something seriously changes the course of the industry, this is the future."
and even at the end of the painfully apocalyptic argument, he still hasn't managed to convince me this will be a bad thing at all.
games without physical media - wonderful! i lose the warm comfort of actually owning the shiny disc, but i gain the ability to install and play the game whenever and wherever, without worrying about lugging the media with my laptop, having to have the CD in the disc drive, losing it, etc.
no rentals? now that's absurd. of course there will be rentals. publishers aren't so dumb that they don't realize many gamers don't actually want to buy everything; that they're willing to pay a cheaper rate to try a game out for a short while. and an automatic delivery system like steam would make it easy to do just that.
indeed, steam would be much better for the independent developers than the current blockbuster-style rentals, of which the author is so fond. at a rental shop, when i rent a PS2 game the profit goes to the shop. over steam, however, the developer could arrange to rent their games, earning the profits themselves, and only paying valve for the use of their infrastructure.
then the author's attacks shift to DRM. "limited hardware upgrades" and "no sharing among friends" pop up in a frequent, if circumspect, manner. and here he's finally getting it. the new approach goes to great lengths to prevent piracy.
what bothers me, however, is that the author seems convinced that anti-piracy measures are bad. why? while i understand the motivations of the typical high-schoolers who want the ability to copy and trade as many games as they can, only the most ridiculous ones would argue that piracy is actually a positive social force for which our techologies should accommodate.
that's just patently absurd. people who make the games need to get paid. and our technologies need to prevent people from stealing the fruits of others' years of hard work.
but this the author doesn't seem to grasp.
first off, long term maintenance will be a problem. once you move on to a better job, the owners will have to deal with the networking themselves. so build them a system that's hands-off (ie. doesn't need patches :), or that then can administer themselves.
:)
:(
:)
i'd stay away from deploying your own linux-pc-based solution for as long as you can. a hardware box that includes all functionality would clearly be best, even if slightly more expensive. eg. a wireless router with bandwidth management. something that, once set up, remains easy to use. unfortunately i don't know of any specific models that would do exactly what you want. you could always talk to the manager of some starbucks, or borders bookstore, and ask them what they use.
second, i like the idea of not going with the subscription model. my local coffeehouse just deployed wifi (using facefive), and when they did a test run for free, it caused quite a stir - a lot of people were coming in for the internet, and i think buying more. then they switched to the subscription model (only barely cheaper than starbucks), and it stopped.
and while anecdotal evidence proves nothing, i just mean to say that a tip-jar model, even if it doesn't bring explicit income to cover wifi costs, should cause increased traffic, especially from students. this should translate to higher sales, and most likely also longer table occupancy. you should do a test run for three months, and see whether it pays off.
and when you do that, please post the results!
It's curious that no one mentioned the problems of imagery and ambiguity. This is the stuff that feeds poetry; but it poisons programming.
What I mean is - good poetry strives on association, connotation, and ambiguity. First, with linguistic surface features. We can bring about feeling or imagery by only hinting at it. Sometimes we don't even need to hint, but merely picking the right sounds. [1] And this requires an extraordinary amount of intuition about how we read.
And then there are higher-level ambiguities, such as when by deliberately masking elements of the situational frame (who is speaking? to whom are they speaking? what are they speaking about?) we can achieve multiple meanings, which will lead to completely different interpretations of the entire piece.
But this goes completely against the rules governing computers, which require their commands to have absolutely clear semantics. You just can't give the computer ambiguous code; indeed, ambiguous code doesn't exist (except when the ambiguity is in the inexperienced programmer's head; the computer always knows exactly what it means).
--
1. And I don't mean just onomatopoeia. E.g. Ginsberg's "boxcars boxcars boxcars racketing through snow".
there's a joke along those lines. if you ask a pole whom to shoot at first, germans or russians, what will he say?
:)
germans first. business before pleasure.
for example the warsaw uprising, which i bet the mod doesn't even consider. when poles started an uprising against nazi occupants in warsaw, the red army was right outside the city - but instead of helping they sat on their hands and waited for germans to massacre half of warsaw.
and then my friends wonder why we have such a massive chip on our collective shoulder.
I guess I have to scrap my 'Europe-during-the-black-plague-simulator."
:)
actually, there exists a board game called black death. it's a plague strategy game set in 15th-century europe.
each player takes on a role of a different pathogen, with the goal of wiping out as much of the population as possible. but you have to be careful, because you mortality rate will work against your ability to propagate, and you may burn yourself out too quickly.
morbid, but great fun.
but is it a slow news day or what? =)
:) but what the article is trying to say is quite worthwhile: that people who make video games need to concentrate on making them fun for people who won't put up with the broken affordances of today's products. and in doing so, they'll have to fix them. :)
:)
:). developers that want to target working adults need to fit games into their lives, not the other way around.
:)
:)
:)
heh, yes, that has to be one of the worst bbc taglines i've seen.
to make this somewhat on topic, i'd actually say that i have to disagree with the article. i think if you concentrate and try to push it out to a demographic thats not familiar with gaming, they'll just resist it more than they normally would.
if you push present products onto an unsuspecting populace, then yes, they will, as they should. but what about if you start fixing games, so they actually appeal to more than the standard asocial obsessive-compulsive type?
video games are often broken. for example, time investment. games often require sinking several continuous hours at a time, and not many people can afford that (students excluded
another example are broken reward/punishment schedules: negative conditioning cycles are commonly hidden in mundane game elements, such as in having to reload a level until you get it right. pavlov would be proud.
and then there's juvenile storytelling, which is a huge turn-off. most people don't bother with pulp fantasy because it's puerile; why should they bother with even worse RPGs?
there are, of course, more problems than that, and they are complex, and without easy fixes. and maybe they will get addressed eventually, if hardcore gamers only stopped touting them as features...
only once the C++ committee gives in to prefix notation: (++ (++ (++ (++ c)))) :)
Now, if the Open Source movement sees its installed base of desktop users reach a critical mass, it can enable a new generation of game designers, who will be shut out of the existing game industry because there is nothing else for them there.
noble sentiment but, sadly, naive. open source will not help game designers. (to say nothing about leading the next hardware revolution!)
games are extraordinarily expensive to make, but the cost isn't driven up by software. modern games require a team of specialists to build or adapt the basic engine, a very talented team of artists to produce the graphic and sound assets, perhaps a team of level designers and scripters, and of course people responsible for high-level gameplay design - to say nothing of production, marketing, and other people on the business side of the fence. all these people bring their expertise into play, and that ends up being really expensive.
can open source help with this? no, not really.
suppose we live in the best possible world, where all of the software used in game production is open-sourced - all game engines, all physics and AI engines, all modeling tools, all graphics software, everything. even in that world, games would retain high production costs - because the cost of making games is not in the tools, but in using the tools to produce content. what's worse, our world isn't too far from that ideal world - many tools are already open-sourced or otherwise available (quake engine is free, torque is available for minimal costs, some modeling tools are free, etc). you could create a game today using only free tools. but revolutionary new games by garage designers are still nowhere to be found. again, this is not surprising. the cost of making new games is not in the tools, it's in the many man-years it takes to produce a polished game using those tools.
the days of shareware garage games aren't over - people will always enjoy simple games, as the success of snood and cell phone games demonstrates - but they have been permanently demoted to a secondary role in the industry. gamers want well-designed, highly-polished games, and are willing to pay for them. this is not a domain that open-source can assist or compete in.
the classic sense of AI might have been that of search and planning. but for the last 20 years or so, many non-search and non-symbolic approaches have been treated as equals in the discipline, including:
- behavior-based robotics
- affective computing
- software agents
- ...and of course particular techniques like neural networks, bayes nets, markov model approximations, etc.
castelfranchi's introductory article in that issue actually mentions the various schisms against classic AI, which have come to be successfully reconciled with and included in the discipline.but your're absolutely right, cog sci is more concerned with mimicking human cognitive processes. which is why AI cannot simply be a branch of it.