Systems Game Reflection

P3 seemed almost impossible at the beginning. It took our team a week to decide on the system we want to model because we did not fully understand what systems game is. However, once we finally decided on our system, networking in the industry, we worked extra hard to make sure we end up with a satisfying game.

We ran 10 playtesting and had 6 prototypes. Our game evolved rapidly through these prototypes and testings and each testing and prototype gave me great lessons.

For the first prototype, we started by making a very simple game that teaches one essential thing about networking: giving and receiving help and forming a relationship. After playtesting the game, we realized the game lacks one thing, but the most important thing — the game does not reflect the system well enough. The testers all felt like they were not networking, but rather matchmaking.
From this first prototype, I learned that in order for a game to reflect the system well, every single element of the game should reflect the system — the goal of the game, the rules of the game, the tools of the game, and the mechanics of the game.

After the epic failure and great learning from the first prototype, we brainstormed ways we can make our game better. Trying to come up with a game from scratch was very difficult. However, luckily, we came across an existing game we could use as a start: a game called “Sequence.” Strangely, lots of elements in Sequence seemed applicable to our system. Therefore, we decided to start our second prototype almost the same as the game sequence. Same rules, same mechanics, same tools. The only difference was the meanings we gave to the tools and mechanics.

I was first very uncomfortable about using an existing game. It felt like we were copying the existing game and just changing the meaning of each element. However, once we started playtesting and updating our prototype, our game soon became very different from the game Sequence. I eventually learned that starting from an existing game is a great strategy when first trying to build the game.

Our 3rd to 5th prototypes were constant updates based on feedbacks from playtests. Most of the updates happened in order to make the game more fun and representative of the system. For each mechanics and tools we added in, we made sure it made sense in the networking world. From these sets of iterations, I learned that it would have been easier and better if we had started the whole thing this way from the beginning — before jumping on to making a game, writing down the things we want to represent in our game and then building mechanics and rules around them.

In our last set of playtesting and prototype, we made a big change: we changed the objective and scoring rules of the game. After playtesting our almost final prototype, we realized that the objective of the game does not represent the system well. We ended up changing the objective and winning status and at the end, the changed objective made more sense. It was interesting how we never received this critical feedback until the very end. From this, I learned the importance of playtesting.

In the end, I think our game modeled the networking system really well. I like how the objective of the game is to point high score, where the scores are determined by the forms and quality of the network each player is forming. Card drawing mechanism, usage of chance cards to expand based on the existing network, and rolling dice all represent the real world well.

I am going to continue working on this project for P4. I have not yet decided whether I want to make the game more representative of the system or just make it more entertaining. However, either way, I am excited to run more playtesting and learn more ways I can improve the game.