From last week’s playtest, we found some hidden issues we hadn’t noticed before. One of the biggest issues is that the object-based puzzle nodes are too flexible so that different playtesters were using it in different ways. This issue is not only hard for the computer to compile but also shows the lack of guidance makes the playtesters all understand differently. To deal with this problem, we would like to work out a more formatted solution that can, to some degree, guide the user to compose the puzzles. That is why we have our progressive puzzle module solution this week.

Progressive Puzzle Modules

The basic idea of progressive puzzle modules is to re-focus on our definition of puzzles and to simplify either the puzzle building process and the puzzle node itself. As shown in the video last week, the object-based puzzle node solution requires quite a lot of space. Both the client and our instructors suggest us to combine the nodes together as a single unit. At first, we were a little bit reluctant to do so, because as a team of almost all programmers, we didn’t want to lose the degree of freedom and flexibility.

After re-considering about what exactly flexibility we are losing if we get rid of the basic object-based nodes, we really couldn’t find much. So, maybe it is a good time to say goodbye to the object nodes! Here comes another problem: if we are putting everything into one single node, how the user can easily pick up the option they want? We simulated our process when building the puzzles as well as tried other tools like Quest, and we found that if the puzzles are following a specific pattern, then most of us usually compose the puzzle step by step in that pattern. Thanks to a video about creating puzzles in adventure games shared by Jesse Schell and the article about puzzle patterns, we figured it out!

As mentioned in previous posts, our pattern of a puzzle is an objective and a solution. When the player is playing the adventure game, he will need to open a door (the solution) and then get to another room (the objective) through it. Designing an adventure game is different. The game designer needs to place the rooms first (the object) and then place the door. With that door, the designers can add some variations to it. They can lock the door with a key, or guard the door with a character.

Our progressive puzzle modules solution is basically mimicking this process. Instead of showing all the options all at once, we only show them the option they need to consider right now. First, the game designers need to choose what is their goal.

Then, the next step is to choose the solution: how can the player get to the airport?

After choosing the solution, a basic puzzle is done, which is to click an arrow and get to the airport. We can also add more challenges to this puzzle. For example, the arrow will not appear unless the player triggers a switch beforehand. In order to do that, our progressive puzzle modules provide the game designers some more choices.

This is the latest plan we have this week and we have scheduled another playtest in a middle school with our target audience next week. We are all very excited to see how well this solution works!