How do you control the ratios? Do you prevent good players from being able to do damage to anyone who isn't an evil character? And do you prevent good characters from harming buildings and non-evil NPCs? What's the method for getting to be evil? Some sort of lottery system? This would encourage people to keep recycling characters until they can get an evil character. Or perhaps 2 out of 5 of your characters can be evil, but that doesn't mean you'll ever play the good characters.
Are there paths you can choose that would allow your character to turn evil, or even be redeemed? Now that's where it gets interesting. If you could actually go and develop your character in a non-stat based way, then you might be able to encourage actual Role Playing.
Anyways, I'm not trying to say it's not a good idea, but it's not a simple design element. I've worked on the design for many Multiplayer and Massively Multiplayer Online Games, and it's always the details that get you when you try these things. I encourage you to work out a full design sometime, then try to do your best to pretend that you are a player main goal is to make gameplay for everyone else miserable. If you can't think of any way, then have some of your friends help. Then, when you've modified the design, do it again.
This is obvious, but the lock isn't unpickable, it's just going to take a while before people figure out how to pick it, and it'll raise the bar on tools needed for picking at most.
Also, while this will be handy for places with cement walls and thick steel doors, places with windows and weak door frames will still be vulnerable. Plus, of course, the social engineering attacks.
That being said, I'm a big fan of new, shiny locks, so hooray for the people who made it.
I wouldn't say they're missing out, per se, because I'm positive that the considered it. it's just a difficult thing to design in. The tricky thing is having servers that aren't simply overrun by villains, with not enough heroes to stop them. If you think regular PvP combat is bad, imagine if you were trying to build your rep as the next Joker.
That's not true from a scientific standpoint. You can't measure an emotion, therefore you have to be able to define it in measurable terms. Generally, stress is measured by blood pressure, heart rate, dialation of the pupils, and a few other measures, depending on what equipment you have available, what your budget is, and how amenable your subjects are to being hooked up to machines.
In clinical psychology, and to the lay-person, yes, stress is an emotion. However, to the research psychologist, one simply can't get away with that soft of a definition.
The only way a computer could cause stress is if it emits a signal or a wave of some kind which stimulates a stressful reaction in people.
There, you've just generated a hypothesis that supports the theory that technology causes stress. It is not, incidentally, the only way, but it's the first way that comes to mind. If you found a correlation between technology and stress, then you would likely want to see if you could construct an experiment to determine if the stress were cause electromagnetically. That's how the research works. You do one step, then the next. You don't simply dismiss the hypothesis because you don't feel it's true. Unless you control the budget, in which case that's perfectly within your rights.
There are myriad environmental, social, cultural, societal and psychological factors that are involved with the question.
Yes, yes there are. That does not mean that correlation cannot be drawn, if the data supports the conclusion. I'm not saying that technology does or does not cause stress, but I am saying that it's something that can be measured and analyzed. The question can be answered, even if the answer is "there is no correlation between technology and stress," as your hypothesis states.
The poster does not seem ready to consider these factors; he simply wants a yes or no answer to make a theory fit a result.
Agreed, and I believe I mentioned in my post that I didn't believe that what the poster was doing would have to do more in order to make the research valid.
Pseudointellectualism may impress your friends, but it doesn't hold water with critical thinkers and people who actually value solid reasoning.
No, what I was outlining what the scientific process. You may have heard of it. What you are attempting to do is draw conclusions without doing any research at all, which is very similar to pseudointellectualism, when you think about it.
You cannot rightfully make a broad, sweeping generalization about stress and computers because of the limitless range of their uses and functions. For most Slashdotters and geeks, computers are a hobby and a way to relieve stress. For secretaries, journalists and others who depend on computers solely for work, computers can be a source of horrible stress.
Actually, you can rightfully make a broad, sweeping generalization about stress and computers...if you research the subject and find that there is correlation. That's the point of social sciences, to determine if there are correlations. If you continue your research and use properly controlled experiments with appropriate statistical analysis, you could even determine causality. It's true that correlation does not imply causation, but that doesn't mean that causation can't be proven.
You say that computers do not cause stress, but that is merely a hypothesis. There are many ways, both obvious and non-, that technology could contribute to stress. Computers emit all manner of EM fields, radiation, and strange sounds on a variety of frequencies, not all of which are intended. Any one of those could interact with the human body to physically cause stress. Or there could be a correlation between multitasking and stress, when multitasking is almost impossible to avoid with modern computer systems.
That being said, if the topic poster is considering this thread to be the sum total of research into the paper, well, it's not going to have much validity. I hope UCLA encourages a bit more work on this sort of thing.
Which reminds me, the whole "unnamed X" with the URL of the X included in a link is really, really dumb. I've seen it at least twice in as many days, and I hope it's a trend that dies out immediately. Just say you're going to UCLA and stop trying to make yourself look clever. There's no reason not to say which X you're talking about, and if you're doing a bare minimum of hiding the info, you look about as smart as Napster did when they attempted the whole "No, we don't encourage illegal file swapping at all (tee hee!)" thing in court.
I'm probably going to make a lot of these on this thread, but...
You cannot say that a more thorough investigation would lead to the conclusion that bad technology is correlated to stress. Well, you can say it, but that proves nothing. The whole point behind doing a study is that you find out whether there is a correlation or not. You may find that blood pressure raises in proportion to the number of active electrical fields in your immediate vicinity. You may discover that the refresh rate of monitors causes the heart to beat faster. You may learn that the sound of a processor, barely audible through the speaker, resonates with the human central nervous system to generally freak you out. I don't know, and you don't know, until you actually do a study.
Your hypothesis isn't a bad one, but it needs to be backed up with data before you can proclaim it as fact. Or at least as factual as any scientific observation.
The items up for sale include lots of those dumb Herman Miller Aeron chairs that were so popular
Very clever, trying to convince everyone not to bid on the Aeron chairs in order to keep the costs down.
=Brian
Re:Mini Ipod Review on WinXP
on
iPod Mini Ships
·
· Score: 1
The mini's also have (finally) a star rating system, so you can rate your songs as you are listening to them.
What do you mean, "finally"? The ipods have had star rating systems on them at least since 2.0, and the minis just came out, so you couldn't have been waiting for star ratings on the minis any longer than you would have been waiting for the mini itself.
Kesmai. Ah, yes, the heady days of Massively Multiplayer Online Gaming, before UO. Air Warrior, Battletech, Legends of Kesmai: gone. Mythic Studio's testing ground, so they could finally launch a game that doesn't crash repeatedly*: gone. Hundreds of jobs in Charlottesville, VA: gone.
=Brian
* - Mythic released several MMOGs before Dark Ages of Camelot. While DAoC had the most impressive launch of any MMORPG in recent years, their earlier attempts were much rockier. Good to see that they're doing well, though.
Well, I have worked for EA. They bought out the company I worked for, then put us out of business. And that was because they liked what we were doing. Imagine what they'd do if they didn't like us.
It's not necessary to have 90% market share in order to dominate the industry. No, they can't buy out Microsoft, but they can cause problems for the small developer.
There's another class of people who don't understand interactive storytelling ready to add the cacophony of "This is the way we want it done, oh and it better work as a game."
Just when developers finally start to get the hang of the movie translation, and just a producers learn how to deal with marketing and management and publishers and every idiot who thinks that they know how to make a game, and it's pretty much the same thing as writing their high-school english essays but easier, since it's a game, and how hard can that be, there's a brand new class of people who come along. Not only that, a brand new class of really pushy people. Oh, hooray.
On a slightly less sarcastic note, yes, there have been many, many bad video games featuring actors, and some of those very good actors, and perhaps this will help out. At least to have someone say, "Wow, these lines are really cheesy. Who wrote this, the programmers?" (Cause, you know, sometimes programmers like to help out on the dialogue, too.) But I can't help but feel impending doom for at least 5 years of this actor/agent-as-game-designer thing starts gaining momentum.
Altogether, Ruby just seems like an odd choice when it comes to really caring about teaching people to program. Not a bad choice, but not clearly better than the more obvious choices either.
The one advantage that Ruby has over Smalltalk and Logo is that it's included with every copy of OS X. So is Perl, but please, please, please nobody teach children to program using Perl. It could doom us all!
Python is included with OS X as well, so that would be a fine alternative. Me, I like Ruby. Just because.
One of the prolems with this idea is that, in a game, it just doesn't matter. Your economic theory will work different in a situation where being broke means that you just can't afford the new cool thing vs. being broke means you will die. And if death were permanent in an MMOG, then people wouldn't play it.
I sent a response to the Author and the Editors of wired.com. Hopefully it'll show up in the rants tomorrow, but...
------ "The process starts when a producer conceives of a project and then goes through an internal sales process that can include being wildly optimistic about budgets and schedules, [Gifford] Calenda said."
This is an interesting view, and yes, it certainly happens from time to time. However, as a former producer myself, I often find that I will present a reasonably budget, schedule, and feature list, only to see upper management tell me that the feature list is perfect, the budget is far too high, and the game needs to be done in half the time.
Producers usually don't want their games to fail. There's very rarely an incentive on the producer's side to cut the development time, unless the producer is bad at making schedules (not uncommon) or the game is tied to a particular release date. However, most games being released are not tied to a release date such as a movie or sporting event.
Upper management, or the publisher, if you're an independent developer, is significantly more likely to have a reason to cut the time and budget. Usually it's a) so the game doesn't cost as much; and b) so it gets out sooner, therefore generating sales revenue in a particular fiscal year. You can see why there will be pressure from management to either present a schedule that is unrealistic, or to cut a realistic schedule away from reality. Naturally, additional budget money is hard to get, and features could never be dropped, and those are really the only other ways of cutting the development time.
I will grant you that, to a point, reducing development time and slashing budgets is a perfectly acceptable way to behave. It would be poor management that simply accepted a producer's word at every turn, because then the producers might take advantage of the unwary eye of management. However, management needs to listen to the producers if they tell them that a particular project is 'unlikely' or 'impossible'. If the people in charge of making decisions tell the project team to go ahead with the hobbled schedule and budget, then the project will likely slip.
The worst part is when the development team has to take shortcuts to get the project out on time which result in more QA time at the end of the project. The ironic part is when the projects slips to meet the original schedule, but you had to do it the hard way, with lots of bug fixing and messy code.
I hope this is a trend that goes away sometime soon in game development. The three worst habits in the Game Industry are poor scheduling, mandatory overtime, and laying off the project team or studio when the game is finished, and usually those three go hand-in-hand. It's a shame when the producers are solely blamed for the process, when it is terribly unlikely that they are the primary cause. ------
Actually, this article has all sorts of other games written all over it, but you can't read it because you didn't work for the author when he was EA Management.
It might be interesting to embed these into the top of a sidewalk, then watch the sidewalk start glowing whenever someone walks on it, or whenever there are other vibrations in the area. Not necessarily useful, but interesting.
I played Dactyl Nightmare once when it was on tour and made it to my University. Usually people focused on the other player and did their best to avoid the Teradactyl. When I finally got my turn, I was unstoppable. The other opponent was easily dispatched time and again, but once the 'dactyl went for me. I said, "What the heck," and shot the thing out of the sky. It was reminiscent of that scene from the first Burton Batman film. Ah, good times.
You wanna know how they pick the specs for UT2003/4? They get a whole buttload of systems, and they run benchmarks on them (probably several times). The systems that average 20fps are deemed "minimum spec", and the ones that hit 40 are "reccomended". Its that simple. They don't pick them out of a hat, nVidia doesn't hand them to Epic, and marketing doesn't have any fucking input.
This may be true for UT, and it may not. I don't know, because I have nothing to do with the product. However, I can tell you that from other places in the game industry, including, sometimes, Electronic Arts, this is not the process.
More often, specs are created before the game are, especially on works for hire. "What are our minimum system specs for the game?" the developer will ask the publisher, and the publisher will respond with something like a 33 MHz 486, because that will sell on the most systems. Then there'll be some arguing back and forth to get the specs up to something reasonable, and it may even be put into the contract what the minimum specs are. Why? Because you don't want to pay a developer for a final game if it won't play on anything but the highest-end machine unless it's a guaranteed bestseller in any case.
Mind you, most likely it won't be put into the contract itself, but rather be part of a verbal agreement or a document specified by the contract.
In any case, the developers will make the game, it won't run on the minimum sys reqs, and there'll have to be some optimization. Sometimes you'll have to bring in another developer to optimize the code, but that doesn't happen very often.
So, as I said, your statement may be true for UT2004, but I can't verify that. In the rest of the gaming industry, there are many ways of detemining min sys reqs, especially on works for hire, and yes, Marketing does play a role in it often. They are commonly picked out of a hat. Usually the video card manufacturers don't dictate the requirements, but I could see situations where they might, depending on the relationship between the publisher and the video card manufacturer. Seems unlikely, though.
In case you're wondering how I know, it's because I've published 6 or 7 games and I've worked directly or indirectly for EA, Kesmai, Atari, Mattel, and Disney, in both the Developer role and the Publisher role over the course of a decade. And obviously games that aren't works for hire will likely go through a different process to determine the min sys reqs.
Nor are Producers, Artists, or anyone else involved in the creation of a video game, except by complete coincidence.
The reason they put the labels on the games is as a fail safe, not because of any knowledge about their game's potential for inducing seizures. Because this is a lawsuit-happy society we live in, they figure it's easiest to put labels on everything.
I'm sure that in 20 years time there'll be big disclaimers before every television show saying that there may be a risk to viewers of seizures, just to prevent lawsuits.
My advice is to presume that video games are going to cause seizures, whether there's a label or not. Game creators have no way of preventing them at this point, so unless one comes out with a label that says that it doesn't cause seizures, I think it's best to avoid the lot of them.
Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. and Mac OS X Panther lets you script with your choice of languages: Perl, PHP, Python, Rexx, Scheme, Tcl and more.
See, you're missing the point. Despite the name, Apple doesn't really consider AppleScript to be a Scripting Language, per se. They consider it to be a root language. Check out the AppleScript Developer Page. To quote, "A peer to the Aqua GUI, AppleScript is the language interface for Mac OS X." There's even a handy little chart that shows AppleScript and Aqua at the top, with Cocoa, Java, Carbon, and Classic underneath, etc.
To Apple, AppleScript is no longer a scripting language so much as it is the underpinnings of the Operating System. It's a different way to communicate with Applications, rather than just through the Aqua interface.
The Athenians knew how to just fix it. Once a year they'd hold an election; the person getting the most votes -- ostrakons, for the shell or potshard used in voting -- would be ostracized, banished, for a year.
All right, so I used to work for Kesmai, who the people who are in the know realize that means that I have some idea what I'm talking about when it comes to multiplayer online gaming and customer support.
While your solution sounds hopeful at first, you really have to stop and think about the consequences of the solution in other terms, rather that just the problem at hand. See, you're trying to keep bad players out by making a system that allows for players to rid the system of other players.
Now, do you have some magic way of ensuring that the troublemaking players don't get to vote? Because here's pretty much what would happen: The troublemaking players would gang up and start a concerted effort to ban proper players. If the troublemakers could get a good head start, then they would quickly be able to outnumber the proper players.
The quick rule of thumb is to imagine that you want to make life miserable for other players. Then ask yourself how you can abuse the tools in the game. Presume you can find 30 other players who also want to abuse the system, 'cause you will be able to.
Automatic, player-controlled community tools are a nice idea, but you have to make sure that those tools can't be used to affect a player's experience.
Okay, so most of the article consists of, "Here's software X. They re-wrote it, and now it's not as good or as accepted. Why'd they do that? They suck."
Software is re-written for many reasons. Sometimes it's ego, sometimes it's for fun, but usually it's because you take a look at the existing codebase and what you want to do with it in the future, and you decide that it's going to cost a lot less to implement the future features by re-writing and fixing the new bugs than to work around the existing architecture.
I've had to make the re-write or extend decision more than once, and it's rarely a simple decision.
What I would have preferred from this article is some interviews with the people responsible for the decision to re-write, and what their thinking was, as well as whether they still agree with that decision or would have done something differently now.
I guess the big flaw in this is that no other member of the company is compensated the same way, while arguably an engineer has the same influence over the success or failure of the company, at least on a small scale. If it works for the executive, why not the front-line worker?
It's called stock options. Their purpose is to get workers to do a better job so that the company's stock will increase rather than decrease, thus making their stock options worthwhile instead of worthless.
Back in my game programming days, we had the old Sega Saturn running, and we'd play some Daytona. The only thing I remember from that thing is...well, I think Penny Arcade said it best.
It could be. The hope is that he was going for using the shock value of the article to make some sort of point about video games, to which I am hopefully letting him know that he failed. The worry with sending a letter to the editor is that the editor probably knew what sort of response such an article would get and green-lighted it anyways in hopes of more traffic/higher sales. That's why I chose that route. Hopefully others wrote the editor.
Slashdot Mirror
How do you control the ratios? Do you prevent good players from being able to do damage to anyone who isn't an evil character? And do you prevent good characters from harming buildings and non-evil NPCs? What's the method for getting to be evil? Some sort of lottery system? This would encourage people to keep recycling characters until they can get an evil character. Or perhaps 2 out of 5 of your characters can be evil, but that doesn't mean you'll ever play the good characters.
Are there paths you can choose that would allow your character to turn evil, or even be redeemed? Now that's where it gets interesting. If you could actually go and develop your character in a non-stat based way, then you might be able to encourage actual Role Playing.
Anyways, I'm not trying to say it's not a good idea, but it's not a simple design element. I've worked on the design for many Multiplayer and Massively Multiplayer Online Games, and it's always the details that get you when you try these things. I encourage you to work out a full design sometime, then try to do your best to pretend that you are a player main goal is to make gameplay for everyone else miserable. If you can't think of any way, then have some of your friends help. Then, when you've modified the design, do it again.
=Brian
This is obvious, but the lock isn't unpickable, it's just going to take a while before people figure out how to pick it, and it'll raise the bar on tools needed for picking at most.
Also, while this will be handy for places with cement walls and thick steel doors, places with windows and weak door frames will still be vulnerable. Plus, of course, the social engineering attacks.
That being said, I'm a big fan of new, shiny locks, so hooray for the people who made it.
=Brian
I wouldn't say they're missing out, per se, because I'm positive that the considered it. it's just a difficult thing to design in. The tricky thing is having servers that aren't simply overrun by villains, with not enough heroes to stop them. If you think regular PvP combat is bad, imagine if you were trying to build your rep as the next Joker.
=Brian
Stress is a human condition, an emotion.
That's not true from a scientific standpoint. You can't measure an emotion, therefore you have to be able to define it in measurable terms. Generally, stress is measured by blood pressure, heart rate, dialation of the pupils, and a few other measures, depending on what equipment you have available, what your budget is, and how amenable your subjects are to being hooked up to machines.
In clinical psychology, and to the lay-person, yes, stress is an emotion. However, to the research psychologist, one simply can't get away with that soft of a definition.
The only way a computer could cause stress is if it emits a signal or a wave of some kind which stimulates a stressful reaction in people.
There, you've just generated a hypothesis that supports the theory that technology causes stress. It is not, incidentally, the only way, but it's the first way that comes to mind. If you found a correlation between technology and stress, then you would likely want to see if you could construct an experiment to determine if the stress were cause electromagnetically. That's how the research works. You do one step, then the next. You don't simply dismiss the hypothesis because you don't feel it's true. Unless you control the budget, in which case that's perfectly within your rights.
There are myriad environmental, social, cultural, societal and psychological factors that are involved with the question.
Yes, yes there are. That does not mean that correlation cannot be drawn, if the data supports the conclusion. I'm not saying that technology does or does not cause stress, but I am saying that it's something that can be measured and analyzed. The question can be answered, even if the answer is "there is no correlation between technology and stress," as your hypothesis states.
The poster does not seem ready to consider these factors; he simply wants a yes or no answer to make a theory fit a result.
Agreed, and I believe I mentioned in my post that I didn't believe that what the poster was doing would have to do more in order to make the research valid.
Pseudointellectualism may impress your friends, but it doesn't hold water with critical thinkers and people who actually value solid reasoning.
No, what I was outlining what the scientific process. You may have heard of it. What you are attempting to do is draw conclusions without doing any research at all, which is very similar to pseudointellectualism, when you think about it.
=Brian
You cannot rightfully make a broad, sweeping generalization about stress and computers because of the limitless range of their uses and functions. For most Slashdotters and geeks, computers are a hobby and a way to relieve stress. For secretaries, journalists and others who depend on computers solely for work, computers can be a source of horrible stress.
Actually, you can rightfully make a broad, sweeping generalization about stress and computers...if you research the subject and find that there is correlation. That's the point of social sciences, to determine if there are correlations. If you continue your research and use properly controlled experiments with appropriate statistical analysis, you could even determine causality. It's true that correlation does not imply causation, but that doesn't mean that causation can't be proven.
You say that computers do not cause stress, but that is merely a hypothesis. There are many ways, both obvious and non-, that technology could contribute to stress. Computers emit all manner of EM fields, radiation, and strange sounds on a variety of frequencies, not all of which are intended. Any one of those could interact with the human body to physically cause stress. Or there could be a correlation between multitasking and stress, when multitasking is almost impossible to avoid with modern computer systems.
That being said, if the topic poster is considering this thread to be the sum total of research into the paper, well, it's not going to have much validity. I hope UCLA encourages a bit more work on this sort of thing.
Which reminds me, the whole "unnamed X" with the URL of the X included in a link is really, really dumb. I've seen it at least twice in as many days, and I hope it's a trend that dies out immediately. Just say you're going to UCLA and stop trying to make yourself look clever. There's no reason not to say which X you're talking about, and if you're doing a bare minimum of hiding the info, you look about as smart as Napster did when they attempted the whole "No, we don't encourage illegal file swapping at all (tee hee!)" thing in court.
=Brian
I'm probably going to make a lot of these on this thread, but...
You cannot say that a more thorough investigation would lead to the conclusion that bad technology is correlated to stress. Well, you can say it, but that proves nothing. The whole point behind doing a study is that you find out whether there is a correlation or not. You may find that blood pressure raises in proportion to the number of active electrical fields in your immediate vicinity. You may discover that the refresh rate of monitors causes the heart to beat faster. You may learn that the sound of a processor, barely audible through the speaker, resonates with the human central nervous system to generally freak you out. I don't know, and you don't know, until you actually do a study.
Your hypothesis isn't a bad one, but it needs to be backed up with data before you can proclaim it as fact. Or at least as factual as any scientific observation.
=Brian
The items up for sale include lots of those dumb Herman Miller Aeron chairs that were so popular
Very clever, trying to convince everyone not to bid on the Aeron chairs in order to keep the costs down.
=Brian
The mini's also have (finally) a star rating system, so you can rate your songs as you are listening to them.
What do you mean, "finally"? The ipods have had star rating systems on them at least since 2.0, and the minis just came out, so you couldn't have been waiting for star ratings on the minis any longer than you would have been waiting for the mini itself.
=Brian
Kesmai. Ah, yes, the heady days of Massively Multiplayer Online Gaming, before UO. Air Warrior, Battletech, Legends of Kesmai: gone. Mythic Studio's testing ground, so they could finally launch a game that doesn't crash repeatedly*: gone. Hundreds of jobs in Charlottesville, VA: gone.
=Brian
* - Mythic released several MMOGs before Dark Ages of Camelot. While DAoC had the most impressive launch of any MMORPG in recent years, their earlier attempts were much rockier. Good to see that they're doing well, though.
Well, I have worked for EA. They bought out the company I worked for, then put us out of business. And that was because they liked what we were doing. Imagine what they'd do if they didn't like us.
It's not necessary to have 90% market share in order to dominate the industry. No, they can't buy out Microsoft, but they can cause problems for the small developer.
=Brian
There's another class of people who don't understand interactive storytelling ready to add the cacophony of "This is the way we want it done, oh and it better work as a game."
Just when developers finally start to get the hang of the movie translation, and just a producers learn how to deal with marketing and management and publishers and every idiot who thinks that they know how to make a game, and it's pretty much the same thing as writing their high-school english essays but easier, since it's a game, and how hard can that be, there's a brand new class of people who come along. Not only that, a brand new class of really pushy people. Oh, hooray.
On a slightly less sarcastic note, yes, there have been many, many bad video games featuring actors, and some of those very good actors, and perhaps this will help out. At least to have someone say, "Wow, these lines are really cheesy. Who wrote this, the programmers?" (Cause, you know, sometimes programmers like to help out on the dialogue, too.) But I can't help but feel impending doom for at least 5 years of this actor/agent-as-game-designer thing starts gaining momentum.
=Brian
Altogether, Ruby just seems like an odd choice when it comes to really caring about teaching people to program. Not a bad choice, but not clearly better than the more obvious choices either.
The one advantage that Ruby has over Smalltalk and Logo is that it's included with every copy of OS X. So is Perl, but please, please, please nobody teach children to program using Perl. It could doom us all!
Python is included with OS X as well, so that would be a fine alternative. Me, I like Ruby. Just because.
=Brian
One of the prolems with this idea is that, in a game, it just doesn't matter. Your economic theory will work different in a situation where being broke means that you just can't afford the new cool thing vs. being broke means you will die. And if death were permanent in an MMOG, then people wouldn't play it.
=Brian
I sent a response to the Author and the Editors of wired.com. Hopefully it'll show up in the rants tomorrow, but...
------
"The process starts when a producer conceives of a project and then goes through an internal sales process that can include being wildly optimistic about budgets and schedules, [Gifford] Calenda said."
This is an interesting view, and yes, it certainly happens from time to time. However, as a former producer myself, I often find that I will present a reasonably budget, schedule, and feature list, only to see upper management tell me that the feature list is perfect, the budget is far too high, and the game needs to be done in half the time.
Producers usually don't want their games to fail. There's very rarely an incentive on the producer's side to cut the development time, unless the producer is bad at making schedules (not uncommon) or the game is tied to a particular release date. However, most games being released are not tied to a release date such as a movie or sporting event.
Upper management, or the publisher, if you're an independent developer, is significantly more likely to have a reason to cut the time and budget. Usually it's a) so the game doesn't cost as much; and b) so it gets out sooner, therefore generating sales revenue in a particular fiscal year. You can see why there will be pressure from management to either present a schedule that is unrealistic, or to cut a realistic schedule away from reality. Naturally, additional budget money is hard to get, and features could never be dropped, and those are really the only other ways of cutting the development time.
I will grant you that, to a point, reducing development time and slashing budgets is a perfectly acceptable way to behave. It would be poor management that simply accepted a producer's word at every turn, because then the producers might take advantage of the unwary eye of management. However, management needs to listen to the producers if they tell them that a particular project is 'unlikely' or 'impossible'. If the people in charge of making decisions tell the project team to go ahead with the hobbled schedule and budget, then the project will likely slip.
The worst part is when the development team has to take shortcuts to get the project out on time which result in more QA time at the end of the project. The ironic part is when the projects slips to meet the original schedule, but you had to do it the hard way, with lots of bug fixing and messy code.
I hope this is a trend that goes away sometime soon in game development. The three worst habits in the Game Industry are poor scheduling, mandatory overtime, and laying off the project team or studio when the game is finished, and usually those three go hand-in-hand. It's a shame when the producers are solely blamed for the process, when it is terribly unlikely that they are the primary cause.
------
=Brian
Actually, this article has all sorts of other games written all over it, but you can't read it because you didn't work for the author when he was EA Management.
=Brian
It might be interesting to embed these into the top of a sidewalk, then watch the sidewalk start glowing whenever someone walks on it, or whenever there are other vibrations in the area. Not necessarily useful, but interesting.
=Brian
I played Dactyl Nightmare once when it was on tour and made it to my University. Usually people focused on the other player and did their best to avoid the Teradactyl. When I finally got my turn, I was unstoppable. The other opponent was easily dispatched time and again, but once the 'dactyl went for me. I said, "What the heck," and shot the thing out of the sky. It was reminiscent of that scene from the first Burton Batman film. Ah, good times.
=Brian
Goddamn there are a lot of BS'ers on /.
Well, true in and of itself...
You wanna know how they pick the specs for UT2003/4? They get a whole buttload of systems, and they run benchmarks on them (probably several times). The systems that average 20fps are deemed "minimum spec", and the ones that hit 40 are "reccomended". Its that simple. They don't pick them out of a hat, nVidia doesn't hand them to Epic, and marketing doesn't have any fucking input.
This may be true for UT, and it may not. I don't know, because I have nothing to do with the product. However, I can tell you that from other places in the game industry, including, sometimes, Electronic Arts, this is not the process.
More often, specs are created before the game are, especially on works for hire. "What are our minimum system specs for the game?" the developer will ask the publisher, and the publisher will respond with something like a 33 MHz 486, because that will sell on the most systems. Then there'll be some arguing back and forth to get the specs up to something reasonable, and it may even be put into the contract what the minimum specs are. Why? Because you don't want to pay a developer for a final game if it won't play on anything but the highest-end machine unless it's a guaranteed bestseller in any case.
Mind you, most likely it won't be put into the contract itself, but rather be part of a verbal agreement or a document specified by the contract.
In any case, the developers will make the game, it won't run on the minimum sys reqs, and there'll have to be some optimization. Sometimes you'll have to bring in another developer to optimize the code, but that doesn't happen very often.
So, as I said, your statement may be true for UT2004, but I can't verify that. In the rest of the gaming industry, there are many ways of detemining min sys reqs, especially on works for hire, and yes, Marketing does play a role in it often. They are commonly picked out of a hat. Usually the video card manufacturers don't dictate the requirements, but I could see situations where they might, depending on the relationship between the publisher and the video card manufacturer. Seems unlikely, though.
In case you're wondering how I know, it's because I've published 6 or 7 games and I've worked directly or indirectly for EA, Kesmai, Atari, Mattel, and Disney, in both the Developer role and the Publisher role over the course of a decade. And obviously games that aren't works for hire will likely go through a different process to determine the min sys reqs.
=Brian
Nor are Producers, Artists, or anyone else involved in the creation of a video game, except by complete coincidence.
The reason they put the labels on the games is as a fail safe, not because of any knowledge about their game's potential for inducing seizures. Because this is a lawsuit-happy society we live in, they figure it's easiest to put labels on everything.
I'm sure that in 20 years time there'll be big disclaimers before every television show saying that there may be a risk to viewers of seizures, just to prevent lawsuits.
My advice is to presume that video games are going to cause seizures, whether there's a label or not. Game creators have no way of preventing them at this point, so unless one comes out with a label that says that it doesn't cause seizures, I think it's best to avoid the lot of them.
=Brian
Even Apple don't mention AppleScript, I think they realise that the UNIX utils/languages have suceeded it. and Mac OS X Panther lets you script with your choice of languages: Perl, PHP, Python, Rexx, Scheme, Tcl and more.
See, you're missing the point. Despite the name, Apple doesn't really consider AppleScript to be a Scripting Language, per se. They consider it to be a root language. Check out the AppleScript Developer Page. To quote, "A peer to the Aqua GUI, AppleScript is the language interface for Mac OS X." There's even a handy little chart that shows AppleScript and Aqua at the top, with Cocoa, Java, Carbon, and Classic underneath, etc.
To Apple, AppleScript is no longer a scripting language so much as it is the underpinnings of the Operating System. It's a different way to communicate with Applications, rather than just through the Aqua interface.
=Brian
The Athenians knew how to just fix it. Once a year they'd hold an election; the person getting the most votes -- ostrakons, for the shell or potshard used in voting -- would be ostracized, banished, for a year.
All right, so I used to work for Kesmai, who the people who are in the know realize that means that I have some idea what I'm talking about when it comes to multiplayer online gaming and customer support.
While your solution sounds hopeful at first, you really have to stop and think about the consequences of the solution in other terms, rather that just the problem at hand. See, you're trying to keep bad players out by making a system that allows for players to rid the system of other players.
Now, do you have some magic way of ensuring that the troublemaking players don't get to vote? Because here's pretty much what would happen: The troublemaking players would gang up and start a concerted effort to ban proper players. If the troublemakers could get a good head start, then they would quickly be able to outnumber the proper players.
The quick rule of thumb is to imagine that you want to make life miserable for other players. Then ask yourself how you can abuse the tools in the game. Presume you can find 30 other players who also want to abuse the system, 'cause you will be able to.
Automatic, player-controlled community tools are a nice idea, but you have to make sure that those tools can't be used to affect a player's experience.
=Brian
Okay, so most of the article consists of, "Here's software X. They re-wrote it, and now it's not as good or as accepted. Why'd they do that? They suck."
Software is re-written for many reasons. Sometimes it's ego, sometimes it's for fun, but usually it's because you take a look at the existing codebase and what you want to do with it in the future, and you decide that it's going to cost a lot less to implement the future features by re-writing and fixing the new bugs than to work around the existing architecture.
I've had to make the re-write or extend decision more than once, and it's rarely a simple decision.
What I would have preferred from this article is some interviews with the people responsible for the decision to re-write, and what their thinking was, as well as whether they still agree with that decision or would have done something differently now.
=Brian
It's called stock options. Their purpose is to get workers to do a better job so that the company's stock will increase rather than decrease, thus making their stock options worthwhile instead of worthless.
=Brian
Back in my game programming days, we had the old Sega Saturn running, and we'd play some Daytona. The only thing I remember from that thing is...well, I think Penny Arcade said it best.
=Brian
It could be. The hope is that he was going for using the shock value of the article to make some sort of point about video games, to which I am hopefully letting him know that he failed. The worry with sending a letter to the editor is that the editor probably knew what sort of response such an article would get and green-lighted it anyways in hopes of more traffic/higher sales. That's why I chose that route. Hopefully others wrote the editor.
=Brian