The Real Deal

Assignment: Create a game using features of a mobile device.

Role: Mechanics Designer and Gameplay Tester

Engine/Tools Used: Unity, Adobe XD, Git, DOTween

Team Size: 7

Development Time: 3 weeks

Overview

The Real Deal is a cooperative party game where you play for the high score by communicating with your teammates and finding out which object is The Real Deal. Every player sees the same object but one player is looking at something with a very slight difference. talk (or yell) to your friends about what you’re seeing and if you find out you’re seeing something different from your teammates, report the item as a fake!

I was responsible for prototyping and testing the core game loop and improving game feel and experience. I took this chance to improve my paper prototype testing and learn how to use DOTween for smooth animations in-game.

Design goals

Create an engaging party game that has people on the edge of their seats talking to each other.
Create puzzles that give players opportunity to strategize in how to solve them using communication.
Learn how to create easy animations within Unity.
Explore what challenges would arise when working with a mobile device.
Try using more “by the book” design methods.

Personal contributions

Paper prototyped all game mechanics and tested them with peers extensively.
Analysing results and documenting suggestions.
Designed and tested different game modes and explored whether they were viable paths for us to take.
Implemented simple animations.
Extensive bug testing and bug reporting.
Puzzle design and prototyping.

Process

At the start of the project we first listed our skills and communicated what we wanted to work with, so we could keep track of everyone’s wishes. After we got that out of the way we started brainstorming several ideas each, writing our top 6 on a whiteboard along with pros and cons.
After weighing these out, we were left with only 3 concepts, for each of which we made a paper prototype to test. On day 2, we tested each of them and The Real Deal was the winner.

The paper prototype was still used several times after to create different types of puzzles. Because our concept was fun for its simplicity, we decided to go for quantity in our puzzles so there’s no high repetition. This meant we had to do a lot more paper prototyping throughout the project.

I made a big point of analysing my results using the methods we learned in school, making use of the Flow state and of fun, curiosity, and surprise.

After the bulk of the design work was done, I helped out the engineers and artists by taking the animation work off their hands. I learned DOTween, preventing objects from just blinking into existence.

The last week was spent mostly bugfixing and user testing. I extensively tested the game with multiple devices and reported any bug I found, explaining where it came from, how to replicate it, and how high it is on the list of priorities.

I managed to fix some bugs myself, and our engineers were able to fix the remainder of them.

After that, all that was left for us was to practice the pitch!

Outcome

Because we focused on making a simple game rather than a complicated one, we were able to put a lot more emphasis on polish, bug-fixing and user testing. I wouldn’t say it’s better or worse than the workflow of making a more complex game, but it definitely taught me more about the later stages of development.

We did bite off more than we could chew in the area of AR though, it proved a lot more difficult than expected to have an object appear in real space, and we were not able to have AR present and functional in the final product.

I’m especially proud of our team that we managed to think of an original game without having to make it overcomplicated and convoluted, the game was fun to play even though it was missing a couple assets and features.

In the end, I learned a lot about how to efficiently bug-report and fix, and picked up the new skill of using DOTween!