Final Project Documentation - Let It Rain

Overview

Let It Rain is a mini game where one player must try to get away from a rain shower while a second player tries to make it rain on the first using the left and right arrow keys to control the rain.

The Making Of - Tracking a Person through Kinect

In class we'd gone over several Kinect examples - one created a particle system when the Kinect could find a person standing in front of it, and another was a riff on Pong where mini cubes would drop from the top of the screen and the player could control a paddle to catch the cubes with their shoulders. The first version of Let It Rain (Assignment 3) was a combination of these two examples. I replaced the paddle with the particle system human body before copying over all the components that had been attached to the paddle to this new skeleton particle system. I hypothesized that this would give me a result where the cubes would now bounce off the particle system. Instead I found that the cubes were dropping straight through the system. With Stacey's help, I removed the particle system component and instead attached a new cube prefab to the joints. 

<insert image here>

Once I had done that, I then attached a Box Collider component to the new prefab (SkeletonCube), which caused cubes to bounce off the joints. However, this lead to the skeleton rotating in a circle whenever a cube collided with it; the rotation would accelerate with each subsequent cube colliding with a joint. This was rectified by adding a RigidBody component to SkeletonCube; now that I could increase the angular drag to a value far higher than the rain cubes' effect on the joints and freeze the rotation on all axes the rotation problem was eliminated. 

SkeletonCube components (click to expand)

The Making Of - The Rain Shower

The rain shower is a particle system that's created at (0,0,20) above the player's skeleton, located at (0,-6,20). This was a modification made on the existing particle system from the paddle example. The shader was tweaked to be blue instead of white. 

A new script was added called Move Rain, which allows the player to move the rain back and forth while also restricting the rain to the camera view. 

The Making Of - Background

The background changes color using the script called RainSplatter, which builds off sample code from Unity's documentation on OnCollisionEnter. I wanted to have the background slowly alter to a darker color if the player was being rained on and back if they were not; I tried to alter the function from Mathf.pingpong to Mathf.Lerp to try this, but it ended up flashing on me in a nauseating way. With Mathf.pingpong, I get a similar effect, even if I want it stop when it reaches the second color I defined.

The Making Of - Audio

I got an audio clip of rain falling from the asset store and attached it to an empty object before setting it to loop.

Outstanding Bugs

I can't find a way to stop the background from changing colors once the rain starts to collide with the body - I wanted it to freeze on that color when the player is not being rained on. I built a script called StopRainSplatter and attached it to the BodyParticles but it doesn't work - the background instead constantly flashes back to the original color when I run the script, so I removed it. 

Resources

Most code resources can be found within the scripts they applied to in the Scripts folder

Audio on Loop: http://answers.unity3d.com/questions/343057/how-do-i-make-unity-seamlessly-loop-my-background.html

Assignment 2 Documentation

For this assignment, I built on the first tutorial we did with the floating cube to prototype the interaction I want to mimic for the final. 

The key changes I made are

  • Make the cube move using the arrow keys (left and right, up and down)
  • Restrict the cube to the camera view

I added a new script called MoveCube. This script dictates how the cube moves - I built on the code we built in class to allow the cube to move side to side.

This gave me this first result: 

The cube was moving but it could float into eternity if I let it. So my second experiment was to restrict the cube to the camera view, which I found a solution via the Unity forums. This led to stage 2.

oving up and down is still broken, but the cube was moving. However, it was still automatically drifting to the bounds of the camera. What I wanted for it was to slow down and be dictated by the arrow presses. 

I messed with some of the settings for the cube to see if I could get it to slow down and stumbled on the Drag property. This gave me the final result I wanted

I wrapped up by adding a particle system because I just wanted to mess with particle systems a little bit. Here are the settings I added: 



Timeline.js Exercise - Retrospective

Of all the tools we used in class, this was the one I was most disappointed in because the experience of using it was far more painful than expected. I'd known about Timeline.js prior to the class since someone had sent out a link to it earlier in the semester and had thought about using it around midterms when I was still thinking about doing a Marvel themed project.

I worked with Hovsep and Gabe to build a timeline of John Boehner's resignation as Speaker of the House. I wasn't able to find the interface we were using in class that day, but I did find the spreadsheets we manipulated. The fact that I had to switch email accounts from my NYU one to my Gmail was a point of frustration - this probably had more to do with security restrictions, but it didn't make a good first use impression. As a UX designer, I expect that if I ran a usability test that the majority of people would give up using the tool at this point because the barrier to entry was high and there wasn't an obvious workaround.

Screenshot of spreadsheet

We ended up not using the interface for the most part to create the timeline; instead, we manually put entries into the timeline. Even by following this methodology the opportunity for error was high (at least, we had a lot of errors). For example, there was some confusion as to what the media field was. We were putting the sources there thinking it would pull the image from the articles, which led to errors being generated. I think that was more obvious in the interface since you had to upload a media file, but that was another pain point for our team.

There's the saying that people won't remember what you've said but they'll remember how they made you feel. Though I understand that the interface is a work in progress, it was a struggle for me to revisit this particular exercise because of the frustration I had with the tool. The current solution is not ideal - I realize I'm probably not the use case this tool is designed for, but there are many usability problems. The intent behind the interface to try and show the user a live updating version of the timeline as they enter data in is a good one, but it still has a long way to go. As for the tool actually fulfilling its purpose, which is to create an interactive timeline of data, I would much prefer to make one out of HTML/CSS myself in the future. The QGIS tool gave me similar frustrations to this one, but there's no denying its capabilities and I can't think of an easier alternative to use that would be a time-effective replacement. For this tool however, there seem to be other timeline building tools such as HSTRY and MyHistro. I needed to have a code to sign up for these, so that makes me think that there's licesnsing fees involved whereas Timeline.js is free and thus good for non-profits or organizations that have a small tech budget. But if I were to build my own timeline, I'd stick to making a one page app in HTML and CSS.


Boehner Walks the Timeline - Timeline.js Exercise

Link to spreadsheet


Final Project Pitch

Here is the original project pitch for the final (taken from the email we sent)

Marijke and I are working together to create a project around self-selection and social media, specifically how social media creates an echo chamber of homogenous opinion/perspective/reference, etc.  We will analyze the Twitter accounts a person follows to determine the diversity of content they consume. The resulting visualization will be a polygonal self-portrait of the user, the complexity of which will be determined by the diversity of their twitter content consumption. The following is our workflow:

 

1 - The user takes a picture of themselves and gives us their Twitter handle

2 - We find the list of people they follow and analyze the text description of each account

3 - Based on the keywords in the text, we create tags to group together the accounts

4 - We generate a low poly version of the image based on the groupings to show the user the diversity of accounts they follow. 

 

We're not sure how to tag and group accounts so that we can build a graph that represents this diversity, so we set some time up to chat with Arlene before the following class to figure out where to go.

CDC

In collaboration with Julian Hyde, Jingjin Liu, and Carl Farra

Space Game: design a game with a large space to play in.

Map of area designed for

Premise

There’s been a breakout of a virus, and the Center of Disease Control has quarantined off the area to prevent spreading it to the rest of the world. A cure is available, but the CDC has a special code that you must send them in order to prove that you are not one of the infected. Work together with your group of survivors to piece together the code and get the cure!

Rules of Gameplay

Three players are CDC members. Take one third of the remaining number of players – they are now the virus. The rest of the players are survivors. Give the virus two minutes to disperse into the play area. After two minutes, the survivors may start moving and the game begins.

The Survivors have 10 minutes to find all three members of the CDC, who will be standing somewhere in the play area, gather the code, and send it to the CDC's phone number. If they do, they win. If not, they lose. To get the code number, they must get within arm's reach of the CDC member and ask for the number. The CDC members will not move during the game.

All players must keep moving at all times, the only exception being when having to cross the street. Survivors may only walk with traffic while the Virus players can only walk against traffic. On Broadway and University Avenues, both teams can walk in any direction. Movement is limited to the sidewalks. If a Survivor is caught walking on the street they are converted into a Virus (except during crosswalks).

When a Virus and a Survivor encounter each other on the street, they must stop and play Rocks Paper Scissors. If the virus wins or there is a tie, the Survivor is converted into a Virus and must immediately start walking against traffic. If the Survivor wins, they keep moving in the direction they were going prior to the mini-game, without any changes. If all Survivors are converted into Viruses, the Viruses win. Survivors cannot be captured in crosswalks.

After ten minutes, all players should return to the Survivors’ start zone.

Playtest Observations

We tested a few key points of gameplay: 

  • How players would interact on the street
  • How players would move in the space

A key point we noticed immediately was the safety concerns; for example, crosswalks were a bad spot for people to try and interact in since it risked people being hit by cars. We then made sure to include the point that crosswalks were a safe spot to prevent this. We also kept gameplay restricted to sidewalks to prevent people from running into the street to avoid interactions. But safety was not just a movement issue; in the initial draft of the game we wanted people to tag each other if they crossed paths. However, it was pointed out that this would cause problems for passerby and may cause injury to players if they weren't careful. We replaced this with the Rock-Paper-Scissors mechanic to introduce some level of randomness in success as well as to replicate the idea of infection sometimes skipping over people. 

The other main thing we noticed was that we ran into problems with restricting people to walking either in the direction of or against traffic - this may be unique to the area we were working with surrounding Tisch, but we found that if we kept strictly to this idea that people would get stuck in certain spots. We then decided to make one street two way to prevent this. While it introduced a complexity that a player would have to remember, it was the major street in the area whereas most of the other streets were smaller in comparison. We later evolved it so that all borders would be two way. 

Initial sketch of movement through the space. The numbers indicate how many moves it takes to get to that crosswalk from the starting spot.

Final Playthrough

Here is the final map of the movement directions: 

Map of space and movement directions courtesy of Jingjin (click to expand)

Map of space and movement directions courtesy of Jingjin (click to expand)

We set up a Slack channel for Survivors to post the codes to when they got them. Three of us served as the CDC workers so that the rest of the class would have an opportunity to play. In the end, the Virus team won as the Survivors ran out of time.


Observations and Feedback from Final Playthrough

  • Walk away, walk away! - players ended up walking during the game instead of running, which was surprising. But it turned out to be strategic; in fact, I saw two Virus players slow down as much as possible without coming to stop when they saw me on my block so that they could cut off any Survivors. 

  • Fate of the group in the hands of one - the Survivors technically could have won because one of their team mates found me but didn't post the code into the Slack before the time ended. It might have been a technology goof since we were forcing players to post codes to Slack; we might need to find an alternative means of having Survivors communicate with each other that a code has been found in a method that would alert the rest of the team. 

Lessons Learned

People will surprise you - it's funny how people acted in ways I didn't expect, from walking slowly on purpose to not being too active on the Slack. We couldn't account for all of these things, but that's why edge cases exist. Plan for surprises and let people have fun with them.