On Friday September 14th we tested out a “paper prototype” using an ingenious system devised by our level designer, Jaewan Park. What follows is his description of the prototype and the playtest itself. -Brad

Main Screen – Transparent Acrylic

We used a transparent acrylic board as the main screen. On the back of the board I drew a map with a marker, and on the other side I hid the map with post-its so that players cannot see the entire map at the beginning.

Dungeon map version 1 (36×28)

Before we playtested, I got feedback from Rich [Hilleman] that the map is probably too large for a two-minute experience. So I scaled it down to about a quarter of the original map size.

Dungeon map version 2 (19×15)

As gamemaster, I move paper characters manually on the back side of the board. The players don’t see their characters on the front unless they have a torch, in which case I move the post-its to reveal that part of the map.

Individual Screen – Workstation with Photoshop
The players each had an individual workstation to control their characters. I placed two layers in Photoshop.

First, I placed a photo the dungeon map.

Second, I put a fake cell phone mask on top of the map layer.

The player can control the map layer using the arrow keys on the keyboard, allowing them to simulate movement through the maze. We played the prototype as a turn-based game, and whenever each player moved their character I (as game master) would update the main screen as well.

Jaewan operates the “TV”

Objectives

My goals with the paper prototype were:

  1. First, to design a map in a short amount of time.
  2. Second, to let us iterate quickly and solve problems through iteration.
  3. Third, I expected the total time of the paper prototype test would be about eight times more than a digital prototype. We used this assumption to estimate how long it would take players to find one another and advance to the boss room.

I was able to design the map quickly because I did not rely on any other technology, so I only focused on the design. It was easy to iterate with the paper prototype, but it had the disadvantage that it took a very long time to finish a playtest. Therefore, we are moving on to digital prototyping because that technology is almost ready.

Romain ponders his next move.


I was proud of my own work on this prototype because I’ve never made a paper prototype before so this was unknown territory. I learned a lot about map design in a short amount of time.

Playtest Results

Here are some notes from our playtest:

Round 0 – Rich points out that the map is too big. We redesign the map.

Round 1 – We have four playtesters. Failure. Players spent five minutes wandering around before I discovered a problem with the map – it needed to be mirrored on the computers, since the players were seeing the back of the acrylic screen instead of the front. We took a break and I corrected the problem.

Round 2 – We have three players, and corrected the flipped-board issue. Having no torch makes people frustrated. Players spent about five minutes and they did not find any treasure boxes at all. There were 10 treasure boxes on the board, but it still took a long time. We take a break and I updated the map so that all players are guaranteed to find an item within their first few steps.

Round 3 – One person playtest. Bang! The player found the boss room in 8 moves. What?

Round 4 – Two players, on a fixed map. The players were given one torch at the beginning of the game and asked to find each other. They looked at the main screen (acrylic board) right away and checked back frequently. They reported the experience was interesting.

General feedback

  • Sometimes it is frustrating because we have to wait a long time between turns, and it feels like there are not many options of different paths to follow.
  • Maybe having rooms instead of just hallways would give more variation to players in the dungeon.
  • On the other hand, maybe we should just consider changing the number of intersections in our maze to adjust its difficulty/variety.
  • It takes too much time to move with the paper prototype, which makes it hard to judge how much time the overall game will take.

The team playtesting together.


Neerav, Brian, and Romain test our digital prototype using various mobile devices and a laptop connected to a TV. Good job Romain and Neerav!
Photo © Jaewan Park.

Team BarrelEye testing our paper prototype.

Some weeks, it feels like you spend more time talking about your game than building it. Team BarrelEye experienced that feeling this week as we prepared a design presentation hot on the heels of our pitch. Everybody has a hand in preparing our presentations, which takes time – we hope to use the slides we have created to quickly template future presentations.

Monday was full of planning. Our engineers met to discuss the game’s architecture, consider the challenges we are most likely to encounter down the road, and prepare a list of tasks they need to complete over the next two weeks. There were also a couple of design meetings to clarify details that we had to include in our Wednesday presentation. Over lunch we shared some of our experiences so far with West-Turn and agreed to meet later to share playtest results. We also had individual advisor meetings and, bit-by-bit, performed our first Scrum pulldown to begin our first official sprint. Tuesday and Wednesday flew by as art and production prepared for the presentation, and engineering started a prototype.

Wednesday afternoon we presented to eight members of the OCCO team, along with our advisors. We shared our research, describing a few of the games we are drawing from. We gave a more complete overview of our design, specifically focusing on the core game loop to find the fun as soon as possible. Finally, we presented our playtesting plan for the next two weeks. Our goal is to test a paper prototype on Friday of this week, and to begin a Unity prototype that will be networked for internal testing on Tuesday. On Friday the 21st we will invite the other ETC teams to help us playtest that prototype, so that at Quarters on the 26th (also our next OCCO milestone) we can present playtesting results, a revised design, and a roadmap to alpha.

The OCCO team provided us with great feedback, and revealed some ways that they will guide us as we proceed with the project. They were very interested in how we can make the game work for a trade show setting, from making the TV screen attract attention, to designing a multiplayer game that can be demoed to a single guest. After our meeting we had smaller conversations that lent further insight into our design. We were also asked to turn this presentation into a video, and future presentations as well – we’ve found it’s a great tool to make our presentations clear and direct.

Jaewan controls the “TV” during our playtest.

On Thursday and Friday we were happy to spend time with John Dessler, who is visiting from Pittsburgh for a few days. He gave a workshop on brainstorming and the creative process, and also took time to sit down with our team and talk about our project. John helped us anticipate some of the hardest challenges we will come across this semester, both from a product perspective and from a teamwork perspective. Thanks John!

By the end of the week we finished our paper playtest and had an early prototype running on a phone, so we feel good about our current progress. We also had our short weekly update with Ben, and we continue to struggle with a few IT issues but for the most part it’s not slowing us down.

Even in a week of talking (and listening!) we’ve found that with good teamwork we can get work done. Better, we can learn to take advantage of valuable feedback from the talented people that surround us to make our game better than we originally imagined. Next week we have no major presentation so our focus will be on prototyping and playtesting, continuing to actively seek that feedback from our teachers, clients, and peers. Expect great things from team BarrelEye!

 

NEWSLETTER #3 PDF FORMAT – DOWNLOAD