In the beginning...

We as a team decided that we wanted a multiplayer puzzle game; but what might the idea be? Well, that was the complication. First, we thought of playing with sound, then I stumbled upon this post and presented it to the team. This became the inspiration to our serious topic, colorblindness. We kept asking the same question, how do we incorporate colorblindness into a core game mechanic. Well, with some light research we hammered down on an idea; simple colorblind filters. With a lack of pigment perception on the screen, we could directly inhibit the players by making the puzzles appear to rely on color. Now, we just had to come up with a few different puzzles with hidden clues within each level.

Goals: 

1. Teach a meaningful lesson regarding an educational and/or serious topic for any target audience in K-12.

2. Design a game around said lesson using the MDA formula.

3. Develop a cooperative and engaging, yet not frustrating, experience.

4. Create an environment that encourages players to learn & grow.

Game Idea: 

Work together with a partner to solve a gauntlet of puzzles in this serious toned visual escapade. In each room, neither player will have access to the full picture; instead, one player will have the puzzle, and the other will have the solution. The challenge comes from how well the two players can communicate without being able to see one another's screens. Trust and listening will be the only way to see clearly.

Contributions

Player Controller:

I implemented a first-person character controller tied to a 3D Character for the other player's perception. Since we wanted the game to be played in a sort of scientific manner, it was easy to default to Local Multiplayer, meaning I just had to have an external way of tying controller input to the player controller itself. Implementing this in Unity is usually considered a time-consuming or daunting task, luckily with the plugin InControl, they take care of the controller input management within Unity, which allowed me to create a Player Input base script and assign controller buttons to them via event triggers. This process made it extremely reliable and portable for different platforms, as well as allowing for much easier duplication and variation of the base player controller for local multiplayer gameplay. 

For our perfect situation, we wanted both players to be playing locally with one another, but also not be able to see one another's screens. For this to happen I had to figure out in Unity how to do that with as little complications as possible. Fortunately, assigning the target monitor worked for the most part, but there were major render order complications, that of which we wrote a small script to fix the render order on certain game objects when within view of the player on the second monitor.

Code Snippets:

After 3 weeks of raw development and gameplay iteration, our team had what we thought was a complete game. Upon the arrival of our third week of development, we noticed after our weekly presentation and playtesting that players were not engaged and had trouble understand the contextual clues and controls. In a last-minute effort to make a game turn from a sandbox of mechanics to an engaging experience, I created Patricia. She's everything your everyday experimental lab needs in an assistant, and more.

First I found a nice looking orb model from the Asset Store. Then I made a small talking script that flashed the lights emitting from Patricia's orb. I wrote a plethora of voice lines for her to say, some condescendingly playful, others direct tutorials. In an attempt to make it more immersive I recorded Google Translate saying each of the voice lines, took those recordings into Audacity, and whipped up a little distortion AI robot magic, thus birthing the complete version of Patricia.

Week 4 of presentations and playtesting came around, for us to receive astounding feedback on how much more Patricia guided the players. Adding a fun interactive element to keep them interested and engaged proved to fill in a gap that we had missing before. In total each level has at least 1 unique voice line while re-using the quippy voice lines to keep her casually commenting. The rate at which she spoke and seeding of what she would speak were parameters we could easily tweak.

During development, I found that Patricia (the AI robot assistant) would get in the way of the player more often than not with a simple follow script. So to put some checks on that, the collision between the player and the AI is toggled off as this was an unnecessary expense that was more detrimental than not. Furthermore, I wrote a script that controlled it's movement to adapt to the player's current state. As the player is moving, Patricia follows a target slightly above and behind the player to avoid being in the way. When the player is idle, Patricia follows a point slightly above and in the view of the player perching there when the destination is reached. This is helpful when she is telling tips and the player has found themselves standing still thinking, as I found it was easy for the AI to get lost and become irrelevant. Each player each has their own assistant helping them out.

Interactive UI:

Since there were five different group members we had to split the work up fairly. Since I was already developing all of the player controls and most of the interactions, it made sense for me to also take care of any interactive UI we may have. Originally we had gone with just a normal cursor, a two-pixel outline of an ellipse. After our first round of playtesting, I noticed the players weren't processing how each of the interactions were going to behave before interacting with them. While there were plenty of routes we could have gone, I wanted to keep the teamwork between the two players at a maximum by trying not to hold their hands too much. So in replacement of tutorializing every gameplay element, I attempted to make a contextual UI system for when the player interacts with interactables. 

To complete this task, I made the Interactable.cs script that would act as a base for all interactables in the game. This allowed for plenty of extra capabilities on the interactables like changing the reticle contextually, or having each interactable have it's own nested logic with inherited base logic, the usual polymorphic behavior system. This system was entirely event based on the input and the current perceived interactable.

Reticle Varieties in action:

Outcome

Zared Redding © 2019