What Does IGLPR Mean to Me?

It seems that I’m releasing an Indie Game Let’s Play & Review (IGLPR) video every day now. What started out as an attempt to break into the world of Let’s Plays and Minecraft has instead turned into applying my computer science education to indie game reviews.

 

You see, an IGLPR isn’t a method for me to get new games to play. It’s all about providing feedback to the game developer by using elements of a usability test. This is a type of analytic tool that developers employ to better understand how users interact with software. Usually, a person who is taking a usability test is given a script to follow that asks for specific actions to accomplish. “Open a document from the USB drive”, for example. The user is expected to perform the action and describe what they’re doing, what they’re thinking about, and other factors in their experience in performing the task requested. There are usually several tasks, questionnaires, and maybe a short survey. All of this data is recorded, whether it’s a good experience, bad experience, how difficult or easy the tasks were, and things of that nature. The developer then has information that can be acted upon to make an interface easier or more intuitive to use. You see, usability testing is a valuable tool that allows a developer to improve a product and make the user experience (or UX) more “enjoyable” for those who are the intended audience.

 

Usability testing is not the same thing as alpha or beta testing. These types of tests are used to find and report bugs, for the most part, and are usually not set in a controlled environment.

 

From my time as a game dev (very limited at that), I usually had one or two people to bounce ideas off of and check out my game’s interface or limited functionality. Usually, I got feedback that was meant to make me happy or to encourage me to continue. I love my friends for thinking of my feelings like that, but as a developer, I want the good, the bad, and the ugly for what I’m presenting. If a feature sucks, tell me with all the vitriol in the world if that’s how it makes you feel. If something is awesome, praise it if that’s what you want to do. If something needs work, give it the praise or hate you feel fit to provide and then suggest alternate methods to how you would like to see the interface handled. I didn’t really have that. And any time I got a partner to work with, I did the communication, the work, and then things fizzled with me holding the project and doing it by myself anyway. Which ultimately lead to failure. Which is not a bad thing, in and of itself, just something that kept me from getting something out there in a more permanent fashion.

 

The long and the short of it is: If you’re working as a solo developer, it is really, really frustrating and difficult to get good, honest feedback. Especially if you don’t have presence in the indie dev world. It is very hard to do everything yourself. It is very easy to become invested in the way you present a game, design the interface, apply the mechanics and physics of the world. You become too close to what you’ve created and that means you generally don’t see things as clearly as an “outsider” might.

 

So, with my IGLPR videos, I provide a valuable service. First and foremost, I provide a first look/first play of a game. I refuse to do an IGLPR for any game I’ve played before. Why? Because that initial reaction you get from a new player can’t be captured after the first time the game is played.

 

I play many games without reading the instructions first. Why? Because that’s how an average person is going to play the game. They are going to start it up and jump right in, feet first, shouting about their new game all the way until they hit that wall. If there are in-game instructions, that makes things easier. Though, if it’s a lot to read, I’ll skip right to the action and start playing, using the in-game instructions as a reference. This shows how intuitive the game is to play, how easy it is for a new user to start the game and just go.

 

I ignore the graphics, audio, technical aspects, and gameplay when I give a rating. Sure, I comment on how they look, whether they’re pleasing or whatnot, but these things are superfluous and can change at the drop of a hat. The only thing I harp on is the ability to customize a user’s controls. There are many people who aren’t right/left handed, that are handicapped, or have issues with certain control setups (WASD irritates me). Without giving the users the ability to change how they interact with your game is a sure-fire way to lose those players.

 

I play the game for roughly twenty to thirty minutes, though sometimes the length can get out of hand if I’m really enjoying a game or if the game is really complex. Even games that are simple to play and have rounds that last only a minute or so get at least a full twenty.

 

And why do I do this? Why do I do it free of charge? Well, it’s my hope that I can help devs improve their games and make them more fun. A lot of indie devs can’t afford to pay for proper usability tests and, to be honest, I don’t think many even realize that they can do this. They’ve heard of playtesting (alpha or beta) or unit testing but may have never even heard of a usability test before.

 

In the end, I hope this helps get my name out there, that I’m here to help others, and that I can become a successful game reviewer. I hope that one day I can do this for a living, devote more time to it, and have fun doing it.

 

Well, this was a bit of a chaotic read. I hope you got a bit out of it. And, as always, this is Excalibur. And I’m out.

Updated: November 17, 2014 — 7:48 am