In the past few weeks…

In Week 12, we said that we were adding the last few essential features and starting to focus more on usability and reliability. After Week 12, we started to fully focus on fixing bugs and improving usability. We made important contents more visible, we rearranged our art assets and we made more games. However, during halves, our faculty pointed out two important issues we hadn’t really addressed. The first problem was that in all of our playtest events, we were sitting next to the playtesters to help them. If the product was supposed to be used at home or in a museum setting, we haven’t proved that our target audience can use our tool to create their games without us hovering. The second problem was, for the potential museum setting, we might need a special version for that setting to protect the PC in the museum.

Thus, the main focus for the last few weeks was really about bringing our audience on board. To do that, we designed a series of tutorials with multiple levels. We started with making a very simple game and teaching the basic idea behind the puzzle building process. After the user get used to the puzzle building process, we gradually introduce more puzzles and more narratives into the tutorials. We recorded video and integrated it into our tool and on the web page.

We also scheduled a playtest at Manchester Academic Charter School to playtest our tutorial. We gave the playtesters the tool, the tutorial and thirty minutes to find out whether they can create their own adventure games without us. The result was, surprisingly, successful. Most of the playtesters succeeded in making their own games and they are really smart and creative in making games. We can definitely see the impact of our tutorial. (To try out their games, check this link)

Besides the tutorial, we also developed a museum-specific version of the tool and wrote documentation for handing off.

Now, we have…

Now, the semester has ended, and here are our deliverable:

1. A puzzle design system: it includes our core underlying game design concepts, state changes, verbs, and backward thinking.
2. A game creation tool: it is a cross-platform application on Windows, Linux and OS X.
3. A series of tutorials: it includes three video tutorials and their text instructions.
4. Hand-Off documentation: it is detailed documentation from both design and technical perspective

Our project is open-sourced on Github and you can see the building instructions on the readme page. To help understand the codebase, we also wrote about the technical documentation on the wiki. You can also download the final product in the release page (Windows version and OS X version)

To help understand our design and our process, we did a good job in our final presentation. Feel free to check out the video:

Next Steps

After the playtest in MACS, we are more and more confident with our product. It can truly teach some basic game design concepts and allow the middle schoolers to create their own games. It has its potential. However, because of the time limit, we still have several unimplemented features. We were focusing more on polishing the tool instead of adding more features in the late semester. Here are the features we would love to add to the tool if we have another semester with this project:

Tech TODOs:

• Make the editor responsive (it’s 1920×1080 now and not resizable)
• Make the editor web-based (required skill: webpack or parcel)

Design TODOs:

• Puzzle editor
  • Puzzle customization
    • Customize complete message
    • Customize sprite changes
    • Customize the winning screen
    • Customize failure message
  • More puzzles
    • Combining puzzles
    • Navigation puzzles
    • Conversation puzzles (distraction and convincing)
  • Puzzle card organization
    • Grouping
    • Showing dependencies
• Worldbuilder
  • Navigation (arrows or minimap)
  • Conversation
  • Imported audio preview
  • Imported image/audio deletion

The End of the Beginning

We do see the potential of this product and the whole K12 education area. The project has ended but the product has not. The first version is just its first cry. We really hope more people can work on this product or work on more K12 education projects. Just keep in mind, you will need tons of playtests to land your new features to the target audience.

The Sprint

Since this week is a short week with Spring Carnival and the semester is ending soon, we were no longer adding too many features to the tool. What we did is to add some essential features needed by the playtesters and to improve the usability once again.

The Focus

• Add more essential features
  • Talk to the character
  • Customize the sound effect after a puzzle is completed
  • Setting the winning condition
• Fix the usability issues we found in last Saturday’s playtest
  • Text clarity (remove the ambiguity of “which is” clause)
  • Visual hints (make tabs, object descriptions more noticeable and have visual aids to organize the puzzles)

The Result

New Features

