It looks like you're new here. If you want to get involved, click one of these buttons!
Alternative thread title: If the reason that a game is bad is because of graphical choices, then the graphics are bad, regardless of how pretty they are.
Basic thesis of topic: The way that most people evaluate game graphics is all wrong.
In many situations in game design, there aren't right and wrong answers, but only trade-offs. That's certainly true of graphics, but not just in the ways that you might immediately think of. I'd like to argue that, for many people, your opinion of how good a game's graphics are should depend at least as much on whether you agree with the trade-offs that the game designers chose as how pretty the game looks in screenshots. For example:
You can make screenshots look prettier, or you can make the game load faster.
You want prettier screenshots? You're going to need more and higher resolution textures. You're going to need to use textures for more things, including lighting and possibly geometry. That means more loading stuff off of the hard drive, and that, in turn, means that that you need longer and/or more frequent loading screens. The extreme case of a seamless world mandates much less loading art assets from the hard drive, and that forces you to give up a lot in how pretty the screenshots look.
You can have prettier looking characters, or you can have the capability to draw more characters simultaneously.
Want to make your characters look prettier? Well then, you're looking at more textures, higher resolution textures, more vertices, and generally a larger performance hit to draw each character. The larger the performance hit to draw things, the fewer things you can draw without making performance choke. Want to have epic battles with 50 characters on your screen at once? They're not going to look nearly as nice as what you could do if you didn't care whether your engine could draw more than 10 at a time.
You can have prettier looking characters, or you can have more customizable characters.
If you just want to have one character and make that one character look good, that's not so hard to do. If you want to give players a bunch of choices in each of 30 different areas, some of which are sliders, and you want to make characters look good regardless of what players choose? Or even just look good for any player choices from a player trying to make a character that looks decent? That's much, much harder.
You can have prettier looking terrain, or you can see terrain from farther away.
You know those trade-offs with drawing characters? They apply to terrain as well.
You can have prettier looking screenshots, or you can have a dynamic world with day/night cycles.
If all light sources are going to always and forever going to be the same, then you can precompute a lot of lighting and store it. If you want to have the sun move in the sky and lighting change accordingly, then you precomputing lighting for when the sun is in one place only works when the sun is in that exact spot. That doesn't work, which forces you to do much less demanding lighting computations that can be handled on the fly.
You can have prettier looking mobs, or you can have mobs that you can tell apart.
If you have ten completely identical mobs, you can use the same art assets for all of them. Want to be able to tell them apart rather than fighting indistinguishable masses of mobs? Then textures or vertex data or uniforms or something is going to have to be different. That means additional load on the video card per character (probably additional video memory required, certainly GPU time to switch resources), which reduces the amount that you have available per character to draw.
You can have a prettier looking game world, or you can have a game world that players can substantially modify.
Letting players modify things in the game world means you need more flexibility in what you can draw, which restricts your ability to make things look as good as possible. Things in the game world that players can change are likely to limit your ability to precompute light maps and such. And there's also the fear that players might do things to make your game world look uglier than what you would have done.
You can have a prettier looking game world, or you can have dynamic weather and seasons.
If you only have to decide what an area looks like once, you can make it look pretty good. If it needs to be computed dynamically with a whole bunch of different possibilities, making them all look good is much harder.
You can have a prettier game world, or you can have a less repetitive game world.
The more you reuse art assets, the fewer such assets you have to make, and the more you can focus on making each one look good. Remember how Final Fantasy XIV had the game world repeat a zillion times? That's just taking this to an extreme in giving you pretty screenshots.
You can have prettier screenshots, or you can have smoother animations.
If you're going to compute each frame of animations manually, then the more frames you have, the less work you can put into each one--and the worse that one will look. If you're going to generate animations procedurally with smooth functions to ensure that the animations are always smooth, any particular frame is not going to look as nice as it could have if you created each frame manually.
You can have a prettier game, or you can have a game that is faster to download and takes less space to install.
More and higher resolution textures can make a game look better. They also bloat the game installation size, which makes the game take longer to download.
You can have prettier terrain, or you can have collision detection that closely matches what the terrain looks like.
Some shapes are simply impractical to do for collision detection. If you want your terrain's graphics to match its collision detection, then you sometimes have to say, I can't do the collision detection for that, so I'm not going to draw it. That means that the game won't look as good, at least if you ignore screenshots of areas where the collision detection is flagrantly wrong.
I'm sure that there are more examples, but that's all that I could think of off the top of my head, so I'll stop now. But in every case above, you can make screenshots look better, or you can do something else. In every one of those cases, I'd lean much more toward the "do something else" than what most AAA games tend to go for.
If you're of the view that prettier screenshots are more important than the "something else" in every case above, then the way you evaluate game graphics fits your preferences. If so, then this thread isn't for you. But thanks for reading this far anyway.
But if you want a seamless world, or a dynamic world with changing time of day and seasons, or greater character customization, or the ability for players to modify the game world, or epic battles with many players at once, that means that you want games to sacrifice prettier screenshots for the sake of something else that you think is more important. If games do exactly that, then you should say that that makes a game's graphics better, not worse, because the game's graphics are more to your liking, even if they don't look as good in screenshots.
Now, trade-offs such as those above are not the only factor in how good a game's graphics are, of course. Some artists are simply better at what they do than others. Some programmers are simply more efficient than others. Some projects simply have a bigger budget than others, and that lets you do more stuff. Talent and resources play a big role in the quality of a game's graphics, too.
But if you want features that require making a game not look as pretty in screenshots and then a game implements exactly what you want, don't complain that the game isn't pretty enough. And conversely, if you dislike a game because it left out features that you wanted for the sake of making the game look prettier, don't be quick to praise the graphics that just ruined the game for you.