Blog Post 6 - Unit 3 Postmortem

December 7, 2022

Group 5 

The game that my group made is named Raid. The game was a roleplaying game in which two players cooperatively fought against waves of mutated insects in order to reach and defeat the boss. Within the game, the players would become stronger by receiving items after each wave which could be used to damage the monsters or heal themselves. 

The target audience for this game was that we wanted to attract players who were somewhat interested in the dice-rolling combat of Dungeons and Dragons and also interested in the rogue-like item acquisition of games such as Risk of Rain 2. The player interaction pattern that Raid utilizes is Cooperative Play, which, as the name suggests, has players cooperating together against the game.

An earlier build of Raid.

One issue that we encountered in our Iterative Design process was that the rule sheet was lacking in some explanations and overcompensating in others. With this rule sheet being the third and final rule sheet of the class, it seems that all three of the rule sheets always were lacking in the same aspect that the explanations were not fully fleshed out enough for the players to proceed without having confusion or hitches in the player experience. 

For this rule sheet in specific, we went far overboard with details related to the cards. There was initially a legitimate reason for this. When we were brainstorming and still trying to formulate what direction we wanted the game to go, we needed to lay out all of the possible stats which the player classes, the item cards, and the monster cards would have. That way, when it came to the production of the actual prototype, we could simply scan through it and see what needed to be added or changed. 

However, our mistake is that once our initial brainstorm for the cards was completed, it should have been shifted onto another document. It contributed nothing to the main document for new players who were trying to go through our rule sheet, and it only caused the document to be more cluttered and the most important information to be less condensed.

The reason that the card abilities and stats did not need to be attached to the document was that once we finished the prototype, we could simply attach the image files of the prototypes to the document and delete the left-over stats.

Once we were finished with these prototypes, the stats could have been removed from the sheet.

Though we had a lot of excess writing in the rule sheet, there were still elements that we missed that should have been expanded upon for the players. For example, it was not explicitly clear to the players that only a single item could be used per round. On our second playtest, the players exploited this gray area by using all of their items every round alongside their basic attack. But, this observation taught us something very important. We noticed that the players were enjoying themselves to a greater degree when they were allowed to stack combinations of items however they desired. So, we explicitly implemented it into the game.

A later build of the game.

Another oversight that we noticed later, though more minor in comparison to the other issues, was that it was hard to distinguish between the item cards and monster cards when face down. There was nothing on the back of the cards, and both cards were the same size. So, the cards got mixed up and confused the players.

In the future, I am going to try and cut away details that are not immediately necessary for the players to know. I am also planning on starting with smaller ideas and building upon them instead of starting large and cutting away ideas.