For new features, we added the three major listed above. The player can now add the message that a character will tell you in the character’s attribute panel. Also, the player can have two optional edits to the puzzles: to make it as a winning condition or to add a completion sound effect to it. After setting a puzzle as the winning condition, when a player completes the puzzle, there will be a winning image overlaying the screen.

Usability Improvement

The usability improvements are mostly focusing on text clarification and visual hints as mentioned before. We slightly changed the wording in the puzzle builder and increased the font size. Also, we moved some important attributes like object description and conversation up, to a more visible position. Furthermore, our biggest change happened to puzzle cards. We re-colored it, optimized the word flow and marked the dependencies across puzzles.

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:

The Sprint

After halves, we had a discussion in the team to figure out what is the best way for the team to develop a project. Though the project is a design-heavy project, we have several programmers but no designers. We all believe that instead of having a design approved before development, developing the tool and iterating according to our daily use is a better way for our team. Thus, we changed our production mode to be more sprint-focused.

Focus

In this sprint, we were focusing on making a usable tool to create games with collecting, using and navigation. After the sprint, we would like to use the tool to find out whether the progressive puzzle design works in the digital form. More specifically, we would like to find out if the options in the progressive puzzle module meet the users’ expectation and they can select the right option with little confusion. Also, we would like to observe the user patterns when they are creating the game: what operation they would like to do in the tool but we cannot?

Assessment

To iterate on the tool, we were building our tool daily and using the latest build to create simple adventure games snippets. When using the tool, we made notes about the frustrating parts of the game creation process. Every morning, before the core hour, we had a quick meeting to view all the frustrations and prioritize them. Also, we planned a playtest inside ETC on Friday to see if naive users can use our tool.

The Playtest

In the playtest, we had 9 playtesters in total with multiple disciplines. During the playtest, we let the playtesters play the target game first to have an overview of the game they would build (let them have a game in mind). After that, we let the playtesters have the game and our tool opened side by side so that they can create the game and reference back if they need.

All of the playtesters managed to create the target game in around 30 minutes.

There are several things they love:

• The ability to build the puzzles step by step
• The feeling of dragging puzzles around
• The ability to experiment with the puzzles by previewing the game

Of course, there are something they feel frustrated:

• Playtesters need time to understand how puzzle making works
  • Usually, they use the first two rooms (puzzles) to experiment with the options and adjust their assumption
  • Once they figured out how it works, they can build the rest of the game fairly quickly
  • Some of the playtesters would like to see all the options before they choose anything
• There are some usability issues when building the game
  • Delete, undo features
  • Adding object descriptions
  • …

All of the feedback is definitely useful and we will keep on iterating our tool. In the end, here is the screen capture of one of the playtesters.

Development

In week 7, we managed to implement our MVP build, which is to remake the first airplane puzzle from Sabrina and Dave’s Adventure. With the completion of that MVP game, our tool was able to create an adventure game with our progressive puzzle builder. This week, we were expanding the puzzle support list from only supporting the exact puzzle in MVP game to supporting all puzzles without adding new features in the world builder.

The puzzles include:

• Get an item by collecting it in the scene
• Go to a location through an object
• Go to a location through an object locked by a key
• Go to a location through an object locked by password key
• Go to a location through an object triggered by a switch
• Remove an object by using an object on it

With those puzzles, we now have the basic features of a game creation tool, and it is able to create some simple adventure games like this:

Design

Besides development, we were also doing the design work for the tool. This week, we were designing the world builder. The main features of the world builder are:

• Decorating the scene
• Navigating between scenes
• Storytelling
  • Description
  • Narrative
  • Conversation

We were designing the look and the interactions in the world builder based on these features.

Decorating the scene

There are four types of objects can be added into the game, which are objects in the scene, objects in the container, objects held by a character and objects needed to be crafted. Interaction-wise, there are three interactions, one for adding the objects to the scene, one for adding the objects to a container or a character and one for setting up the recipe for the combining. Since the combining result does not belong to any scene, our first design is to have a recipe book which is like the rule book for the world where the user can set up how everything can be crafted.

