On the second day of development, our team decided to immediately test the game to see if it worked. We created a simple board with a grid of squares and used sticky notes as tiles to build a line. We quickly saw potential but realized the game needed more, such as sabotage abilities, to stay engaging. Here's why our process of rapid prototyping worked for us:

• Short length of the game allowed us to modify small parts and quickly play to test it
• Played 10-15 variations in the first week, taking brief notes after each round
• Hands-on approach helped us make decisions based on gameplay not theory
• Quick evolution then allowed more time for external playtesting and building a real board later on

Many of our iterations were to try and solve our one main problem of players hoarding Rotate cards, effectively making each game too predictable. Eventually we settled on each player having four cards in their hand that they must play before getting a new set. But, before this we experimented with various tweaks, such as:

• Adding bridges for crossing obstacles
• Allowing the player to discard cards each turn to play the one on top
• Forcing the player to discard one card each turn
• Switching the objective from the middle of the board to the edge of it
• Adding a new Action Card to allow players to swap hands when played

Writing the rulebook was a major part of my workload. This was challenging, as I hadn't done much technical writing before, and the iterative design process made the game seem simple in my head. Here's a breakdown of the main issues I encountered:

• Over-assumptions about player knowledge: My first draft assumed too much about what players should already know, leaving out critical information. Playtesting highlighted this issue.
• Too much information: After revising, I overcompensated by adding too much text. This made the rulebook overwhelming and discouraged players from reading it.
• Playtesting and feedback: A second round of playtesting with second-year students and feedback from Adam, our lecturer, revealed that the lengthy rulebook was still confusing.

To solve these issues, I:

• Focused on clear, concise lists (bullet points or numbered sections) for rules
• Added diagrams with captions next to corresponding text for better clarity
• Organized sections clearly, making each part easy to understand

While I didn't work on the art, I noticed how much it helped with clarity. It made it easier for players to see their stream, understand the game's objective, and properly place tiles on the board. Please see the PDF below of the rulebook if you would like!

I had a great time in this course! Before this, I had never made a physical board game or considered the process behind it. There's something special about having tangible components to interact with, rather than using a keyboard, mouse, or controller. Here's what I learned:

• Rapid prototyping is key, especially when your project can be quickly tested.
• Establishing strong pillars early makes later design decisions much easier.
• Open conversations and testing out ideas helped us resolve challenges quickly.
• Playtesting with peers revealed issues we hadn't noticed with gameplay or rules.
• No matter how good your game is, unclear rules ruin the experience.
• Game development often doesn't go smoothly, but we got lucky this time.
• Working in a group helped me refine ideas and clarify the project's scope.

Going forward, I'd only make minor tweaks for clarity, particularly with tile placement. Overall, we met all our goals, and I wouldn't change our process of ideation, rapid prototyping, iteration, and playtesting.