Any reason you didn't call up former employees A & B after the move and offer them 1.5X once the interview process for replacement employees started in the new location?
I don't see anywhere in the article where they claim that their results are any better than simply asking the player "Was this game fun to play?"
Said question is already asked of focus groups extensively during development of games.
The methodology the article provides isn't going to provide any better feedback to the developers than the way we already do it -- it just lets them put nice graphs and numbers up that tell us what we already know.
Yes, it is interesting to know that the psychological reactions to playing computer games are similar to the psychological reactions from playing real-world sports, but that doesn't give us a better process for making computer games than we have now.
Add to that the fact that often 75-90% of the game development has to be finished before you really have something playable that could be used for this testing. It is only after the majority of the game is done that user feedback actually becomes useful -- before that what you have is a pile of compiling code that only superficially resembles what the final product will be. Come up with a system that we can use on a game design document BEFORE we spend a year programming to the alpha stage of the game and you will have something useful.
Basically, I get the impression that the people behind the study don't really understand how computer games are actually made.
There will ALWAYS be a place for telling a processor exactly what you want it to do, step-by-step.
Yeah, we all thought that processors had finally gotten fast enough that we weren't going to need to write in assembly any more. Then the invention of the GPU pushed that idea out of the forseeable future.
Writing a vertex or pixel shader is functionally working in assembly language. These skills aren't going away any time soon.
When I was in graduate school in Minnesota, I applied for an engineering position in town. When I got called into the interview, the first question out of the interviewers mouth was (in a fine Scottish accent) "So, it says on your resume that you play rugby." We had a nice chat about my playing rugby for the last 6 years, then moved on to talking about the work they did and how I could fit in with their plans.
I am confident that my resume got picked out of the pile to get interviewed because my hobbies made me sound interesting and like a real person instead of a faceless skills list. Having something non-work related to talk about at the beginning of the interview also helped to "break the ice" and made for a far more comfortable interview where I wasn't as nervous as I might have been if we had launched right into the technical talk.
Slashdot Mirror
Any reason you didn't call up former employees A & B after the move and offer them 1.5X once the interview process for replacement employees started in the new location?
I don't see anywhere in the article where they claim that their results are any better than simply asking the player "Was this game fun to play?"
Said question is already asked of focus groups extensively during development of games.
The methodology the article provides isn't going to provide any better feedback to the developers than the way we already do it -- it just lets them put nice graphs and numbers up that tell us what we already know.
Yes, it is interesting to know that the psychological reactions to playing computer games are similar to the psychological reactions from playing real-world sports, but that doesn't give us a better process for making computer games than we have now.
Add to that the fact that often 75-90% of the game development has to be finished before you really have something playable that could be used for this testing. It is only after the majority of the game is done that user feedback actually becomes useful -- before that what you have is a pile of compiling code that only superficially resembles what the final product will be. Come up with a system that we can use on a game design document BEFORE we spend a year programming to the alpha stage of the game and you will have something useful.
Basically, I get the impression that the people behind the study don't really understand how computer games are actually made.
There will ALWAYS be a place for telling a processor exactly what you want it to do, step-by-step. Yeah, we all thought that processors had finally gotten fast enough that we weren't going to need to write in assembly any more. Then the invention of the GPU pushed that idea out of the forseeable future. Writing a vertex or pixel shader is functionally working in assembly language. These skills aren't going away any time soon.
When I was in graduate school in Minnesota, I applied for an engineering position in town. When I got called into the interview, the first question out of the interviewers mouth was (in a fine Scottish accent) "So, it says on your resume that you play rugby." We had a nice chat about my playing rugby for the last 6 years, then moved on to talking about the work they did and how I could fit in with their plans. I am confident that my resume got picked out of the pile to get interviewed because my hobbies made me sound interesting and like a real person instead of a faceless skills list. Having something non-work related to talk about at the beginning of the interview also helped to "break the ice" and made for a far more comfortable interview where I wasn't as nervous as I might have been if we had launched right into the technical talk.
"I don't know about anyone else, but I'd rather have a guy with a trojan break into my computer than a guy with a gun in my house."
Its when the guy with the trojan breaks into my house that I start to get really worried....