My post roughly followed the order of the original article. On page one the author definately suggested that risk is good, and that current common risks are money, increased difficulty, having to restart the game, and time. He then goes on to blow off wasting time as "not a real risk". After ignoring that restarting the game directly translates into wasting time, and increased difficulty indirectly does he goes on to spend the rest of the article bashing washing time. The implication is that the other three risks are reasonable risks.
Honestly, I don't see where he contradicts himself. He never argues that wasting time is not a real risk. If you'd point me to the passage in the article that descibes that, I'd be grateful to reconsider my position on that point.
That's a matter of game balance, possibly in the form of automatic difficulty adjustment, alternate paths, or user controlled difficulty. I agree, it's a rare game I'm willing to retry a section 20 times for. But I think it's reasonable to expect players to occasionally replay sections a few times. It provides risk, simultaneously provides practice, and so long as the player succeeds before getting frustated provides a real sense of accomplishment.
Ah, ALTERNATE PATHS. This is precisely the crux of the entire article. He argues that alternate paths should be available to players in order to provide all types of players the ability to complete the game, rather than just hard core gamers, who seem to think they are the only group games are made for. He further postulates that easier paths should have a penalty attached to them, which he believes should be a longer completion time period.
That is, worse players get less play time and get bad ending, while good players play more and get good ending.
It's pretty clear that the author dislikes that proposal, as do I. I doesn't reward skill, it rewards grinding. It's the sloppy solution some games use to claim "replayability." It's one of the reasons I find much of the console RPG genre frustrating.
I agree, this is far less disirable. Just wanted to point out that this option was presented.
I can see the reviews now. "If you really good at this type of game, it's amazing. If you suck, but still enjoy it, you're in for a snorefest." After complaining about games that make you retry 20 times, you're offering less skilled players the exact same option. "Retry the harder, higher risk option until you succeed, or get a worse game. Want to see the best setpieces and setups, you're going to be retrying over, and over, and over.
Low skill players aren't just playing because they want to get to the end. They play for the same reason that more skilled players do: the game is inherently enjoyable. It seems like a bad idea to take the best of a game away from them because they lack the skills. Indeed, those very skills would best be honed by giving them challenging but still enjoyable games that they can finish.
I completely agree with paragraph 2. Especially "...challenging but still enjoyable games THAT THEY CAN FINISH." Emphasis mine, obviously.
I completely disagree with paragraph 1.
I will try and rephrase some key points from my original reply which may not have been clear: 1) It doesn't have to be binary. Its not going to be all hard or all easy. The vast, vast majority of players will land somewhere in between. Meaning that many times they will complete the hard path, and only when they become completely and utterly frustrated will they go for the easier one. 2) Setups should be reserved for the hard route only when an "easy" version of that route is not feasible or breaks the suspension of disbelief in the game. I didn't say ALL the best setups should be reserved for the hard route. In general though, the hardest route should include almost all of the most exciting content. This leaves the player an incentive to at least attempt the hard route. 3) Current games r
RPGs can, for the most part, be broken down into many tasks which the player must complete. Some of these tasks may be optional, but in almost all games a certain number of tasks will be required for the player to progress in the game. Even in a MMORPG, you must often complete a certain task to progress further, such as kill a certain monster or open a certain portal in order to move to the next environment.
The author is proposing that each of these tasks should have multiple methods of completion. There might only be two, an "easy" and a "hard", or there might be more. Regardless, his point is that there should be a risk/reward tradeoff that the player must choose. Do they attempt the harder method, which will be quicker and more action packed, but more likely to result in defeat? Or do they attempt an easier path, which takes longer to complete, but is far less likely to result in defeat?
Even in a true open-ended game, one that has no overall goal, there still will be tasks to complete in the game. If developers were to offer risk/reward tradoffs of methods to complete the tasks, games would be more accessible to players who desire less risk, but still exciting for players who like playing a more high-stakes format.
Wow, you completely missed the point of the article. Are you sure you read it?
"He's seriously advocating that it's reasonable that if you fail at a risk in the game, the game should become harder."
He's not advocating that the game becomes harder, quite the opposite, in fact. What he's advocating is that the player should be able to choose between taking more high risk paths, or more low risk ones. High risk paths are more intense, and more difficult, meaning they are more likely to result in a penalty should the player not succeed. But they're shorter, they take less time to complete. Low risk paths are less difficult, so the chance of the player incurring a penalty would be less. However, these low risk paths require the player to play the game for a longer period of time in order to achieve the same result as the high risk path.
"Yes, you only get one path at a time in Ico, you're forced to replay a section until you beat it. Those failed attempts are called 'practice.'"
Your "practice" is my "curse you, lazy game developer". If I am unable to complete a section within about 20 tries, I'm done with a game (less if the section is very long, say more than 15 minutes). If the game developer did not allow for any changes in difficulty settings, or alternate paths, I will simply cease playing the game. Its supposed to be a game, to be FUN. I find about the 20th attempt at something to become a lot more like work than fun. When a video game becomes work, thats when it gets turned off. You may make a counter arguement that "well, if you give up like that in something like golf or skiing, you'll never get any good". And thats true, but those are things I can do for my entire life, activities which contribute to my well being. I have a much greater incentive to put work into those activities than a video game, which I will play for 20 hours or so and then retire to a shelf, regardless of whether I finish it.
"You'll then have the skilled players (which include many professional reviewers) either blow through it quickly and complain there wasn't much content for their money, or play it slowly and complain it's too easy. Either way you get bad reviews."
The author also posits, in the closing footnotes, that an alternate option is available. From the article: "It has been said to me that it is equally valid to make content the wager and have the worse player complete the game in eight hours, getting the 'bad ending', while the good player gets through all 40 hours and gets the best ending. This is debatable."
"He's still talking about punishing weaker players by costing them time (which is still money)."
Very true, a position which the author does not deny. The author, however, does not see this as a punishment, but rather an option that the player may choose. The point is that current games very often do not offer the player any sort of risk/reward option. The player must simply complete the task in the way that the game developer designed it, or quit. Take the most recent Ninja Gaiden, for instance. The first version, the one not titled "Black", did not have any difficulty settings. The game is linear and requires players to beat bosses in order. Thus a "weak" player will never see all of the games content anyway, having to quit at the point at which they are unable to advance in the game. This is, quite simply, a poor game design from the viewpoint of the author, and I happen to wholeheartedly agree.
I would even go so far as to say that the high risk path should be more exciting, and offer the best content. Players who take high risk paths should be rewarded with more invigorating environments, with more intense and exciting situations. Thus the high risk gamer will see the absolute best the game has to offer, the best setpieces and setups, the most action packed into a smaller time frame. The other, lower risk options may still include some of the same setpieces, but some of the very best ones might be missed when they just don't a
Yes, I'm sure paying less than 1/3 of the cost in salary and benefits isn't whats attacting companies to outsource. Seriously, you actually believe thats not the main factor?
Reductions in litigation and regulations may seem advantageous, however, I tend to disagree somewhat. Who's at more of an advantage, an employee making 50K per year or a corporation pulling down 20+ billion in profits? Large corporations have fleets of well paid lawyers. As for regulations, there's a reason that large corporations pour millions into PACs and other political concerns...
I think work ethic can be debated, most certainly. Are there lazy people? Sure, especially in a good economy, where the pressure to work hard is reduced. But the people at the top of their profession, such as high quality software developers, did not get there by being lazy, believe me.
Taxes are a legitamite concern, yes, but I consider that part of the reduction in payroll required when outsourcing.
All-in-all it comes down to this: There are only so many high quality developers to go around. India may be cranking out mediocre programmers by the barrelfull, but its not increasing the top quality developers at a very much increased rate. You see the same thing in the U.S. There are tons of mediocre programmers coming out of the ITTs and Devrys of the world, heck even quality CS programs produce a number of mediocre developers. A much smaller number of people who can be considered true Software Architects, who continue to develop and broaden their skillset and gain valuable experience in the best practices for building software - those are the valuable people. Even in India, those people don't grow on trees.
PopSci has been throwing out articles regarding this topic for quite a while now, I think they've had at least two major articles on the subject. One of the key innovations is a "highway in the sky" setup for these new small jets which will make it dramatically easier to fly this sort of aircraft. Implied is that qualifications for flying these "air taxies" will be far less restrictive than current commercial aircraft. The result, hopefully, will be more pilot jobs as the industry expands, which would be lower paying jobs than what current pilots make due to less required experience. Both of these are critical, as more pilots would be required to support it and lower pilot salaries for these flights would be required to keep it affordable.
I for one, very much hope this new air taxi industry will get underway as I'm waiting for a flight right now that is delayed 1.5 hours.
1) Schedule stuff to run at a given time. 2) Priveledge escalation and/or impersonation.
Why do those feel like hacks? They are.
I'm not sure why you think installing software on Windows is painful. I've not run into any application that didn't install via a convenient executable that I simply double clicked.
ACPI has been flaky for a long time. The reason FreeBSD has a workaround to get it to work right and Windows doesn't is that somewhere a FreeBSD user took it upon himself to fix the issue. Unfortunately its not cost effective for Microsoft to go back and make these sort of fixes/repairs for specific platforms or hardware defects.
All that said, when a truly user-friendly distro is available, I'll switch.
I tried a couple of liveCDs recently. Let me give you a scenario: I wanted to use an older TV capture card. Didn't know what the card was. I spent 3 hours trying to find out what card it was and find drivers for it in linux. Windows, after installing the OS, installed the driver for me in seconds. Until I get that sort of performance from linux, I'll just have to stick with Windows.
I have to disagree with this line of thinking, at least at the enterprise level. (In the small software sector, underdesign and overcode may be more often the case.)
Much of the current focus is on attempting to address every conceivable situation and use case scenario up front, then design and execute on a plan to address each and every one. This approach is destined to fail on any sufficiently large product. I believe this is the reason why Extreme Programming made such a splash in the design space when it debuted, as it finally, and I believe correctly, rejected this notion. Unfortunately XP contained numerous other "rules" other than an iterative focus of development, and has as such not gained the mindshare I believe it might have if it had been better conceived.
The fact that XP rejected many other fundamental programming concepts made it unworkable and/or unpalatable for many software designers. Pair programming, far too frequent meetings, and required cross training are completely unworkable in most environments. Most managers will not understand the usefulness of pair programming, even many who are in a corporation devoted solely to software development. I dislike the frequent meeting requirement, as once per day is a significant waste of time. Developers will very often be spending more than one day on a feature and/or mundane code, and this level of review and oversight makes little sense. Required cross training sounds nice on the surface, until one realizes that an expert in a specific area, say regular expressions, or artificial intellegence, or graphics, or whatever it might be; that the expert will spend far more time training a programmer unfamiliar with the specific piece of code than they will actually writing the software. You might say that this is time well spent, but I disagree, as these impromptu sessions delve deeply into specific code and will not cover the core concepts as a whole, nor should they. The result is that the "trainee" most often will not understand the code anyway, and the training session will have served only to waste time and frustrate both the trainer and trainee. Generally, software development is under a deadline and cannot afford to function as a time for in depth training on code specifics.
All this is more of a tangent to my main point, which is that a fundamentally solid design is proper and necessary. However, the continued focus on more and more time spent on rehashing every feature endlessly without putting the product in the hands of its users is wasteful. It is impossible for the end user to fully comprehend how the product will function without using it, and features which they believe to be an absolute requirement for the product are often found to be unwieldly, counterproductive, or entirely useless when the product is completed and delivered. In an iterative environment, various iterations will weed these features out, and result in a better overall product. In addition, developers and testers can NEVER account for every possible scenario end users will create to break the product. Good testing is necessary and important, but I believe it is just as important that the product not be over-tested. Many tested scenarios will never occur in the life use of the product, but nearly infinite untested scenarios will always occur. What if the user opens an email program, while a virus scan is running, and they click a button in the lower left quadrant of the product, which runs code that attempts to use the file system? Sure, this shouldn't break the product, but crazy scenarios often have unexpected consequences which your program may not be equipped to handle. It is far better to deliver the product to the users and let them create the problems for you, elegantly handling exceptions with your program and reporting them to a centralized location, where you can address the most problematic and frequent errors in turn in the next iteration.
In short, continually placing more and more focus at the design time can easily reach a stage where it is counterproductive, and the result is more time and money are spent on a product which ultimately does not deliver the best result for the user base.
The article cites the following risks: disclosure, inference, exposure, loss, guessing, cracking, and snooping, and I'll agree that regular password changes only helps minimize the risk of compromise due to guessing and cracking, and then, only somewhat. But regular password changes can also help to minimize the damage when a password is compromise via other methods.
I have to disagree.
First of all, again: the most common method for password discovery is directly related to the user. If this was the discovery method, our enemy will easily use the same methodology to obtain the password again when it has been changed.
If the password is cracked through guessing, snooping, etc - the problem is that the user is likely to choose a new password which is very close, or just as insecure as their old password. The first thing I would try as a cracker, if someone had a reasonably hard password and changed it, would be to try every variation of the last character. If they had an easy password ("password" or some other dictionary word), I'd just know that I could run a speedy dictionary attack against their password and have it cracked in no time. These two methods of user password changing represent the vast majority - thus forcing a password change has not made the password significantly more secure because the original password was discovered.
I agree with the article, and not the parent post. Constant changing of a frequently used password is a complete failure in the exploration of logic regarding passwords. It is laziness, plain and simple; the reliance on the folklore of old to tell us what we should do. Frequent Password Changing Makes a System More Secure is an old wives tale.
Over time, even a hard password will be memorized by your average user. This password does not somehow become more insecure over time, because, as the article points out, the largest vulnerabilities are not due to the cracking of passwords, but rather human error, ignorance, and/or incompetance. These should decrease with time. The user should become better educated and better able to remember the password, thus less likely to give it out. Only the chance of human error increases slightly (typing password in login box and such). Of the three, this presents the least risk by far of those three, and generally the user is aware of this occurrance and with proper education will know to immediately change their password.
Forcing a user to change password frequently is likely to only cause them to alter one character (likely the last) in the password because committing another secure password to memory is difficult. This causes both usability and security to be comprimised in the same fell swoop. The other option is that they will write the password down or otherwise record it, thus defeating its security. If you've got users with photographic memories who instantly memorize a new hard password every month, you must be the luckiest damn admin in the world.
As the article points out, modern computing and cracking techniques expose vulnerabilities much more quickly, so passwords would have to be changed so frequently as to make a changing password policy useless in many environments anyway.
Caveat: The opposite is true of Administrator passwords or others which are rarely used. These are generally not committed to memory, and likely documented in some fashion (hopefully they are, or when the admin leaves you're screwed). If they're meant to protect a truly important system, a biometric and/or time sensitive method (such as a synchronized continously changing key generator) should be used in addition to the password. Changing these passwords with some frequency is a good idea, as it forces someone to ensure the validity of the current password (the account is not locked or disabled) as well as provide the aforementioned small measure of protection against cracking.
Please, stop forcing password changes on user accounts. Its a stupid idea. It serves no purpose other than to ensure the latest user password is written down at every desk.
What you say is true, but there are two fundamental problems:
1) These types of users sometimes attempt to create a fully realized system. Then when it gets beyond 40 users, and it starts tanking (recent real world example), then what happens? Either they're just hosed, or they have to call in the big guns - real Application Developers. We usually find its easier to start from scratch than attempt to work through the code to figure out what exactly it does. I can't tell you how many of these I've seen in a production environment.
2) More importantly, in many cases, management thinks these guys know what they're doing. They manage to create some little access process that stores a few thousand rows of data, with an Access Report frontend, and suddenly these guys are "Programmers". Then they give them an assignment that ramps up beyond a few hundred thousand rows, the "app" blows up in their face, and now there is a great big emergency and my team suddenly gets a priority shift to replace the stupid Access process in an unrealistic amount of time.
Access, excel; they're great as long as you stay under a certain level of complexity. Most users/corporations don't know where that line lies, and when they step over it, the consequences are often disasterous.
How about trying to find drivers for an unknown ATI AGP card? I got an older TV capture card from a friend, and decided I wanted to see if I could turn and older box I had into something I could watch TV on. Maybe I'd do video capture, maybe not. After about 4 hours trying to find drivers, I gave up. In the Windows world, this is a 5 minute process. Windows autoinstalls prepackaged drivers, I look in the advanced display properties and find what card I have, then I go to the manufacturers website and download the latest driver. If I started with Windows Media Center, I'm watching TV already. If I didn't, it takes another few minutes to download and install a TV watching program.
I'm sure linux is great for Granny who just wants to check email and surf the internet, but until it gives users with good computing familiarity the ability to install a driver for an unknown device in less than 30 minutes, I'm not interested.
Note: Tried this with Knoppix and Gnoppix, as I didn't want to have to do a bunch of command line stuff to install MythTVs "live CD". I have to install a separate server installation that isn't a live CD? Follow some hackneyed installation procedure with a dozen command line options - then I can do a live CD install? All that without knowing if it will actually work. No thanks, I've got better things to do with my time.
Flame on, baby - I've got Karma to burn. You don't like the truth? Start writing drivers.
I think the Cars trailers stink. However, I've watched the Cars preview material on the Toy Story 10th Anniversary edition - and now I'm a lot more interested in seeing it. I'm actually looking forward to seeing it now, rather than the "hmmm, this looks to suck" attitude that I had when I saw the trailer the first time.
Frankly I've never been bowled over by any Pixar trailer. Perhaps the only one that I really liked was the Incredibles trailer, and that only because I immediately thought: "Whoa, Pixar is making a superhero movie? I have GOT to see that!"
I think part of the problem is getting across the premise. Imagine trying to make the trailer for Finding Nemo... so, its a movie about fish, and they have an adventure. But there is one fish captured and he's in a tank and the other one is swimming through the ocean to find him with another fish who has a memory problem, but you can't give away all the best moments in the movie so you have limited scenes to work with.
Same thing with Cars. This is a movie about Cars, but in this universe there are no people, only cars. And racing is the major sport, and there is a character story (I believe a car trying to make the racing circuit) and other things happen along the way, but we can't use all the best scenes in the movie to make the trailer or give away the entire plot - so we're left with a trailer that makes you go "meh".
I've got a 3 year old son, so I'll probably be watching Cars many times - here's hoping it doesn't suck.
I think the point of the parent post is that the word "widget" has long been used in the software industry as a very generic term for an item, perhaps of software, or perhaps used or tracked by software.
Now we're talking about Widgets being something very specific, a "small, componentized peice of code", likely on a web page.
I have to agree with the parent that this is an annoying development. When I say, "we need to develop a generic widget tracker" - to me that means we're going to build a piece of software that tracks widgets - some generic nebulous item of some sort. Now, what am I talking about? You assume that I'm talking about tracking "small, componentized pieces of code", likely ones which are on the web.
The word thus has two separate, differing definitions in the same occupation sphere.
This is critical to understand. When we say "widget", clearly we don't mean definition #1, because that lies outside of the occupation sphere for almost all software development. So clearly we can safely assume the developer meant definition #2, "an unnamed article considered for purposes of hypothetical example". Now, we have no idea which one was meant, and we have to listen for context to pick up the meaning. This detracts from the likely more important task, which is understanding what the other person is trying to convey.
I refuse to use the term "widget" to refer to these small, componentized pieces of code. Couldn't they be called Web Components? Perhaps we could use a term that actually DESCRIBES what the thing is? I can't tell you how irritating this is to me, that we must make up or shoehorn words for things when a simple english phrase would suffice to describe the concept. Its like all these math nerds and their damnable greek alphabet. Take your greek alphabet and stuff it....Rant complete.
All I can say is I'm going to make sure to catch this ASAP - to try and determine whether I can send it out to family members so they can finally understand what exactly it is that I do every day.
You have to remember that glasses have existed for well more than a century now. They've become accepted in a culture where they are now commonplace. I think the same will be true of hearing aids eventually, but hopefully in the short term, someone will design a hearing aid that doesn't look like a horrible growth.
I think the biggest thing is not to try to hide them. Stop making them flesh colored! We don't have flesh colored eyeglasses.
Make them look like a cool peice of tech. Make them comfortable to wear and easy to take off + put on.
I think a lot more people would use hearing aids if they were better asthetically designed.
Anyone who's ever attempted photography at night will have learned this simple fact.
You basically have two choices, when presented with super bright object(s), and other much less bright object(s):
1. Expose the bright object(s) perfectly, leaving the other object(s) unseen because they are underexposed.
2. Expose the less bright object(s) perfectly, leaving the very bright object(s) overexposed and thus, completely unintelligible. (A giant bright ugly blob)
Well, I suppose you can also go for some exposure in between, but then you'll just end up with a bad photograph.
So the designers of the spacecraft correctly decided to expose the Earth beautifully, and leave the stars absent because they are underexposed. They're just blue, yellow, red, etc dots anyway - we don't really need to see them since the Earth is the focus of our attention.
Go ahead, take a few photographs of the sky at night. (Warning - do this with a digital camera, you're going to waste a lot of shots) Try taking pictures of the moon. If you get a decent one.. wait, where are the stars? Leave the exposure on long enough, you'll get the stars. But if you leave the apeture open that long, the moon will just be a tremendous white blob. Same deal with the Earth from space.
As soon as the exclusivity deal was signed, innovation ended. I expect EA to release the exact same game for every year of the contract, with the exception of updated rosters and some new "feature" like the QB vision. Each new feature will be half-assed and poorly implemented.
Football games haven't exactly been known for innovation, but what little did exist is dead now.
The only hope is that the exclusivity contract will cause game developers at other companies to branch out and build truly interesting sports games, ones like Base Wars or Super Baseball Simulator 1.000 perhaps, though obviously football instead of baseball.
Maybe we can get a Blood Bowl game (on a console)?
This has always been the Microsoft approach. It goes something like this:
10: Wait until someone comes up with a great idea. 20: If they'll sell out for cheap, buy them. 30: If they won't sell out, build a competing product that is marginally better than what already exists. 40: Put the massive microsoft marketing machine behind the "new" product. 50: Use Operating System monopoly power to push the new product onto everyone (if applicable). 60: If the product is not dominating the marketplace or crushing competitors out of existence, Goto 20. 70: If the product is dominating the marketplace, abandon the product and let it stagnate. 80: Product cycle complete.
Do they try to come up with their own ideas? Oh, sure they do. However, Microsoft is most successful when they take someone else's great idea and build their own version of it.
How far must we go then, to have "security"? Should we all be strip searched before entering an airplane? What about buses and trains? What about public buildings? At some point, you have to trust that the vast majority of people are not terrorists out to get you.
Inmates in prison are very secure.. are they free? What you propose will make us all inmates in our very own police state.
Is it better to live a life of safety, watched by a suspicious government every second of your life? Not allowed to do anything that might be considered remotely dangerous? Or is it better to accept the fact that your chances of dying by terrist attack are far more remote than everyday occurrances like car crashes and heart attacks, even in places like Israel and Iraq where terrorists attack frequently?
Perhaps you should accept that if someone is out to kill you, and is willing to give up their life to do it, that the amount of "security" does not matter. That sacrificing our freedoms will not stop crazy brainwashed knuckleheads, whether they wear turbans or blue jeans.
I say freedom, I say liberty, and I say we let the makers of the PATRIOT act be hung by the undead writers of the Constitution of the United States.
Oh, the writers of the constitution aren't undead? Drat. Well the rest of it still goes.
Don't let your fear of death and outsiders be the undoing of my freedom. Take your "compromises" and "maximised freedom", and move to China. There are no terrorist attacks in China. Because in China, the terrorists have already won.
First off, the SIMS has a rating of Teen. Not Everyone/Teen. No such rating exists. You can see the gamespot Sims site for confirmation of the rating: Gamespot SIMS info
The SIMS, under normal conditions, does not display nudity. If it did, it would likely have received an M rating, although the inclusion of this one "offensive" item may not have been enough to move it into that category.
The SIMS merely displays naked people when hacked. GTA: SA depicts an actual sex act. This, under the guidelines, clearly would put GTA: SA in the AO category, especially when coupled with the violence already depicted in the game.
The matter is further inflamed by the fact GTA is a game that legislators would just as soon rather had never been created in the first place, already having spawned talk of banning the game due to violence, criminal acts, and general disdain for the law. (though that didn't get far).
I'm sure a similar uproar would have occurred if there were an actual sex act explictly displayed in the SIMS, or if a sex act were "unlockable", even through a hack such as the one in GTA: SA.
I don't necessarily disagree with you that rating of the SIMS, and its sequels and expansion packs might be changed - but it seems unlikely. Even if it did, Walmart and other mainstream stores would still sell the games anyway, as they'd only have M ratings.
- Stores don't enforce ratings, ever. "Oh you are just so wrong here with this statement. Folks, most stores will not sell a video game unless it is ESRB rated. Those stores that _do_ sell non ESRB rated video games are fly by night storefronts, selling fly by night video games. Every respectable video game company has ESRB ratings as part of their publishing standards."
Sure, stores won't sell games unless they are ESRB rated. But few stores (especially "boutique" types) pay any attention to the rating that is actually on the box. Meaning they are not enforcing the rating.
Whether it has a rating or not means nothing if it isn't being used.
Slashdot Mirror
My post roughly followed the order of the original article. On page one the author definately suggested that risk is good, and that current common risks are money, increased difficulty, having to restart the game, and time. He then goes on to blow off wasting time as "not a real risk". After ignoring that restarting the game directly translates into wasting time, and increased difficulty indirectly does he goes on to spend the rest of the article bashing washing time. The implication is that the other three risks are reasonable risks.
Honestly, I don't see where he contradicts himself. He never argues that wasting time is not a real risk. If you'd point me to the passage in the article that descibes that, I'd be grateful to reconsider my position on that point.
That's a matter of game balance, possibly in the form of automatic difficulty adjustment, alternate paths, or user controlled difficulty. I agree, it's a rare game I'm willing to retry a section 20 times for. But I think it's reasonable to expect players to occasionally replay sections a few times. It provides risk, simultaneously provides practice, and so long as the player succeeds before getting frustated provides a real sense of accomplishment.
Ah, ALTERNATE PATHS. This is precisely the crux of the entire article. He argues that alternate paths should be available to players in order to provide all types of players the ability to complete the game, rather than just hard core gamers, who seem to think they are the only group games are made for. He further postulates that easier paths should have a penalty attached to them, which he believes should be a longer completion time period.
That is, worse players get less play time and get bad ending, while good players play more and get good ending.
It's pretty clear that the author dislikes that proposal, as do I. I doesn't reward skill, it rewards grinding. It's the sloppy solution some games use to claim "replayability." It's one of the reasons I find much of the console RPG genre frustrating.
I agree, this is far less disirable. Just wanted to point out that this option was presented.
I can see the reviews now. "If you really good at this type of game, it's amazing. If you suck, but still enjoy it, you're in for a snorefest." After complaining about games that make you retry 20 times, you're offering less skilled players the exact same option. "Retry the harder, higher risk option until you succeed, or get a worse game. Want to see the best setpieces and setups, you're going to be retrying over, and over, and over.
Low skill players aren't just playing because they want to get to the end. They play for the same reason that more skilled players do: the game is inherently enjoyable. It seems like a bad idea to take the best of a game away from them because they lack the skills. Indeed, those very skills would best be honed by giving them challenging but still enjoyable games that they can finish.
I completely agree with paragraph 2. Especially "...challenging but still enjoyable games THAT THEY CAN FINISH." Emphasis mine, obviously.
I completely disagree with paragraph 1.
I will try and rephrase some key points from my original reply which may not have been clear:
1) It doesn't have to be binary. Its not going to be all hard or all easy. The vast, vast majority of players will land somewhere in between. Meaning that many times they will complete the hard path, and only when they become completely and utterly frustrated will they go for the easier one.
2) Setups should be reserved for the hard route only when an "easy" version of that route is not feasible or breaks the suspension of disbelief in the game. I didn't say ALL the best setups should be reserved for the hard route. In general though, the hardest route should include almost all of the most exciting content. This leaves the player an incentive to at least attempt the hard route.
3) Current games r
Actually I completely disagree.
RPGs can, for the most part, be broken down into many tasks which the player must complete. Some of these tasks may be optional, but in almost all games a certain number of tasks will be required for the player to progress in the game. Even in a MMORPG, you must often complete a certain task to progress further, such as kill a certain monster or open a certain portal in order to move to the next environment.
The author is proposing that each of these tasks should have multiple methods of completion. There might only be two, an "easy" and a "hard", or there might be more. Regardless, his point is that there should be a risk/reward tradeoff that the player must choose. Do they attempt the harder method, which will be quicker and more action packed, but more likely to result in defeat? Or do they attempt an easier path, which takes longer to complete, but is far less likely to result in defeat?
Even in a true open-ended game, one that has no overall goal, there still will be tasks to complete in the game. If developers were to offer risk/reward tradoffs of methods to complete the tasks, games would be more accessible to players who desire less risk, but still exciting for players who like playing a more high-stakes format.
Wow, you completely missed the point of the article. Are you sure you read it?
"He's seriously advocating that it's reasonable that if you fail at a risk in the game, the game should become harder."
He's not advocating that the game becomes harder, quite the opposite, in fact. What he's advocating is that the player should be able to choose between taking more high risk paths, or more low risk ones. High risk paths are more intense, and more difficult, meaning they are more likely to result in a penalty should the player not succeed. But they're shorter, they take less time to complete. Low risk paths are less difficult, so the chance of the player incurring a penalty would be less. However, these low risk paths require the player to play the game for a longer period of time in order to achieve the same result as the high risk path.
"Yes, you only get one path at a time in Ico, you're forced to replay a section until you beat it. Those failed attempts are called 'practice.'"
Your "practice" is my "curse you, lazy game developer". If I am unable to complete a section within about 20 tries, I'm done with a game (less if the section is very long, say more than 15 minutes). If the game developer did not allow for any changes in difficulty settings, or alternate paths, I will simply cease playing the game. Its supposed to be a game, to be FUN. I find about the 20th attempt at something to become a lot more like work than fun. When a video game becomes work, thats when it gets turned off.
You may make a counter arguement that "well, if you give up like that in something like golf or skiing, you'll never get any good". And thats true, but those are things I can do for my entire life, activities which contribute to my well being. I have a much greater incentive to put work into those activities than a video game, which I will play for 20 hours or so and then retire to a shelf, regardless of whether I finish it.
"You'll then have the skilled players (which include many professional reviewers) either blow through it quickly and complain there wasn't much content for their money, or play it slowly and complain it's too easy. Either way you get bad reviews."
The author also posits, in the closing footnotes, that an alternate option is available. From the article: "It has been said to me that it is equally valid to make content the wager and have the worse player complete the game in eight hours, getting the 'bad ending', while the good player gets through all 40 hours and gets the best ending. This is debatable."
"He's still talking about punishing weaker players by costing them time (which is still money)."
Very true, a position which the author does not deny. The author, however, does not see this as a punishment, but rather an option that the player may choose. The point is that current games very often do not offer the player any sort of risk/reward option. The player must simply complete the task in the way that the game developer designed it, or quit. Take the most recent Ninja Gaiden, for instance. The first version, the one not titled "Black", did not have any difficulty settings. The game is linear and requires players to beat bosses in order. Thus a "weak" player will never see all of the games content anyway, having to quit at the point at which they are unable to advance in the game. This is, quite simply, a poor game design from the viewpoint of the author, and I happen to wholeheartedly agree.
I would even go so far as to say that the high risk path should be more exciting, and offer the best content. Players who take high risk paths should be rewarded with more invigorating environments, with more intense and exciting situations. Thus the high risk gamer will see the absolute best the game has to offer, the best setpieces and setups, the most action packed into a smaller time frame. The other, lower risk options may still include some of the same setpieces, but some of the very best ones might be missed when they just don't a
Yes, I'm sure paying less than 1/3 of the cost in salary and benefits isn't whats attacting companies to outsource. Seriously, you actually believe thats not the main factor?
Reductions in litigation and regulations may seem advantageous, however, I tend to disagree somewhat. Who's at more of an advantage, an employee making 50K per year or a corporation pulling down 20+ billion in profits? Large corporations have fleets of well paid lawyers. As for regulations, there's a reason that large corporations pour millions into PACs and other political concerns...
I think work ethic can be debated, most certainly. Are there lazy people? Sure, especially in a good economy, where the pressure to work hard is reduced. But the people at the top of their profession, such as high quality software developers, did not get there by being lazy, believe me.
Taxes are a legitamite concern, yes, but I consider that part of the reduction in payroll required when outsourcing.
All-in-all it comes down to this: There are only so many high quality developers to go around. India may be cranking out mediocre programmers by the barrelfull, but its not increasing the top quality developers at a very much increased rate. You see the same thing in the U.S. There are tons of mediocre programmers coming out of the ITTs and Devrys of the world, heck even quality CS programs produce a number of mediocre developers. A much smaller number of people who can be considered true Software Architects, who continue to develop and broaden their skillset and gain valuable experience in the best practices for building software - those are the valuable people. Even in India, those people don't grow on trees.
PopSci has been throwing out articles regarding this topic for quite a while now, I think they've had at least two major articles on the subject. One of the key innovations is a "highway in the sky" setup for these new small jets which will make it dramatically easier to fly this sort of aircraft. Implied is that qualifications for flying these "air taxies" will be far less restrictive than current commercial aircraft. The result, hopefully, will be more pilot jobs as the industry expands, which would be lower paying jobs than what current pilots make due to less required experience. Both of these are critical, as more pilots would be required to support it and lower pilot salaries for these flights would be required to keep it affordable.
I for one, very much hope this new air taxi industry will get underway as I'm waiting for a flight right now that is delayed 1.5 hours.
Windows was never designed to do the following:
1) Schedule stuff to run at a given time.
2) Priveledge escalation and/or impersonation.
Why do those feel like hacks? They are.
I'm not sure why you think installing software on Windows is painful. I've not run into any application that didn't install via a convenient executable that I simply double clicked.
ACPI has been flaky for a long time. The reason FreeBSD has a workaround to get it to work right and Windows doesn't is that somewhere a FreeBSD user took it upon himself to fix the issue. Unfortunately its not cost effective for Microsoft to go back and make these sort of fixes/repairs for specific platforms or hardware defects.
All that said, when a truly user-friendly distro is available, I'll switch.
I tried a couple of liveCDs recently. Let me give you a scenario: I wanted to use an older TV capture card. Didn't know what the card was. I spent 3 hours trying to find out what card it was and find drivers for it in linux. Windows, after installing the OS, installed the driver for me in seconds. Until I get that sort of performance from linux, I'll just have to stick with Windows.
I have to disagree with this line of thinking, at least at the enterprise level. (In the small software sector, underdesign and overcode may be more often the case.)
Much of the current focus is on attempting to address every conceivable situation and use case scenario up front, then design and execute on a plan to address each and every one. This approach is destined to fail on any sufficiently large product. I believe this is the reason why Extreme Programming made such a splash in the design space when it debuted, as it finally, and I believe correctly, rejected this notion. Unfortunately XP contained numerous other "rules" other than an iterative focus of development, and has as such not gained the mindshare I believe it might have if it had been better conceived.
The fact that XP rejected many other fundamental programming concepts made it unworkable and/or unpalatable for many software designers. Pair programming, far too frequent meetings, and required cross training are completely unworkable in most environments. Most managers will not understand the usefulness of pair programming, even many who are in a corporation devoted solely to software development. I dislike the frequent meeting requirement, as once per day is a significant waste of time. Developers will very often be spending more than one day on a feature and/or mundane code, and this level of review and oversight makes little sense. Required cross training sounds nice on the surface, until one realizes that an expert in a specific area, say regular expressions, or artificial intellegence, or graphics, or whatever it might be; that the expert will spend far more time training a programmer unfamiliar with the specific piece of code than they will actually writing the software. You might say that this is time well spent, but I disagree, as these impromptu sessions delve deeply into specific code and will not cover the core concepts as a whole, nor should they. The result is that the "trainee" most often will not understand the code anyway, and the training session will have served only to waste time and frustrate both the trainer and trainee. Generally, software development is under a deadline and cannot afford to function as a time for in depth training on code specifics.
All this is more of a tangent to my main point, which is that a fundamentally solid design is proper and necessary. However, the continued focus on more and more time spent on rehashing every feature endlessly without putting the product in the hands of its users is wasteful. It is impossible for the end user to fully comprehend how the product will function without using it, and features which they believe to be an absolute requirement for the product are often found to be unwieldly, counterproductive, or entirely useless when the product is completed and delivered. In an iterative environment, various iterations will weed these features out, and result in a better overall product. In addition, developers and testers can NEVER account for every possible scenario end users will create to break the product. Good testing is necessary and important, but I believe it is just as important that the product not be over-tested. Many tested scenarios will never occur in the life use of the product, but nearly infinite untested scenarios will always occur. What if the user opens an email program, while a virus scan is running, and they click a button in the lower left quadrant of the product, which runs code that attempts to use the file system? Sure, this shouldn't break the product, but crazy scenarios often have unexpected consequences which your program may not be equipped to handle. It is far better to deliver the product to the users and let them create the problems for you, elegantly handling exceptions with your program and reporting them to a centralized location, where you can address the most problematic and frequent errors in turn in the next iteration.
In short, continually placing more and more focus at the design time can easily reach a stage where it is counterproductive, and the result is more time and money are spent on a product which ultimately does not deliver the best result for the user base.
The article cites the following risks: disclosure, inference, exposure, loss, guessing, cracking, and snooping, and I'll agree that regular password changes only helps minimize the risk of compromise due to guessing and cracking, and then, only somewhat. But regular password changes can also help to minimize the damage when a password is compromise via other methods.
I have to disagree.
First of all, again: the most common method for password discovery is directly related to the user. If this was the discovery method, our enemy will easily use the same methodology to obtain the password again when it has been changed.
If the password is cracked through guessing, snooping, etc - the problem is that the user is likely to choose a new password which is very close, or just as insecure as their old password. The first thing I would try as a cracker, if someone had a reasonably hard password and changed it, would be to try every variation of the last character. If they had an easy password ("password" or some other dictionary word), I'd just know that I could run a speedy dictionary attack against their password and have it cracked in no time. These two methods of user password changing represent the vast majority - thus forcing a password change has not made the password significantly more secure because the original password was discovered.
I agree with the article, and not the parent post. Constant changing of a frequently used password is a complete failure in the exploration of logic regarding passwords. It is laziness, plain and simple; the reliance on the folklore of old to tell us what we should do. Frequent Password Changing Makes a System More Secure is an old wives tale.
Over time, even a hard password will be memorized by your average user. This password does not somehow become more insecure over time, because, as the article points out, the largest vulnerabilities are not due to the cracking of passwords, but rather human error, ignorance, and/or incompetance. These should decrease with time. The user should become better educated and better able to remember the password, thus less likely to give it out. Only the chance of human error increases slightly (typing password in login box and such). Of the three, this presents the least risk by far of those three, and generally the user is aware of this occurrance and with proper education will know to immediately change their password.
Forcing a user to change password frequently is likely to only cause them to alter one character (likely the last) in the password because committing another secure password to memory is difficult. This causes both usability and security to be comprimised in the same fell swoop. The other option is that they will write the password down or otherwise record it, thus defeating its security. If you've got users with photographic memories who instantly memorize a new hard password every month, you must be the luckiest damn admin in the world.
As the article points out, modern computing and cracking techniques expose vulnerabilities much more quickly, so passwords would have to be changed so frequently as to make a changing password policy useless in many environments anyway.
Caveat:
The opposite is true of Administrator passwords or others which are rarely used. These are generally not committed to memory, and likely documented in some fashion (hopefully they are, or when the admin leaves you're screwed). If they're meant to protect a truly important system, a biometric and/or time sensitive method (such as a synchronized continously changing key generator) should be used in addition to the password. Changing these passwords with some frequency is a good idea, as it forces someone to ensure the validity of the current password (the account is not locked or disabled) as well as provide the aforementioned small measure of protection against cracking.
Please, stop forcing password changes on user accounts. Its a stupid idea. It serves no purpose other than to ensure the latest user password is written down at every desk.
Rant complete.
What you say is true, but there are two fundamental problems:
1) These types of users sometimes attempt to create a fully realized system. Then when it gets beyond 40 users, and it starts tanking (recent real world example), then what happens? Either they're just hosed, or they have to call in the big guns - real Application Developers. We usually find its easier to start from scratch than attempt to work through the code to figure out what exactly it does. I can't tell you how many of these I've seen in a production environment.
2) More importantly, in many cases, management thinks these guys know what they're doing. They manage to create some little access process that stores a few thousand rows of data, with an Access Report frontend, and suddenly these guys are "Programmers". Then they give them an assignment that ramps up beyond a few hundred thousand rows, the "app" blows up in their face, and now there is a great big emergency and my team suddenly gets a priority shift to replace the stupid Access process in an unrealistic amount of time.
Access, excel; they're great as long as you stay under a certain level of complexity. Most users/corporations don't know where that line lies, and when they step over it, the consequences are often disasterous.
How about trying to find drivers for an unknown ATI AGP card? I got an older TV capture card from a friend, and decided I wanted to see if I could turn and older box I had into something I could watch TV on. Maybe I'd do video capture, maybe not.
After about 4 hours trying to find drivers, I gave up. In the Windows world, this is a 5 minute process. Windows autoinstalls prepackaged drivers, I look in the advanced display properties and find what card I have, then I go to the manufacturers website and download the latest driver. If I started with Windows Media Center, I'm watching TV already. If I didn't, it takes another few minutes to download and install a TV watching program.
I'm sure linux is great for Granny who just wants to check email and surf the internet, but until it gives users with good computing familiarity the ability to install a driver for an unknown device in less than 30 minutes, I'm not interested.
Note: Tried this with Knoppix and Gnoppix, as I didn't want to have to do a bunch of command line stuff to install MythTVs "live CD". I have to install a separate server installation that isn't a live CD? Follow some hackneyed installation procedure with a dozen command line options - then I can do a live CD install? All that without knowing if it will actually work. No thanks, I've got better things to do with my time.
Flame on, baby - I've got Karma to burn. You don't like the truth? Start writing drivers.
Couldn't agree more.
I think the Cars trailers stink. However, I've watched the Cars preview material on the Toy Story 10th Anniversary edition - and now I'm a lot more interested in seeing it. I'm actually looking forward to seeing it now, rather than the "hmmm, this looks to suck" attitude that I had when I saw the trailer the first time.
Frankly I've never been bowled over by any Pixar trailer. Perhaps the only one that I really liked was the Incredibles trailer, and that only because I immediately thought: "Whoa, Pixar is making a superhero movie? I have GOT to see that!"
I think part of the problem is getting across the premise. Imagine trying to make the trailer for Finding Nemo... so, its a movie about fish, and they have an adventure. But there is one fish captured and he's in a tank and the other one is swimming through the ocean to find him with another fish who has a memory problem, but you can't give away all the best moments in the movie so you have limited scenes to work with.
Same thing with Cars. This is a movie about Cars, but in this universe there are no people, only cars. And racing is the major sport, and there is a character story (I believe a car trying to make the racing circuit) and other things happen along the way, but we can't use all the best scenes in the movie to make the trailer or give away the entire plot - so we're left with a trailer that makes you go "meh".
I've got a 3 year old son, so I'll probably be watching Cars many times - here's hoping it doesn't suck.
I think the point of the parent post is that the word "widget" has long been used in the software industry as a very generic term for an item, perhaps of software, or perhaps used or tracked by software.
...Rant complete.
Now we're talking about Widgets being something very specific, a "small, componentized peice of code", likely on a web page.
I have to agree with the parent that this is an annoying development. When I say, "we need to develop a generic widget tracker" - to me that means we're going to build a piece of software that tracks widgets - some generic nebulous item of some sort.
Now, what am I talking about? You assume that I'm talking about tracking "small, componentized pieces of code", likely ones which are on the web.
The word thus has two separate, differing definitions in the same occupation sphere.
This is critical to understand. When we say "widget", clearly we don't mean definition #1, because that lies outside of the occupation sphere for almost all software development. So clearly we can safely assume the developer meant definition #2, "an unnamed article considered for purposes of hypothetical example". Now, we have no idea which one was meant, and we have to listen for context to pick up the meaning. This detracts from the likely more important task, which is understanding what the other person is trying to convey.
I refuse to use the term "widget" to refer to these small, componentized pieces of code. Couldn't they be called Web Components? Perhaps we could use a term that actually DESCRIBES what the thing is? I can't tell you how irritating this is to me, that we must make up or shoehorn words for things when a simple english phrase would suffice to describe the concept. Its like all these math nerds and their damnable greek alphabet. Take your greek alphabet and stuff it.
All I can say is I'm going to make sure to catch this ASAP - to try and determine whether I can send it out to family members so they can finally understand what exactly it is that I do every day.
Don't forget the sequel, "Hot Grits", and of course the blockbuster "All Your Base Are Belong To Us".
You have to remember that glasses have existed for well more than a century now. They've become accepted in a culture where they are now commonplace. I think the same will be true of hearing aids eventually, but hopefully in the short term, someone will design a hearing aid that doesn't look like a horrible growth.
I think the biggest thing is not to try to hide them. Stop making them flesh colored! We don't have flesh colored eyeglasses.
Make them look like a cool peice of tech. Make them comfortable to wear and easy to take off + put on.
I think a lot more people would use hearing aids if they were better asthetically designed.
Anyone who's ever attempted photography at night will have learned this simple fact.
You basically have two choices, when presented with super bright object(s), and other much less bright object(s):
1. Expose the bright object(s) perfectly, leaving the other object(s) unseen because they are underexposed.
2. Expose the less bright object(s) perfectly, leaving the very bright object(s) overexposed and thus, completely unintelligible. (A giant bright ugly blob)
Well, I suppose you can also go for some exposure in between, but then you'll just end up with a bad photograph.
So the designers of the spacecraft correctly decided to expose the Earth beautifully, and leave the stars absent because they are underexposed. They're just blue, yellow, red, etc dots anyway - we don't really need to see them since the Earth is the focus of our attention.
Go ahead, take a few photographs of the sky at night. (Warning - do this with a digital camera, you're going to waste a lot of shots) Try taking pictures of the moon. If you get a decent one.. wait, where are the stars?
Leave the exposure on long enough, you'll get the stars. But if you leave the apeture open that long, the moon will just be a tremendous white blob. Same deal with the Earth from space.
As soon as the exclusivity deal was signed, innovation ended. I expect EA to release the exact same game for every year of the contract, with the exception of updated rosters and some new "feature" like the QB vision. Each new feature will be half-assed and poorly implemented.
Football games haven't exactly been known for innovation, but what little did exist is dead now.
The only hope is that the exclusivity contract will cause game developers at other companies to branch out and build truly interesting sports games, ones like Base Wars or Super Baseball Simulator 1.000 perhaps, though obviously football instead of baseball.
Maybe we can get a Blood Bowl game (on a console)?
This proves my hypothesis:
Mac users are completely and totally insane.
Joking aside though, if a sale like this were happening in my area, I would have been there too.
This has always been the Microsoft approach. It goes something like this:
10: Wait until someone comes up with a great idea.
20: If they'll sell out for cheap, buy them.
30: If they won't sell out, build a competing product that is marginally better than what already exists.
40: Put the massive microsoft marketing machine behind the "new" product.
50: Use Operating System monopoly power to push the new product onto everyone (if applicable).
60: If the product is not dominating the marketplace or crushing competitors out of existence, Goto 20.
70: If the product is dominating the marketplace, abandon the product and let it stagnate.
80: Product cycle complete.
Do they try to come up with their own ideas? Oh, sure they do. However, Microsoft is most successful when they take someone else's great idea and build their own version of it.
How far must we go then, to have "security"? Should we all be strip searched before entering an airplane? What about buses and trains? What about public buildings? At some point, you have to trust that the vast majority of people are not terrorists out to get you.
Inmates in prison are very secure.. are they free? What you propose will make us all inmates in our very own police state.
Is it better to live a life of safety, watched by a suspicious government every second of your life? Not allowed to do anything that might be considered remotely dangerous? Or is it better to accept the fact that your chances of dying by terrist attack are far more remote than everyday occurrances like car crashes and heart attacks, even in places like Israel and Iraq where terrorists attack frequently?
Perhaps you should accept that if someone is out to kill you, and is willing to give up their life to do it, that the amount of "security" does not matter. That sacrificing our freedoms will not stop crazy brainwashed knuckleheads, whether they wear turbans or blue jeans.
I say freedom, I say liberty, and I say we let the makers of the PATRIOT act be hung by the undead writers of the Constitution of the United States.
Oh, the writers of the constitution aren't undead? Drat. Well the rest of it still goes.
Don't let your fear of death and outsiders be the undoing of my freedom. Take your "compromises" and "maximised freedom", and move to China. There are no terrorist attacks in China. Because in China, the terrorists have already won.
Please see the ESRB ratings definitions.
First off, the SIMS has a rating of Teen. Not Everyone/Teen. No such rating exists. You can see the gamespot Sims site for confirmation of the rating: Gamespot SIMS info
The SIMS, under normal conditions, does not display nudity. If it did, it would likely have received an M rating, although the inclusion of this one "offensive" item may not have been enough to move it into that category.
The SIMS merely displays naked people when hacked. GTA: SA depicts an actual sex act. This, under the guidelines, clearly would put GTA: SA in the AO category, especially when coupled with the violence already depicted in the game.
The matter is further inflamed by the fact GTA is a game that legislators would just as soon rather had never been created in the first place, already having spawned talk of banning the game due to violence, criminal acts, and general disdain for the law. (though that didn't get far).
I'm sure a similar uproar would have occurred if there were an actual sex act explictly displayed in the SIMS, or if a sex act were "unlockable", even through a hack such as the one in GTA: SA.
I don't necessarily disagree with you that rating of the SIMS, and its sequels and expansion packs might be changed - but it seems unlikely. Even if it did, Walmart and other mainstream stores would still sell the games anyway, as they'd only have M ratings.
- Stores don't enforce ratings, ever.
"Oh you are just so wrong here with this statement. Folks, most stores will not sell a video game unless it is ESRB rated. Those stores that _do_ sell non ESRB rated video games are fly by night storefronts, selling fly by night video games. Every respectable video game company has ESRB ratings as part of their publishing standards."
Sure, stores won't sell games unless they are ESRB rated. But few stores (especially "boutique" types) pay any attention to the rating that is actually on the box. Meaning they are not enforcing the rating.
Whether it has a rating or not means nothing if it isn't being used.
Please read Not So Useful For Me
Mods - Please do not mod this post up. Parent post should be allowed to fade into trolldom.