Peer Reviews: Why We Need Game Testers
The peer review sessions on the final week of class were crucial for game development. Since I had been focused on designing the game, I mainly was checking to see if passage algorithms worked. The feedback helped me get back to the playing viewpoint and aspect of my game. No wonder game developing companies hire game testers before final launches. Sometimes, you need a fresh new pair of eyes (someone who hasn’t been exposed to your game world or doesn’t know anything about your game) to really see how and what your game is.
Moreover, these breakout room sessions were refreshing as I was able to see other people’s games. It was fun to see how different and diverse everyone’s Twine projects had turned out. Playing a new narrative is always exciting. Also, seeing how others designed their plotlines was an eye-opener: sometimes I would find a new way for passage links, other times I would be giving advice on how to improve their games. It was a fruitful session in both game design and play.
After the group sessions with classmates on our final week, I realized what I thought was easy to play/click through or obvious, sometimes turned out complicated or unclear to users. On our last day, everyone played each other’s games. Many were playing my game for the first time, and they were the game testers I needed. (This is clearly why test runs are done multiple times before a game gets launched.) Things might look great and work from a game developer’s perspective, but that won’t matter if the average player finds the game difficult or boring.
Improving Gameplay and Design Based on Feedback
Based on the feedback I received, I had made some crucial changes to my Twine project.
First, I made sure instructions were clear — so that players understood what needed to be done and that all steps/processes were essential for the storyline and game choices.
In my game project, I’ve enabled the player to choose from three characters before they continue their journey. I thought it would be necessary to give them — and make them read — the overall lore and background information of each character before they made their decision. In order to do this, I created a list based on passage history and only allowed the “Continue” link to appear if the player had gone through all three worldbuilding passages. During the final play session with feedback post-its on the class Miro board, someone gave feedback on they were not sure if these passage transitions were intentional and that it felt difficult to proceed. I realized how poor my instructions were for that section, so I included more detail.
Next, I was recommended to implement more conditional statements, macros, and math coding to simplify branching storylets and smoother gameplay. For my first iteration, I had several passages and even more link arrows. I was really focused on just writing out my whole plotline. Later, with the help of feedback comments, I realized number of passages could be reduced tremendously with if statements and macros. I was toying around with the program and realized you could even include images inside your if statements: your image would differ depending on your choice from previous passages. Also I had incorporated health bars and damage point in my game. At first, I was just using numbers for health and damage. However, later on, I noticed it was much more efficient and effective to use datamaps and math coding for damage and health stats.
In the end, it was a great experience. I had read and learned a lot about game design — also about games and playing in general. I also had the opportunity to try Twine and make my first narrative game. I look forward to learning new game design platforms and, from now on, will pay extra attention to design and other elements when I play games:)