Navigating between scenes

In a point-and-click adventure game, there are two ways to navigate between scenes: by clicking arrows (direct navigation) or by clicking specific objects (like doors or ladders, indirect navigation). We also designed two ways of setting up the navigation relation between two scenes.

Conversations

Adventure games are also about stories. We want the users to have different ways to tell their stories. There are three ways to tell stories: narratives (direct), object descriptions (indirect) and conversations with NPCs (indirect). For the first two, they can be the properties of the scene and the object, and for the conversation system, which was something we wanted to do at the beginning of the semester, we were now thinking about simplify it due to the schedule and the scope.

When you are using our tool to build your own game, in the crafting phase, the tool assumes that you know what is the game you are making and the puzzles in the game. You can then set up the scenes and the puzzles. However, for our target audience, they might not have a game in mind. Maybe they only have a story in mind and want to use our tool to create a game about that story. The inspiring phase is designed for them. It will bridge the gap and help them to form a game with a puzzle in their minds.

Because we are mostly focusing on the crafting phase, especially the puzzle building process, it is just an initial plan for the inspiring phase and we will have a further plan about it in the second half of the semester.

The MVP Target

The reason we are building an MVP demo varies. First, we need to get something to show in the halves presentation. All we had before are paper prototypes while they are not that suitable for the presentation. Second, we have struggled with design iterations for a long time (about 4 weeks). Maybe it’s a good time for us to take a break from that rabbit hole and do some programming. As suggested by our instructors, the MVP demo can really be minimal, since one of the goals of this demo is to make sure the technical pipeline works. They also suggested us to choose an existing point-and-click adventure game as our target, even for the final product.

With that in mind, we soon listed out three candidates and then decided to pick one among these three. The three candidates are all the first puzzle in the adventure game so they are all fairly simple, and the one we chose in the end is the first puzzle, the airplane puzzle, from Sabrina And Dave’s Adventure (SADA) made by our instructor Dave Culyba. We chose this puzzle as our target, not only because it was made by our instructor, but also this puzzle covers a lot of basic features our final product will cover:

• The ability to compose a puzzle with Goal-Solution-Challenge pattern (in this case is to go to the airport by clicking the arrow and to unlock the arrow by operating the call button).
• The ability to add a description to an object (the call button)
• The ability to add narrative to a scene (the radio in the beginning)

The World Builder

When we were creating our slide deck, we found we were focusing on the puzzles in the point-and-click adventure games too much. The adventure games are not only about puzzles. The game designers also need to tell a story in the game, mostly by building a virtual world. There are several things cannot be covered in the puzzle editor (since they are not puzzles at all!), such as descriptions of objects, narratives of scenes and conversations with characters. All of those should be involved in the scene editor.

Now the scene editor is more powerful than only placing different objects in the scenes, so we also upgraded its name to the world builder.

We didn’t have much time to develop how the users can use the world builder, while we can still show you an overview of the features of different editors and a sketch of the world builder.

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!

UI Design

Even we were going to have paper prototypes for this playtest, we definitely still need the interface designed. In last year’s Alice’s Adventure project, The scene editor, the library, the hierarchy, the interaction list and the interaction editor are all in the same window. Though it was straight-forward and showed everything in the first page (just like Unity and other game editors), there were several drawbacks: displaying different windows sections all at once is a little bit overwhelming and the scene editor window is too small for editing.

To solve these drawbacks, we decided to have different tabs for different features: one for scene editing and one for puzzle building. Since the hierarchy can be used for multiple purposes, it is shared by these two tabs. The initial interface is like this:

Clarifying Puzzle Nodes

We proposed the object-based puzzle nodes last week and this week we started to clarifying it. We started to finalized the initial list of all the object nodes and started to design the different options on each object (e.g.: the locks on the door and the guard of the container). Also, our client mentioned that we could also provide some templates for the users to quickly add some example puzzles. We were not that convinced at first but we still compiled a list of puzzle template which we planned to do AB test during the playtest to see which kind of nodes (object-based puzzle nodes or puzzle templates) the users love more.

Playtesting!

On Feb. 15, we held our first playtest inside of ETC! The goal is to test whether current object-based nodes have enough expression power and are intuitive enough. Also, we would like to know which plan is more preferred, the basic nodes or the premade templates.

11 ETC students and one faculty took part in this playtest and we got some interesting findings:

• Playtesters tend to use templates more while they prefer to keep both basic nodes and premade templates
• The puzzle nodes and scene decoration do need much space so multiple tabs are needed while the playtesters tend to switch a lot between tabs or some of them just ignore another tab
• The playtesters can use the nodes to compose puzzles while the wording and the user flow (like adding the sprite or attaching different nodes) should be improved.

These findings were super useful and there were still quite a lot design challenges to need to overcome!

Quarter’s Walkaround And Sitdown

During the presentation, we were clarifying what our project is, what our deliverables are and what our approaches are. Also, we were showing them how we will playtest our project and how our project differs from the last Alice Adventure project.

Project Description

• A continuation of the ETC Alice’s Adventure project
• Developing a 2D adventure game creation tool for people with little game design experience
• The secondary goal is to teach introductory game design concepts

Deliverables

• A point-and-click adventure game editor
• An engine supports adventure game features
• A game creation guide for naive game designers

Our Approaches

• Game-to-Engine Approach (more detail in previous blogs)
• Engine-to-Game Approach

Playtesting

• Target Audience: Middle schoolers
• Content
  • The usability of the game creation guide
  • The usability of the sandbox interface
  • The process of game creation guide

Differences

• Focus: from CS concept to game design concept
• Features: Navigation and story-telling
• Guide: Add a guide that helps game designers to create games by answering questions
• UI: Programming-centric to design-centric
• Platform: Windows only to cross-platform

Feedback

We got tons of feedback from our faculty, mainly from three perspectives: understanding demographics, being aware of the project management and some tips about puzzle design. For puzzle design, they recommended us to prepare some puzzle libraries so that the puzzles won’t be unsolvable. That was one of the great suggestions we got from the quarters and we started to iterate on our work based on that.

New Design Proposals

Though we had compiled a puzzle list on the weekends, after the quarters, we found that those puzzles were still too generic. Thus, we decided to specify those puzzles by providing specific puzzles like “go to X scene” puzzle. When working on that approach, we had two different ideas in our team. One idea is to consider an action like “Enter a scene from a door” as a node, which can be manipulated and connected by the user. Another idea is to consider a puzzle like “A door locked by a key” puzzle.

Action Nodes

Pros: The action nodes are quite intuitive. It acts like storytelling. “The player enters the room, unlocks a treasure box with a key and gets all the golds”. It’s very clear that there should be three actions: enter a scene, unlock a locked container and get items from unlocked containers.

Cons: However, it has some potential disadvantages, the result of one single action might be very fuzzy. For example, what is the result of talking to an NPC? To design this action, the user will inevitably add some temporal state as a result of an action. Back to the example above, the result of “talking” action can be the NPC is convinced (state). This kind of states are very abstract and hardly be mapped to the real-life experience, which makes the game design process hard to learn.

Puzzle Nodes

Pros: The puzzle nodes approach is rather a different one. Instead of providing action nodes, we provide puzzles. All the temporal states like “the door is unlocked” or “NPC is convinced” are encapsulated by the puzzle nodes like “Unlock a key-locked door” puzzle or “Trade with NPC” puzzle.

Cons: While it also has its own downside. When composing an adventure game with those puzzles, game designers might need to think backward. The puzzles related to winning condition will be made first and then propagate to the beginning scene.

Conclusion

By talking with our client and laying out some of the examples, we finally decided to stick to the second approach because it’s more beginner-friendly and easier to understand. Though the game designer needs to think differently, it is actually something we should teach the naive game designers!