For my undergraduate senior capstone, my partner Alvin and I were given the freedom to pursue any kind of passion project under the guidance of a faculty professor. We were always passionate about exploring augmented reality (AR) technologies and video games, and as a duo we thought it would be exciting to design something collaborative.

We designed and built Don't Panic!, a collaborative AR game pilot that requires two players to rely on partial information and verbal communication in order to beat the game.

My role mainly involved using Unity and C# to design AR interactions, controls, and game logic. I was also responsible for visual and sound design.

Alvin Jeong, Andrew Tang

10 Weeks

Unity 3D, Xcode, Vuforia, Photon

Our journey started with an initial brainstorm of areas in which AR hasn’t been really explored yet. Our list ended up being mostly of our favorite video games, what we liked about them, and their potential in AR. We really enjoyed some of the hecticness that these games brought in terms of gameplay. Because we were partners working together, we thought it could be interesting to explore collaborative augmented reality.

Fresh off of finishing It Take Two, one of the best collaborative video games we’ve ever played, our design challenge became:

We started to brainstorm collaborative ideas, eventually landing on an idea we called “AR Dodging”, in which we imagined ourselves having to physically work together to dodge virtual objects in space. However, after consulting with the team running our design exhibition, space was limited, and we condensed this idea into a tabletop game in which two players control balls to dodge lasers.

To add a bit of challenge, we took inspiration from game mechanics in games like Keep Talking & Nobody Explodes, where each party of players have different clues and have to communicate together to fill in the blanks. So, our concept became a game where two players control balls to dodge lasers in a grid with the catch that each player only knows where half of the lasers are going to show up.

With this game concept, we had to answer two very important questions:

We took these two questions and tried to answer them through our own research. To answer the question of "why AR?", we sought to explore what the future of games looked like with emerging technologies. How could we take the experience of traditional tabletop games in physical space and translate them into a digital one? We hoped to answer this through experimentation of our game with other people and get their thoughts.

For the second question, we did desk research. We recruited one game developer and seven participants who play collaborative games and asked them what makes these games fun to them. At it's core, collaborative games are fun because it requires both players to put trust in each other and share a commitment in a constrained, fast-paced environment.

So we put this to the test. We wanted to design our game with the focus on delivering a fast-paced experience and commitment-based gameplay. We did this through first creating an analog version of our game and conducted different time-based tests with participants to gauge game pace, communication style, and difficulty.

We did one test where we gave them clues of where lasers would be and 10 seconds to talk to each other to place their balls in a safe zone, using any communication means necessary.

‍On the other hand, we did another test where we gave no time limit, but could only communicate verbally.

‍From these tests, we really enjoyed the time constrained tests because it promoted more fast-paced hecticness, communication, and level pacing.

Knowing the style of gameplay we wanted, my partner and I moved into development. Because we hoped for the game to be playable, our design process ended up being flipped. We had to design based on what we could build. We coded the game in Unity, and for every new part of the game we built, we had to test with participants to design the experience elements for them.

We wanted depth of field to be a constraining mechanic of the game, so we purposely made it a bit difficult for players to see which cube their balls were in and where lasers were going to hit to encourage players to look around and shift their position to see and communicate. This also added to the fast-paced nature of the game as it required players to rapidly look around for clues.

We showed our prototypes to participants to get feedback on visual clarity. Some participants stressed that perhaps it was maybe a little bit too hard to see exactly where objects were. To fix this, we updated our design to use light as a way to better indicate clarity of lasers to make up for the lack of depth.

Originally we wanted to involve hand tracking so that players could move objects with their actual hands. However, tests showed that this was constraining because players felt awkward holding iPads with only one hand while trying to keep their other hand in frame to move objects. Also, we ran into a bunch of bugs trying to implement hand tracking so we had to scrap the idea and go with more traditional button layouts.

Multiplayer was something that we were stuck on for quite a bit and it wasn’t until the very end when we could spend time making the UI look better because we were so focused on getting it to work. We were consistently using the native Unity UI templates and in feedback sessions our professor mentioned updating the UI before releasing it to the public. Our Menu UI was based off of our actual game board, incorporating the colors of the balls and the dark grey bottom playing field.

We treated our AR game as kind of a transition into a new medium, and wanted to pay homage to retro games. Game sounds were crafted and designed to mimic 8-bit sounds, and I created these sounds in FL Studio and Serum.

Once we had a working version of the game, we had participants try it out. While they enjoyed the game, they weren’t exactly sure how the game worked unless we told them specifically. From this feedback, we aimed to try to create a tutorial experience before players played the game, but at this point there was only about a few days left until the show, meaning that whatever instructions we created could not be tested before putting it out there. In the future, this is something we want to address earlier in later projects but we were blocked by the amount of time it took to code the game.

This issue was also present at the design exhibition itself. While the game experience was fun for many people, we realized by watching that many people were confused on how to start the game and my partner and I realized that we did not spend enough time designing an easy onboarding experience.

I also remember on the second reception night the game actually broke so my partner and I ended up spending a couple hours fixing the game during the actual show. I felt so bad because I had invited many friends over to try the game but it wasn’t working.

From this we learned that a good game needs a good tutorial and strong testing, and that is something that my partner and I are looking forward to addressing as we polish the game up.