After the playtest last Friday, this week we kept on adding new features into the tool to support more puzzles. Also, based on the result of last playtest, we talked with our instructor Dave and re-organized all the puzzle options to make them more cohesive internally. On Saturday, we playtested with our target audience on ETC playtest day to assess our progress.

The Sprint

In this week’s sprint, our goal was to make the tool support container puzzles and enhance the usability so that it can be used by our target audience (middle schoolers) on Saturday’s ETC playtest day. Thus, the focus of this sprint is:

• Fix the issues we found during last playtest
  • Organize the puzzle options to make them easier to understand
  • Enhance the usability of the world builder and the puzzle editor
• Add interactions to set containers in the world builder

After this sprint, the tool now supports a larger range of puzzles:

• Get an item from a container
• Get an item from a container locked by a key
• Get an item from a container locked by password
• Get an item from a container triggered by a switch
• Get an item by trading with NPC

Progressive Puzzle Module 2.0

In the previous version of the progressive puzzle, we had four puzzle goals: “go to a new scene”, “get an item”, “destroy an item” and “let somebody say something”. Under each goal, we provided some solution options for the user to choose how to achieve the goal. In a puzzle designer’s perspective, the solutions are the actions/verbs and the goals are the state changes. However, our design was not showing this “verb-state change” relation explicitly. We somehow maintained this structure implicitly. In fact, we ourselves didn’t realize it until Dave pointed that out.

This unconsciousness led to the result of the confusion of the playtesters. The “destroy an item” and the “let somebody say something” were misused very often. In our original design, “destroy an item” was only designed for monster battle (destroy the dragon with sword) at the end of the game. Same as the “let somebody say something” puzzle goal. However, in the playtest, the playtesters sometimes use the “let somebody say something” puzzle as a way to add a description of an object and use “destroy an item” to add items into the inventory (removing it from the scene).

The underlying reason for the misusing of the two puzzle goals is the inconsistency. The goals like “go to a new scene” and “get an item” have a state change that is depended by another puzzle. For example, “go to a new scene” changes the scene state, and all the puzzles in that scene depend on this state change. In contrast, “destroy an item” does nothing to other puzzles. It only serves for the end game and has no useful state change as a reward. This slight inconsistency might be the reason for the confusion happened in the playtest.

After setting up the goal and the solution of a puzzle, we ask the users if they would like to add a challenge to this puzzle. The challenges contain a “lock” challenge where the players need to find a key or input a password to unlock the object, a “guard” challenge where the players need to bribe the guard in this puzzle and a “switch” puzzle where the players need to operate a trigger first. However in the playtest, the playtesters sometimes confused the “lock” challenge with the “switch” challenge. After the meeting with Dave, we realized that we overlooked the fact that these two are both “locks” essentially. Actually, these three challenges are all locks, to some degree. The “lock” is a direct, internal lock of an object, the “guard” is a direct, external lock of an object and the “switch” is an indirect, external lock of it. Thus, instead of providing three “challenge” options, we were actually three “lock” options, while “lock” itself was one of the options. That’s why the playtesters felt frustrated in the playtest.

To address those issues, we re-organized all the puzzle options by thinking about the state changes and the verbs and collapsing some of the options. The “flow chart” of the updated puzzles is here. In this Saturday’s playtest, we would like to see how this updated progressive puzzle module design works.

The Playtest

On this Saturday, we hosted 6 groups of playtesters, aged from 8 to 15. The goal of this playtest is to find out if the reorganized progressive puzzle module works better than before and to find out more usability issues. Instead of directly providing a game to them, we were providing a game story to them. In the story, we tell the playtester how the scenes look like and how to solve all the puzzles, and then let them create this corresponding adventure game. The result of this playtest was quite successful: All of the playtesters managed to create the target game less than 30 minutes.

The playtesters loved the puzzle building process. They thought it was streamlined and straight-forward, but also exciting and fun. This means that our progressive puzzle module design 2.0 works better than the previous version. They also love the feeling of actually making something. One of the playtesters made more scenes after he finished our game, and was excited to share his own story to his friend. Another playtest thought it was his favorite project when asked by another project.

But still, the playtesters need more features. They also found some usability issues during the playtest:

• Needed features
  • Interact with characters (talk to characters)
  • Set win screen
  • Spawn something
  • Customize sound/message after puzzles completed

• There are some usability issues when building the game
  • All of them can choose the goal correctly, but some of them chose the wrong objects at first
  • Tutorial/hint about adding objects into containers
  • Some elements are not noticeable enough (like puzzle editor tab, object description, …)
  • And more…

Here is the example game made by our tool in this playtest: