Real Al's Human Academy

Real Al's Human Academy, XR, Design, Games

Design Retrospective: Real Al's Humanity Academy #3: Crafting Game Mechanics

In this series of blog posts, I will talk about my process as a producer, designer, and programmer of Real Al’s Humanity Academy. I’ll discuss why I made the decisions I did in each of these roles to give readers a better idea of how I approach these disciplines. The intended audience of these posts are potential employers, collaborators, and/or fans of the game who want a more behind-the-scenes look.

In this post, I will discuss how our team designed the project’s game mechanics.


In the previous posts, I discussed why our team set out to make a VR party game and why we thought a minigame collection was the best fit for our team.

With our gameplay concept selected, we brainstormed individual gameplay mechanics. As in Warioware or Dumb Ways to Die, each minigame would be based around a simple mechanic. When the game progressed, the minigames would become increasingly complex and difficult.

The  Dumb Ways to Die  minigame collection was another source of inspiration for our game.

The Dumb Ways to Die minigame collection was another source of inspiration for our game.

A core principle that we kept in mind throughout this process was to design every minigame for VR and only VR. At that time, there were many VR titles on the market that were essentially 2D experiences shoehorned into the medium. We wanted to make something that could only be experienced in VR and that utilized VR’s strengths, such as its physicality and 360 degree environments.

One of my favorite aspects of VR is its physicality. Like the Wii remotes before them, the HTC Vive’s motion controllers feel fantastic when you use them to perform physical tasks like swinging tennis rackets, boxing heavyweights, or climbing mountains. To brainstorm minigame ideas, I would grab a Vive controller and play with it like a toy until I found a motion that I found satisfying. Then, I would try to spin this action in a surprising way. For our “Bounce the Eggs” minigame, I first started with the motion of hitting a tennis ball. At that point, I prototyped surreal variants of this action, like the balls transforming into balloons on impact or the balls shooting out from the floor. Somehow, we arrived at eggs falling from the sky in a supermarket.

Our “Bounce the Eggs” minigame in action.

Our “Bounce the Eggs” minigame in action.

Another aspect of VR that I loved was the fact you could build a game all around the player. There’s something magical about turning around while in VR and finding a whole new side of the environment for you to explore. We applied this thinking to our game by designing every minigame so that you had to turn around and explore your environment to win.

Early in my time at NYU, I went to a VR masterclass that had Saschka Unseld, the director of Oculus Story Studio, in attendance. He said:

Film is about showing, not telling.

VR is about discovering, not showing.

I found this statement to be true in my time as a VR consumer and we tried to apply this paradigm to our design of the minigames. Imagine that each level is divided into a north, east, south, and west quadrant. Whenever it was possible, we tried to put a compelling and unique gameplay or art element in each quadrant so that the player would always feel rewarded when they turned around.

The “Grab the Numbers” minigame forced players to turn around because the numbers they needed were sometimes behind them.

The “Grab the Numbers” minigame forced players to turn around because the numbers they needed were sometimes behind them.

I loved this phase of production because our team had the chance to experiment. We made minigames where you popped balloons, smashed computers, played blackjack with floating cards, and dodged evil bees.

To externally validate these designs, we were constantly playtesting our ideas. In order to expedite playtesting, I would parameterize the settings of the various minigames and then have playtesters try variants of the same minigame one after the other until they felt just right. For the egg bouncing minigame, I would modify the eggs’ speed, size, color, and sound effects until every bounce felt satisfying and fair. This method of iteration was one of my favorite parts of the process.

Sometimes, the minigames would get stuck even after several rounds of tweaking. When this happened, we’d review our playtest notes for a diagnosis. Most of the time, the issue was that the minigame was too complicated to understand in five seconds. When this happened, we identified the best part of the minigame and simplified or eliminated the rest. In one case, we had a minigame in which you had to use a flashlight to find a lever in the dark and then pull that lever. Playtesters didn’t like the minigame, but they did like the flashlight, so we kept the flashlight and redesigned the game around finding ghosts in a dark room.

Players loved our flashlight mechanic, but not the rest of the minigame, so we kept the flashlights and ditched the rest. To make the flashlights even more rewarding, we added about forty unique images to the walls of the flashlight level so that players would be encouraged to explore the room.

Players loved our flashlight mechanic, but not the rest of the minigame, so we kept the flashlights and ditched the rest. To make the flashlights even more rewarding, we added about forty unique images to the walls of the flashlight level so that players would be encouraged to explore the room.

When designing minigames, we found that a few guidelines generally held true. We measured our minigames’ success by two simple metrics: A) Did they want to play again? B) Did they say they liked the game? In general, we listened to “A” a lot more than “B!”

  1. Simpler minigames performed better. Every minigame that required two phases ultimately became a one phase game.

  2. Minigames that heavily utilized motion controllers performed better.

  3. Minigames that gave dramatic reactions to the player’s actions performed better, regardless of whether the player won or loss. [For most players, a dramatic failure is more satisfying than a tepid victory.]

  4. Minigames that forced the player to utilize all 360 degrees of an environment performed better.

  5. Minigames that asked the player to simply touch an object were not as satisfying as minigames that required “bigger” actions like swinging, punching, or throwing.

  6. For most players, the game felt well balanced and fair when they won about 75% of the minigames in the first round and won about 50% in the later rounds.

  7. Players appreciated failure the most when they could clearly see how close they were to success. I think the egg game was popular in part to the fact that you could clearly see how many eggs were left to bounce at any given time. On other hand, I felt that the ghost game was sometimes unsatisfying because you could easily feel like you had made no progress if you didn’t spot any ghosts.

