Devlog #10

This week we started a new project, making our own asymmetrical battle game with a boss and character cards. It reminds me of Dungeons and Dragons, as well as Pokémon. 

Tuesday was spent coming up with an idea for a game that followed the Battle Battle layout but was original in how characters attacked and how enemies reacted. Our group spent a bit of time brainstorming before coming up with the idea that the players are firefighters going against a fire. We then added further on with different rounds, each round getting a bit more difficult than the last. 

I realized earlier today that one of our group members went ahead and designed characters and what powers they had. I was fine with this, since 2/5 of the characters we had an idea for. I was going to work on our Engineer character and submit ideas for powers, as well as look into any other characters we could do. However, due to a busy schedule and other assignments (and the teams layout) I was behind on what I needed to do, and someone mostly did it for me. It led to a bit of confusion on my part, especially having to reread things that happened while I was working on other school work. I think having a method of tracking all the info we have down is needed.

"Team members might end up with different understandings of the game, duplicate work might get done, or even worse, work might not get done at all" (Macklin, Sharp). The book states three methods to help stop this from happening; design documents, schematics, and tracking spreadsheets. I believe our team could benefit from one of these methods, though it is up to us to see if its really necessary and which method to use if needed.

"... a combination of dice rolls, card draws, or other random processes determine the events and winners" (Hiwiller). Randomness and luck seems to be a major part in developing this sort of game. Our group playtested with the new roles and with how the fire acts in each round, with the randomness coming from dice rolls. However, the players had the advantage of abilities, with the fire having the advantage of high HP, enough to where it cannot be taken out by one single player. It provided balance to each side, so that the players didn't get through each round too quickly but didn't have the chance of losing if all players talked amongst one another.

"Fairness is key to how players perceive randomness. It they believe that the randomness limits their chances at victory, they can view it as less fair. If they believe that the randomness enhances their chance at victory, they can view it as enforcing fairness" (Hiwiller). This was a struggle for our group before Thursday. We had to come up with a way to make the game fair to the players, where they could win 50-75% of the time, but still provide some challenge for them. We knew that we had to make the boss fire a bit difficult, but not overly so. However, I believe we came up with a solution on Thursday in the middle of playtesting. We increased the HP of the enemies by half, so 8 HP turned into 16, 10 into 20, etc. It changed the game immensely, as no one player could now one shot an enemy before it had a chance to attack. It even made team discussion while strategizing more interesting, as we had to determine who is willing to take damage in favor of either equalizing the damage across enemies or taking them out one at a time. In our playtest sessions, the randomness of dice rolls was still favorable, because while I was getting high dice rolls with pure luck, there was still the off chance I would roll low and either not help my teammates heal or not do a lot of damage. In my eyes, our game is really fair, as the fires are tanky enough to not be taken out immediately, but all characters are usable and have their own special abilities to help out other players and still make a dent without feeling like the character is weak or useless.