Game Design [Somewhat] Weekly-For SCIENCE!
While in class, we discussed research data, and about user testing, post-game testing, etc. Our homework was to find two games on Meta-Critic (one below 60, the other above 80) and find 30 reviews for each, and highlight game design terms. We then discussed in groups with each other about the games we chose, and how the comments were similar, or different.
While in theory, this exercise may have been thought to be a good idea, but in practice, it was a mess. If we were to use only “official” reviews (not by users) the reviews were extremely limited. Finding 30 reviews for each was way too excessive, and it was nearly impossible to find 30 reviews that were of “high enough” quality. It also felt like this project was a grade nine project, but just with more reviews to go through. It felt childish, and pointless, and there wasn’t a lot to “learn” from this lesson.
Earlier, we had reviewed terms and phrases in games. Why they were good, and why they were bad. The point of this homework was to have us see the similarities and differences with each good and bad game, no matter what it is. Although there were some similarities, some games were so bad it was all negative reviews, while others weren’t “so” bad and had mixed. It was difficult to find the same “What’s wrong with this” with 6 or 8 completely different games.
Also, ranking the similar flaws/good things was also difficult. Even if there were many similarities, to have all three or four people agree on the scaling of what affected the review the most (poor graphics, shoddy mechanics, poor controls, good music, etc) was the hardest part. Each person had their own idea of what was the “best” one to pick, and how they would rank each asset.
The point of the exercise was to see what made a “good” game, and what made a “bad” game, so we as developers would know what to avoid, and what to focus on while making our games. While the work itself was stressful, we covered what we already knew about game design, and what to avoid and what to pick when creating our game.
What would have worked a lot better, would be each person chooses one good and one bad game and create a review. What makes the game good or bad to you? What design decisions, or mechanics fall short? What makes that game, to you, the worst or best game you’ve played? That would spark a better discussion, than copying, pasting, and highlighting, supposed “professional” reviews. Is that not the point of being a game developer? To discuss with others what works an what doesn’t and why so you can all come to a mutual agreement to fix the issue in and of itself.
When I went through the reviews, I found users themselves used more accurate, and overall better, vocabulary relating to game design. The professionals used “Oh it’s good because the music.” While the users went a step forward with “The music evokes certain responses from the players at certain points in the game. It works well because…” and on. This assignment really was a letdown, and in future could have been worked a lot better, especially because the assignment seemed to only be worth participation marks.
Since doing that assignment and taking it up, we had already known a lot of the information, but it was still fine to go over to ensure we knew what we were talking about. We used that session to really dive deeper into what could make or break our game.