A progress bar from the amazing  Cuphead.  Players love to see how close they are to success.

A progress bar from the amazing Cuphead. Players love to see how close they are to success.

At this point, we kept the game’s art and theming to a minimum. We wanted to to communicate the game’s general tone, but we did not want to finalize art assets until we knew that our game mechanics were solid. In general, we thought it would be easier to create a story around a set of mechanics than vice versa. I also didn’t want our team’s artists to spend time building assets for a mechanic that would ultimately be cut.

We knew from playtests that many players enjoyed taking turns playing the game with their friends. While this was great, we needed to give players a reason to invite others to play the game with them, so we implemented a simple local high score system. Putting a leaderboard in a game can awaken players’ competitive spirits; we found that most players would do an additional playthrough if they were aware of the leaderboard and were in the presence of their friends.

The final big test of our game’s mechanics that semester was the NYU Game Center’s biannual show. This was an important show for us because the show often had professional game designers in attendance.

The NYU Game Center, where this game was first designed.

The NYU Game Center, where this game was first designed.

Thankfully, the game was well received; several people even said the game was terrific. Most importantly, the game seemed to achieve its stated mission: it thrived in the show’s party-like atmosphere. Many people would first play the game individually then challenge their friends to beat their high scores. For me, this was a profound moment. We had built the foundation of a solid VR party game.

However, there was still significant work to do; the minigames needed refinement and the game lacked a theme. In my next post, I will discuss how I wrote the game’s script and how our team approached the game’s art.

Enjoyed this blog post?

Subscribe below for more dev blogs and news delivered to your inbox.

* indicates required

XR, Design, Real Al's Human Academy

Design Retrospective: Real Al's Humanity Academy #2: Choosing an Idea

In this series of blog posts, I will talk about my process as a producer, designer, and programmer of Real Al’s Humanity Academy. I’ll discuss why I made the decisions I did in each of these roles to give readers a better idea of how I approach these disciplines. The intended audience of these posts are potential employers, collaborators, and/or fans of the game who want a more behind-the-scenes look.

In this post, I will discuss why our team chose to make a minigame collection given our stated mission.


In my previous post, I discussed the mission that guided this project, which was:

Make a VR game that people would want at their party.

With this goal in place, I started recruiting people who felt as passionate as I did about making VR games less isolating. I reached out to Keanan Pucci and Matthew Ricci because they were some of the hardest working people in my VR production class and seemed equally invested in solving this isolation issue.

Once our developer and designer team was in place, we started brainstorming ideas to achieve our goal. We decided that we would each bring five gameplay ideas and five theme ideas to our meetings until we found an idea we all believed in. I personally set aside twenty-five to fifty minutes a day to brainstorm ideas so that I was always bringing my best ideas to the group meetings.

We analyzed these ideas with a lens similar to the “Hedgehog Concept” mentioned in Jim Collins‘s book, Good to Great. Essentially, we asked ourselves three questions:

1) If we sold this game, would other people want to buy it?

2) Could we make a version of this game that was competitive with similar games on Steam?

3) Are we passionate about this idea?

If the answer to all these questions was yes, we would go forward with the idea.

HedgeHog_Concept.png

Between the three of us, “Warioware in VR” was our favorite idea, so we tested that idea first. If you’re not familiar with Warioware, it is a fast-paced casual game in which players compete to complete as many five to ten second minigames as they can. In the minigame pictured below, you are given five seconds to slap Wario and wake him up.

WarioWare_Slap.gif

To answer question number one, we pitched our game to anyone who would listen and gauged their reaction. The game was easy to pitch and most people seemed enthusiastic about the idea. For question two, we spent significant time looking through Steam and Itch.io for similar games. There were one or two Warioware-like VR games, but they were either buggy or bland; we felt that we could do better. It was clear our whole team was excited about the idea, so we decided to move into planning the project.

The Warioware concept had other game development-specific advantages to it. For one, it was modular: a minigame could fail in production and the rest of the project would be fine. This modular design gave us the flexibility to pursue three minigames if things were going slowly and ten if they were going quickly. If we had instead made a narrative game, we would have to commit to finishing every chapter or the experience would be incomplete. Some members of the team were relatively new to VR development, so this modular paradigm helped diffuse production risk.

The other advantage to the Warioware concept was that it gave us room to experiment with a variety of art styles. If you have played Warioware, you’ll know that each of its minigames has its own unique look: there are games rendered in claymation, 3D animation, acrylic paint, watercolor, and more. Warioware’s art is not always the most realistic or technically polished, but it makes up for this with visual inventiveness and humor. We knew our team couldn’t afford to create naturalistic animations like in AAA VR experiences like Henry or Robo Recall, so we decided to also aim for humor and inventiveness in our art rather than technical polish. You can find some images from our initial moodboard below:

Now that we had our core gameplay paradigm in place, it was time to brainstorm our mechanics.

Enjoyed this blog post?

Subscribe below for more dev blogs and news delivered to your inbox.

* indicates required

XR, Design, Real Al's Human Academy

Design Retrospective: Real Al's Humanity Academy #1: Finding Purpose

In this series of blog posts, I will talk about my process as a producer, designer, and programmer of Real Al’s Humanity Academy. I’ll discuss why I made the decisions I did in each of these roles to give readers a better idea of how I approach these disciplines. The intended audience of these posts are potential employers, collaborators, and/or fans of the game who want a more behind-the-scenes look.