I made two videos because the webcam in the first video took up a lot of room. Also, the minor choppy-ness in the videos is not from the game, it is from
the screen recording software I used.
Give a brief summary of the game
Shot Blocker is a kinect game where you are a soccer goalie. To play, you must stand approximately 4 feet from the kinect and stick your hand out.
Your hand will control a pair of hands on the screen. As soccer balls are shot towards the camera, you must move the hands on screen to block the ball.
The goal is to block as many balls as possible. When you let in 5 goals (the ball travels behind the camera), the game is over. This game was inspired by the
kinect soccer game for xbox 360.
What are the key algorithms and techniques you used in developing your game?
The main algorithm used in my game is 3D collision detection. This happens when the hands collide with the 3D ball. I achieved this by first detecting when the ball
crosses the z-plane that the hands live in (since the player can only move their hands in x and y direction). I added a small buffer of 30px (in the z direction) to make
sure that the ball doesn't pass through the plane without being detected. Once the ball is detected to be in the z-plane, then collision detection is done in the x and y
direction. This is very similar to 2D collision detection since the hands are implemented as a square, and the sphere has a radius. I just used the radius and the sphere
and the width of the square to check if the hands were within the dimensions of the sphere. Once a collision is detected, the y velocity of the ball is set to 0.
This makes the ball fall through the ground. It doesn't look the most realistic, but works well to set up for the next ball.
I also re-implemented 3D projectile motion to make the motion of the ball look like a natural soccer shot. The difference between a normal projectile motion implementation (such as what I did
with cannon duckies) is that the ball is traveling towards the camera. This means, instead of updating the x position each update, the z position is updated. The y position
is the same which makes the ball fall (because of gravity) in a realalistic way.
Did you need to add any special processing to handle user inputs? Any error handling? Signal Processing?
Since I used the kinect processing library, getting the user input was fairly striaght forward (as was shown in class). There isn't any error handling, but the game will not work if the player
is too close to the camera, or if the player sticks 2 hands out instead of 1. Initially, I wanted the player to control 2 hands independent of each other. I looked
into doing this with the kinect, but it seemed too difficult for the scope of this assignment. My user input is based on the average point on the screen (to control the hands).
How does your user input affect the difficulty of your game? Did you need to re-tune any aspects after play testing?
The user input makes it hard because the ball moves faster than the player can move his/her hand (in control). When the game is played with the mouse, it is much easier to
move the hands because moving the mouse is easier than your whole hand. After play testing I re-tuned all the parameters of the ball. I tuned the speed and the angle it's shot at.
It was difficult to find the correct speed of the ball. Many times it was too slow making the game too easy, and sometimes it was too fast making the ball impossible to block.
I ended up making the ball speed random within a certain range to make some easy to block, and others more difficult.
That being said, I feel as if the game is still too easy (perhaps because I'ved played it a lot). If I had more time I would implement more features to make the game more fun
and challenging for the player.
I did not write the class kinect_tracker. I followed this tutorial and used the class found on his github page. The kinect
tracker class just returns the average point. (exactly what was shown in class)