This is the first in a series where I document and reflect on my experience building my knowledge in game development, and writing through the process. Think of it as a bit of a diary — entertainment for the learned, therapy for the learning.
In my first game “A Thoughtful Gift”, the user unpacks items from a gift box accompanied by sound effects and a dialogue bubble declaring each item. As the creator of the game, of course I was well aware of every detail put into it, and in each of my playthroughs I took my time cherishing every “ding” and subsequent animation.
Once completed and available for browser play, I had colleagues and friends try it out with the intention of receiving accolades for my effort and constructive feedback. Not surprisingly, the response landed more on the ‘constructive feedback’ end than the former. A few weeks later, a game reviewer posted a video on YouTube that featured my game among others.
In the video, the game reviewer clicked through the dialogue and animations too quickly, in my opinion, to “appreciate the effort that went into creating the game”. I felt like this made the game seem shorter than it actually was (which was already pretty short).
I realized that my perception of how the game should be experienced doesn’t matter. I can’t stand over each player’s shoulder and tell them to “play it slower, or else.” Going forward I knew to ensure that the gameplay components I wanted control over, I actually took control over — rather than hoping the player sees and adheres to my vision.
I practiced this in my next game “Bombastic Battle Arena”, where the next button is not shown until the full sentence has been displayed at the intended programmed pace. We can all have a momentary sigh of relief knowing my dialogue will not be clicked through at sonic speed.
Now I could chalk this lesson up to being a rookie mistake and write a sticky note reminder to myself to “always govern the dialogue system with an iron fist”. Rather, I’ll write a note reminding myself that the factors of user experience are bigger than that. Regardless of how many use cases I resolve alone, I can’t account for something I never thought to look for. That is where user testing comes in.
It’s a common tip that I see all the time in articles to user test your game before releasing it, but I think it takes firsthand experience to actually understand why it’s important to do so. I’m glad to have made this mistake early on (I’m sure there will be many more mistakes to come), but I have gained an appreciation for the fine-tuning iterative process, and am now of the idea that the more user feedback, the better.
One of the reasons user testing is necessary is because we are limited by our own experiences in the broadest sense. It is impossible to take into consideration what the user will do because you don’t know what the user will do until they actually do it. Having real-life players point this fact out is a concept that I’ve learned to take as constructive criticism, and not as malicious disregard for developer intentions (dramatic I know, but I need my first post to end with a bang).
Thank you for reading this far, you can find me by visiting kazmuir.com. If you have anything to add to this topic please comment below. I am all ears (not in a literal sense, but it would be pretty cool if that were the case).