The Troubleshooting Review

I wrote this a while back to try and get myself to write something slightly risky. I dunno if it's law school or what, but often I feel like my writing starts to feel excessively safe. Not in the sense of being overly-friendly or not saying anything batshit, there's plenty of that to go around. I mean just posting something that I don't really know what the response will be. I'm not always right when gauging the interweb's reactions but I can usually narrow it down to what ballpark I'm going to land in.

This post, instead, was just me spotting a problem that I'm not really sure will ever have a final definitive answer and throwing one out on the table anyways. As games begin to rely heavily on dialog trees, QTE's, and branching paths a reviewer can't really presume that one playthrough of a game is going to fully describe it. Time constraints make it so you also can't expect them to play the game repeatedly, leaving you with a weird problem of what exactly one is supposed to discuss when reviewing a video game.

All I propose is to just think of them like machines that produce experiences instead of experiences themselves. A lot of reviewers already do this, almost all academics I've met do. A more design-centric approach is nothing new, but what it means for a reviewer is to put a bit more effort into actually seeing if you can break the game. So many people who review games are accustomed to gaming's conventions that they often aren't really accurately describing how the game will work for someone new to the genre.

I'm guessing the reaction will be interesting.