As seems to normally be the case, here I am on Sunday night, trying to get everything done that needs to be done, and there is so much more that could be done. However, it feels like a rhythm is starting to develop in our workflow, decreasing stress and panic greatly. Communication in the group has been great this week.
I was required to write a problem statement paper for our VR Rhythm game, which was particularly difficult to me. What world problem is solved by creating a video game? How can a problem statement be written for the creation of a game? I decided to try to explain that there is a demand for new games, and so the creation of our game would help meet that demand, and thus solve that problem. It was a stretch and flimsy at best. Receiving an 80% with notes saying that I didn’t properly hit the prompt, I decided I would resubmit.
So, after many hours of debating with myself, some guidance from the professor, and forcing my wife to listen to my complaints, I selected a new approach and tried again. Unfortunately, my original could not be salvaged. I needed a complete rewrite. And it paid off! I have now received full credit and glowing comments from the professor.
My advice for writing a problem statement for a video game project:
- Look internally for the problem! The problem should not be something external to the game, but instead should be a problem that you expect to encounter in developing the game.
- Look to other developers for solutions! Chances are other games have faced similar problems to your own. How did they address the problem? Would that work for your game?
- There may be multiple solutions! My whole team ended up addressing very similar problems, and we all came up with different ways to solve it. Ultimately, combining portions of all of our solutions will create more novelty than any singular solution.
- The whole project is not the solution! You don’t need to find a way that every piece of your game is tied in to solving the problem. It could be solved by a single system, or it could be many, but don’t try to force your entire project to be the solution to one problem.
Writing problem statements, and requirements documents aren’t very fun to me. However, I can already see the benefits of having these available when we start developing in earnest. Looking to the future, developing plans for how to address problems, and outlining specifications: it’s all making me excited to make something!
