EARLY PROTOTYPES

This was my first time working on a fully designed game and playtesting a game. Early prototypes and playtests hosted on Miro were very misguided and I still didn't have a grasp on how to present essential information through "paper" prototypes.

After prototyping and playtesting some more I gained the skills to host guided playtests and have my paper prototypes convey essential information and therefore makes the playtesters understand gameplay elements easier.

After the Semester ended, the team wanted to develop the game further. We focused on heavy iteration of game mechanics in order to fine tune the gameplay experience. 

Switching over to Tabletop Simulator as our base for playtests helped bring in a group of playtesters and the game emulates how the game would play in real life, allowing for me to gather better data and make informed changes.

While conducting playtests, I had to learn in staying silent and diligent in recording player data. This was difficult since I wanted to guide playtests to gather specific data. I later did this through creating a script that players had to follow during the beginning of gameplay. Afterwards they would naturally play with exceptions placed on rules sometimes.

Staying silent also leaves no designer influence on the player, which means they interact with the game mechanics in a more natural sense. Flaws pop up more creating pure data.

For playtest surveys, I focus on answers requiring some form of thought processes from the testers on why they did things and feelings they've had towards the game's mechanics. So no yes or no questions at all. I'd gather this data into charts and present them during meetings to allow for Actionable Items to be done by the end of the week.

ITERATING ON DESIGNS

Iteration happened constantly and fast during development. The problem in my iteration was the fact that the team never defined what the game experience would be. I iterated for the purpose of creating balanced gameplay.

Gameplay can only be balanced if said balance was in service of maintaining some sort of experience. I did develop a personal goal: to make sure that all weapon cards could never overpower another one and that their abilities enabled the player to perform their own personal strategies.

This helped focus iterations and it did help improve the cards. But these weapons exist within a context of a board, Fuel Spawns, Weapon Power Ups and more. These didn't have a solid goal and so I didn't have the opportunity to iterate on those designs.

I was also designing the game with the wrong approach in mind. I was designing with a free player space, like a battlefield in an FPS game. But this was a player-turn board game. Iterations I made on designs didn't focus on maintaining the experience through that lens, and so my iterations always had some flaw attached to them.

Iterations were made off of playtest data gathered from surveys, playtesters responses and remarks during playtesting and moderator observations.

ITERATING ON THE RULEBOOK

Iterating the rulebook was tricky. It's our way of communicating to the player on how exactly they should play the game. I learned a lot about player expectations through reactions on our rulebook.

Players never want to read. Even if said reading is necessary to play the game. That rule is more forgivable on the player's part when it comes to board games, but it's still there.

Words need to be precise. Many times throughout my playtests players would debate with each other on what rules meant, and the wording of rules I've written down could mean multiple things. I learned how to be clear in my definitions, use no jargon and to use as little words as possible.

It was always a point of reflection on how well I understood the rules of the game myself, when iterating on the rulebook. I enjoyed rewording rules and developing a deeper understanding of the mechanics and systems I didn't design within our game function. 

It's also important to make the Rulebook easy to reference. Having pages that list components, or list the rules of all Weapon Cards helps onboard the player in understanding the mechanics and systems within the game.

DEFINITIONS THROUGH ITERATION

I learned that iterating with a goal in mind is not the only viable form of iteration, despite the warnings I've heeded earlier. There were times throughout development where blind iterations lead to better mechanics.

Juice Tokens are power ups you can pick up on the board to use special weapon abilities. The players have to actively spawn these on the board every 4 turns. Our original design had players randomly increase 4 separate bars through increments. It was always annoying for players to keep track of the bars.

It was later iterated to have Juice Token spawns be determined by random card pulls. It achieved the same effect without overloading players' brains.

Juice Tokens were easy to grab to use in killing other players. Players would set up Juice Camps and spam Special Abilities, overpowering other players. In order to stop unfair play, we made some abilities cost extra Juice Tokens and had Juice Blocks preventing the collection of further Juice Tokens.

Players had to collect enough Fuel Tokens or kill another player to remove Juice Blocks. This created an experience where Juice Tokens are now something players can built up to and introduces more strategies onto the board.