The seemingly innocuous appliances — all 224 million of them across the nation — together consume as much electricity as produced by four giant nuclear reactors, running around the clock.
But how much power is that in libraries of congress?
I feel like the requirements for the Turing test have been consistently lowered over the years to match what would be considered realistic to achieve rather than, as Alan Turing seemed to believe, demonstrate that a computer can be said to actually be "thinking."
The average user doesn't know not to click pop-up ads for fake antivirus. That's why so many people feel comfortable with an "app store" experience like that of iOS or the game consoles, because it protects the average user from himself.
It's not relevant that those users are ignorant or don't make any effort to protect themselves. They're still users and they still deserve a positive user experience. Autosave helps them have that positive user experience. Antiviruses help them have that positive user experience. Windows features that help protect them from themselves (but annoy the hell out of informed power users) help them have that positive user experience. Using software should be as easy as using a microwave or driving a car. People don't have to know how those machines work, mechanically or theoretically, or how to fix them, in order to have positive user experiences with them and use them as tools to accomplish their goals. Software should be the same way.
Do you honestly believe the average user has a UPS? Or that they never try to use their laptop away from an outlet at very low battery life? These kinds of assumptions are what make for bad user experiences.
Perhaps you've heard of a thing called a power outage. I just had one last night. Or maybe you've had a cat step on your keyboard and somehow manage to close the window you were working in. There are enough acts of god and human error that still exist regardless of how flawless the program you're working in is to make autosave highly valuable. The 1000 times you don't need autosave are not nearly as critical as the 1 time you do.
Specifically in Doom, there was an additional bug beyond the general sqrt(2) bug where if you were pressing up against an axial wall and facing either North or East, you could obtain a speed increase greater than 100%.
This isn't really a surprise because an interstellar impact is probably what placed it into the path of our orbit to begin with. But hey, I'm no astronomer/astrophysicist/whatever.
Most of these games are being shut down because they relied on GameSpy's master servers and matchmaking systems, which are finally being shut down. A lot of these servers are actually fairly simple, and new master servers could be set up, but most of these games are also 10+ years old and it's not seen as worth the effort. I don't know much about the other games, but I'm fairly sure the Battlefield games all can still be played online if you know the address of the server you're trying to connect to.
No. HL2 actually hides the inside of the building as long as the entire vis area is properly blocked off. It's a shame you're posting AC so you won't be notified of my reply and probably never see it.
I had to read it about 4 times before I realized what it was trying to say, but the math works out. It says there are 132 people. 12 are secretaries (all women), 12 report directly to Bezos (all men). If you cut out the secretaries and Bezos himself, you're left with 119 people, only 18 of whom are women.
It's not meant to be strenuous mentally on its own. It's meant to demonstrate the kind of detail and tedium required to be a game designer, because most people think it's all just goofing off and playing games. Extrapolate those questions to every single object and system in a game, from doors, to trash cans, to lamp posts, to ammo boxes, power-ups, enemies, weapons, equipment, etc. Someone has to make a decision about which ones will be in the game, what they will do, how they will behave, how users will interact with them, whether users even can interact with them, edge cases, exceptions, unexpected behavior, etc.
The point of the article is that these are questions a designer has to consider for every single object and system in the game, interactable or not. There are no obvious answers because the answers will be different depending on the nature of the game one is trying to design. Some of the questions aren't even relevant to most games (which is intentional on the part of the author). The point is that designing video games is not just coming up with fun gameplay, but handling a lot of tedious and mundane details for a complex interactive system, and coming up with answers and solutions for things that most players will never even think about (until it breaks).
Also the second set of lines are demonstrations of how a person from that area of production might influence or interact with the design of a game system or object, not questions to be answered.
It's not just a technological or man power problem. Even if we create holodeck technology that can automatically generate realistic environments for those other 60 floors, the game designer is still only going to let you go straight to the roof, because that's the game experience they're trying to create. That's what they think will be fun for most people (and they're right, by the way).
For most people, a truly open game is not fun. They're not playing BF4 to kick over furniture. They're playing it to shoot bad guys. They're playing it to interact with the gameplay systems. If you put them in a building with 60 floors, but the bad guys are only on the roof, 59 of those floors are a waste of their time. Obviously there are some games where exploration is one of the primary gameplay systems, but BF4 is not one of them. It's your responsibility as a consumer to do your research and find out which games fit your tastes and buy games that cater to your tastes. Not to try and insist that every game that's released be specifically tailored to your tastes.
In real life, there are plenty of doors for which you will never find the key lying around. More importantly there, are millions (billions?) of doors that are of no interest to you, ever. In a video game, it would be very difficult to set up a series of long term societal detriments for going around trying to open every door, or to easily express to the player why the character they're playing has no interest in one door vs. another, or why what's behind most doors is not of interest to the gameplay or the plot of the game. But it'd also be extremely strange to walk down a city street environment and have there be no doors into any of the surrounding buildings. So we put up false doors as window dressing so the environment looks familiar, but then we build a visual metaphor that lets players see at a glance which doors are unimportant so they don't bother to try them. This can be by leaving them as a flat texture instead of modeled, making openable doors a different color or have specific lighting or highlights, making openable doors have handles and unopenable ones not have handles, or as the article suggests, putting rubble or something (depending on the context of the game) in front of unopenable doors. You can even make unopenable doors make a specific sound effect when approached, such as the sound of a handle jiggling on a locked door, or the sound of the character specifically saying "It won't open," etc. (although only communicating it once the door is approached can be tedious for the player).
First of all, you've failed to understand the premise of the article. The article is not intended to answer any of those questions, it's meant to communicate to the reader that these are all considerations that have to be made not just for a simple and seemingly obvious object like a door, but every single object and potential object in a video game.
As for your assertions:
> 2. Can the player open them? Yes. If you have doors in a 3D game and they don't behave like doors, you have failed.
False. When you walk down the street in your neighborhood, do you walk up to every single door trying to open it? No. You ignore 99% of the doors you pass in real life. They can usually be opened, but it's often not relevant or important to you that you open them. If a door is not relevant to gameplay, but your environment is one that in real life would contain a lot of irrelevant doors, then it's expected and correct to put a bunch of false, graphical-only doors to make the environment feel more familiar and natural. The important part, and what's alluded to in the article, is that you create a clear visual logic for the player so they can recognize which doors are important and openable vs. which ones are just there to make the environment look more interesting.
> 5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.
Again, it's not about how it should work, but rather that you have to consider every possibility and account for it. If you create a door with a set of states and triggers, but only consider one player, then the second player could potentially cause problems with the state by triggering states out of order in a way that a single player could not. If, for gameplay reasons, you want the door to immediately lock behind the player to trap them, and you introduce a second player who does not pass through the door when the first does, you have now separated the players and potentially prevented one of them from participating in your gameplay encounter because you forgot to consider there might be a second player in your multiplayer game.
> 7. What if the level is REALLY BIG and can't all exist at the same time? Then your technology is not good enough to implement your vision and one or the other needs to change. See point 2.
Most games these days stream level and texture data from disk rather than keep it all in memory. This allows more complex scenes in each area and disguises or obviates load screens. Doors can be a good way to section those areas off and control the flow so you can optimally stream that data from the disk without the player noticing. The scope of the project could be fine, but now the level designer has to design his levels with this aspect in mind. The design has to be understood all the way down the line, from project lead to engine programmer to level designer to quality assurance (so they can try to break it in a way a customer might accidentally break it) in order for the result to prevent this from becoming an issue in the final product.
It's not that hard to develop a visual language within your game to make it clear to the player which objects are interactive and which are not. That's why some of the questions in the original article are things like "Do you put rubble in front of a door to indicate that it won't open?" It becomes a clear visual metaphor for the player that doors with rubble in front do not open, and ones without rubble do (or at least can given proper conditions). For your ledge grabbing example, all you have to do is look at the Uncharted series. Climbable ledges in Uncharted have a distinct color and texture that makes them stand out from non-climbable ledges. This is *exactly* what the article is talking about. You didn't know which ledges in Tomb Raider were climbable because their visual metaphor failed to inform you of which ones were climbable and whi
Doors infrequently have windows in video games because they are used to block visual information from the renderer and gameplay information from the player. But doors with windows do exist. Even Half-Life 1 had some.
It has nothing to do with "Americans." It has to do with the fact that every single open source project that had a version called "Open Something" now has a fork called "Libre Something," even when the name change doesn't make sense (because the original version was "libre" software, too).
It's just people getting tired of a silly trend and a lazy naming scheme.
Slashdot Mirror
But how much power is that in libraries of congress?
posting to undo accidental moderation
I feel like the requirements for the Turing test have been consistently lowered over the years to match what would be considered realistic to achieve rather than, as Alan Turing seemed to believe, demonstrate that a computer can be said to actually be "thinking."
People have been modifying the text on these signs for almost a decade. Most companies don't even bother to change the password from the default.
This is the most insane, paranoid thing I've ever seen posted on Slashdot. And that's saying a lot.
It's not relevant that those users are ignorant or don't make any effort to protect themselves. They're still users and they still deserve a positive user experience. Autosave helps them have that positive user experience. Antiviruses help them have that positive user experience. Windows features that help protect them from themselves (but annoy the hell out of informed power users) help them have that positive user experience. Using software should be as easy as using a microwave or driving a car. People don't have to know how those machines work, mechanically or theoretically, or how to fix them, in order to have positive user experiences with them and use them as tools to accomplish their goals. Software should be the same way.
Do you honestly believe the average user has a UPS? Or that they never try to use their laptop away from an outlet at very low battery life? These kinds of assumptions are what make for bad user experiences.
Perhaps you've heard of a thing called a power outage. I just had one last night. Or maybe you've had a cat step on your keyboard and somehow manage to close the window you were working in. There are enough acts of god and human error that still exist regardless of how flawless the program you're working in is to make autosave highly valuable. The 1000 times you don't need autosave are not nearly as critical as the 1 time you do.
That works for Descent. Now explain why the Doom guy does the same thing.
Specifically in Doom, there was an additional bug beyond the general sqrt(2) bug where if you were pressing up against an axial wall and facing either North or East, you could obtain a speed increase greater than 100%.
http://doom.wikia.com/wiki/Wal...
http://doom.wikia.com/wiki/Str...
This isn't really a surprise because an interstellar impact is probably what placed it into the path of our orbit to begin with. But hey, I'm no astronomer/astrophysicist/whatever.
Supposedly in the German version they completely changed the plot so it's about a mad cult instead of Nazis. I can't verify this for myself.
There have been like 100 id tech games without Carmack. What the hell do you think they were licensing for almost 20 years?
Don't be ridiculous. They'll survive just fine. Their property holdings may not. It's not going to flood overnight. There will be ample warning.
Most of these games are being shut down because they relied on GameSpy's master servers and matchmaking systems, which are finally being shut down. A lot of these servers are actually fairly simple, and new master servers could be set up, but most of these games are also 10+ years old and it's not seen as worth the effort. I don't know much about the other games, but I'm fairly sure the Battlefield games all can still be played online if you know the address of the server you're trying to connect to.
No. HL2 actually hides the inside of the building as long as the entire vis area is properly blocked off. It's a shame you're posting AC so you won't be notified of my reply and probably never see it.
http://www.optimization.interl...
I had to read it about 4 times before I realized what it was trying to say, but the math works out. It says there are 132 people. 12 are secretaries (all women), 12 report directly to Bezos (all men). If you cut out the secretaries and Bezos himself, you're left with 119 people, only 18 of whom are women.
Half-life 2 actually has a flag you can set on windows so that at a distance they're opaque and as you approach them they become transparent.
It's not meant to be strenuous mentally on its own. It's meant to demonstrate the kind of detail and tedium required to be a game designer, because most people think it's all just goofing off and playing games. Extrapolate those questions to every single object and system in a game, from doors, to trash cans, to lamp posts, to ammo boxes, power-ups, enemies, weapons, equipment, etc. Someone has to make a decision about which ones will be in the game, what they will do, how they will behave, how users will interact with them, whether users even can interact with them, edge cases, exceptions, unexpected behavior, etc.
Woosh.
The point of the article is that these are questions a designer has to consider for every single object and system in the game, interactable or not. There are no obvious answers because the answers will be different depending on the nature of the game one is trying to design. Some of the questions aren't even relevant to most games (which is intentional on the part of the author). The point is that designing video games is not just coming up with fun gameplay, but handling a lot of tedious and mundane details for a complex interactive system, and coming up with answers and solutions for things that most players will never even think about (until it breaks).
Also the second set of lines are demonstrations of how a person from that area of production might influence or interact with the design of a game system or object, not questions to be answered.
It's not just a technological or man power problem. Even if we create holodeck technology that can automatically generate realistic environments for those other 60 floors, the game designer is still only going to let you go straight to the roof, because that's the game experience they're trying to create. That's what they think will be fun for most people (and they're right, by the way).
For most people, a truly open game is not fun. They're not playing BF4 to kick over furniture. They're playing it to shoot bad guys. They're playing it to interact with the gameplay systems. If you put them in a building with 60 floors, but the bad guys are only on the roof, 59 of those floors are a waste of their time. Obviously there are some games where exploration is one of the primary gameplay systems, but BF4 is not one of them. It's your responsibility as a consumer to do your research and find out which games fit your tastes and buy games that cater to your tastes. Not to try and insist that every game that's released be specifically tailored to your tastes.
In real life, there are plenty of doors for which you will never find the key lying around. More importantly there, are millions (billions?) of doors that are of no interest to you, ever. In a video game, it would be very difficult to set up a series of long term societal detriments for going around trying to open every door, or to easily express to the player why the character they're playing has no interest in one door vs. another, or why what's behind most doors is not of interest to the gameplay or the plot of the game. But it'd also be extremely strange to walk down a city street environment and have there be no doors into any of the surrounding buildings. So we put up false doors as window dressing so the environment looks familiar, but then we build a visual metaphor that lets players see at a glance which doors are unimportant so they don't bother to try them. This can be by leaving them as a flat texture instead of modeled, making openable doors a different color or have specific lighting or highlights, making openable doors have handles and unopenable ones not have handles, or as the article suggests, putting rubble or something (depending on the context of the game) in front of unopenable doors. You can even make unopenable doors make a specific sound effect when approached, such as the sound of a handle jiggling on a locked door, or the sound of the character specifically saying "It won't open," etc. (although only communicating it once the door is approached can be tedious for the player).
First of all, you've failed to understand the premise of the article. The article is not intended to answer any of those questions, it's meant to communicate to the reader that these are all considerations that have to be made not just for a simple and seemingly obvious object like a door, but every single object and potential object in a video game.
As for your assertions:
> 2. Can the player open them? Yes. If you have doors in a 3D game and they don't behave like doors, you have failed.
False. When you walk down the street in your neighborhood, do you walk up to every single door trying to open it? No. You ignore 99% of the doors you pass in real life. They can usually be opened, but it's often not relevant or important to you that you open them. If a door is not relevant to gameplay, but your environment is one that in real life would contain a lot of irrelevant doors, then it's expected and correct to put a bunch of false, graphical-only doors to make the environment feel more familiar and natural. The important part, and what's alluded to in the article, is that you create a clear visual logic for the player so they can recognize which doors are important and openable vs. which ones are just there to make the environment look more interesting.
> 5. What happens if there are two players? Doors behave the same for all players. It's a door. See point 2.
Again, it's not about how it should work, but rather that you have to consider every possibility and account for it. If you create a door with a set of states and triggers, but only consider one player, then the second player could potentially cause problems with the state by triggering states out of order in a way that a single player could not. If, for gameplay reasons, you want the door to immediately lock behind the player to trap them, and you introduce a second player who does not pass through the door when the first does, you have now separated the players and potentially prevented one of them from participating in your gameplay encounter because you forgot to consider there might be a second player in your multiplayer game.
> 7. What if the level is REALLY BIG and can't all exist at the same time? Then your technology is not good enough to implement your vision and one or the other needs to change. See point 2.
Most games these days stream level and texture data from disk rather than keep it all in memory. This allows more complex scenes in each area and disguises or obviates load screens. Doors can be a good way to section those areas off and control the flow so you can optimally stream that data from the disk without the player noticing. The scope of the project could be fine, but now the level designer has to design his levels with this aspect in mind. The design has to be understood all the way down the line, from project lead to engine programmer to level designer to quality assurance (so they can try to break it in a way a customer might accidentally break it) in order for the result to prevent this from becoming an issue in the final product.
It's not that hard to develop a visual language within your game to make it clear to the player which objects are interactive and which are not. That's why some of the questions in the original article are things like "Do you put rubble in front of a door to indicate that it won't open?" It becomes a clear visual metaphor for the player that doors with rubble in front do not open, and ones without rubble do (or at least can given proper conditions). For your ledge grabbing example, all you have to do is look at the Uncharted series. Climbable ledges in Uncharted have a distinct color and texture that makes them stand out from non-climbable ledges. This is *exactly* what the article is talking about. You didn't know which ledges in Tomb Raider were climbable because their visual metaphor failed to inform you of which ones were climbable and whi
Doors infrequently have windows in video games because they are used to block visual information from the renderer and gameplay information from the player. But doors with windows do exist. Even Half-Life 1 had some.
It has nothing to do with "Americans." It has to do with the fact that every single open source project that had a version called "Open Something" now has a fork called "Libre Something," even when the name change doesn't make sense (because the original version was "libre" software, too).
It's just people getting tired of a silly trend and a lazy naming scheme.