Last week we challenged with our three game ideas: The Augmented Reality, Sumo Puzzle game, and our Ripple game. Based on the feedback we got during our testing we decided to go forth with the Ripple game. To recap, Ripples involves the players jumping around on the surface of water. Each time they land on the water they generate a ripple. The ripples are the players tools to attack. If an opponent touches a players ripple, they lose. To dodge the ripple, the player needs to jump over it. The player is forever in a constant state of jumping, so they need to time it to jump over the ripple. Since jumping and ripple generation are automatic, the player is only in control of their movement.
For this week, we were exploring Ripples in three different directions. Willie, our designer, explored ripple interaction. David, the other programmer, looked into music integration. I looked into a mobile version of the game. A majority of the people we talked to mentioned that they could see this on the mobile platform, so I was tasked with seeing how feasible it would be.
Since Unity makes it so easy to make a mobile game, once I installed all the necessary drivers, I had the initial Ripple prototype deployed on my phone. All I needed was a way to control the game. I looked into 3 different directions off the bat. The first was tilt controls. Tilting in a direction causes you to move in that direction, simple. The game reads the accelerometer and moves the player in that direction at a set speed. As of now, the accelerometer only determines the direction and not the speed.
The second control scheme involved having the character mimic the thumb movement of the player. Each frame, the thumb position was calculated and a direction vector was stored based on the thumbs current position and the previous position of the thumb if it was still touching between both frames. The direction vector is then be applied to the player character and the speed is determined based on the magnitude of the vector. This scheme was split into two variations, one with a capped max speed and one with no cap. The capped speed kept the maximum speed consistent with the two other control schemes and the original prototype. The uncapped speed, while most people thought it felt better than the capped version, broke the current build because it made it almost impossible to lose. However the point of this week was to figure out control schemes and what people were most comfortable with.
The final control scheme that was tested out was a simple scheme; swipe in a direction and the player character will move in that direction at a set speed. Taping on the screen would stop the movement.