Homework3W15

Homework Assignment 3: Space Slalom

For this assignment you can obtain 100 points, plus up to 10 points of extra credit.

The goal of this assignment is to create a 3D game for the Sony Move.

Update: due to unforeseen difficulties with the Move drivers, you are allowed to use the device from last project again in this project. If you had a Leap and want to try the Kinect, or vice versa, you will need to find a team that is willing to switch. There will be the opportunity to connect during the upcoming lectures. You can even choose to use the device from the last project and the Move, which can be useful if you got the Move to work at least partially (for instance buttons, orientation or vibration feedback).

This assignment is due on Friday, February 13th at 1:00pm.

The assignment should be done in teams of two if at all possible.

There will be a homework discussion session in CSE lab 220 on Wednesday, February 4th from 4-5pm.

The Sony Move bundle (controller, camera and USB cable) were handed out on Friday 1/30 during grading, one bundle for each team. You are welcome to use your own Move if you have one.

Driver

Before you can use the Move you will need to install a driver for it. Because the Move was made for the Play Station, there is no official support from Sony for it when used with PCs. However, there is an excellent open source driver available for Windows, Mac and Linux. There is also a driver for Unity. Download the driver and try getting it to work on your platform. Since these are community developed drivers, please make use of the course Piazza to share your experiences installing and using the driver, especially if you have or solved problems others in class likely have as well.

The Project (100 Points)

The goal of this project is to create an interactive game in which the player flies a spacecraft through a number of rectangular gates in zero-gravity space, a little bit like slalom skiing. Instead of flying around the gates like in slalom skiing, the player needs to fly through the gates, which are only slightly bigger than the spacecraft itself.

Each team needs to create their own level builder in which the player flies the spaceship around places the ten gates.

The gates for a level need to be saved to an ASCII file so that their positions and orientations can be retrieved later. The file format should be as follows:

CX0 CY0 CZ0 RX0 RY0 RZ0 UX0 UY0 UZ0 
CX1 CY1 CZ1 RX1 RY1 RZ1 UX1 UY1 UZ1 
...
CX9 CY9 CZ9 RX9 RY9 RZ9 UX9 UY9 UZ9 

Each line contains a whitespace separated list of coordinates for one gate, so the file should have 10 lines of numbers. In each line, the first three number should be the center point coordinates of the gate: CX, CY and CZ. These are followed by the normalized vector that points to the right edge of the gate: RX, RY, RZ. The last three numbers are for the normalized vector that points to the upper edge of the gate: UX, UY and UZ.

We will use a unit of meters for this game. Gates should be 10 meters wide and 5 meters tall. This is the size of the opening, so the geometry for the edges should be located completely outside of this size.

The file extension should be .txt so that it is easy to open the file in a text editor.

The player's spacecraft should be 5 meters wide. You can visualize it as a rectangle, a rectangular box of this width, or use a different geometry of your choosing, but you need to scale it to a width of 5 meters at the widest point.

The playing "field" can be assumed to be no larger than 10 kilometers cubed (i.e., 10k x 10k x 10k units). Initially the spacecraft should be located in the origin of the playing field's coordinate system.

The spacecraft's velocity should probably be no faster than about 200 kilometers/hour in order to be able to properly maneuver through the gates.

The camera should show the spacecraft from a third person's perspective so that the player can see it on the screen to make sure it will clear the gates. You are welcome to additionally use other camera perspectives to switch between (such as a pilot's perspective, a control tower view, gate view, etc.).

The goal of the game is to fly the spacecraft through ten gates in as little time as possible. On demo day, we will provide a game file to each group so that we can find out who is fastest. (This ranking will not have an impact on the grade.) This file is going to be called "competition.txt" - make sure your application will be ready for it (we recommend creating a dummy competition file which you'll replace once the official one is available). A proper competition-quality level will have the gates make good use of the three-dimensional space (e.g., not all located in one row or plane), and the gates will not be oriented the same way (their up and right pointing vectors will all be different).

Once your application has started up, it should only accept input from the 3D input device(s) - no keyboard or mouse commands are allowed (except for debugging). There should be a main menu with options to build a level or play a level.

To interact with the main menu you are only allowed to use one button on the Move. In the rest of the game you are allowed to use all buttons of the Move if you wish.

In play mode the player first needs to choose one of several saved levels, then the player gets to fly through the level. At the end the time it took to complete the level needs to be displayed. There will be extra credit for those teams who place in the top 3, see below.

Collisions between spacecraft and gates need to be recognized by the system and the player needs to be notified. This is where the physics engine comes in. Collisions should not alter the path of the spacecraft. Once a collision happens the player needs to turn around and fly through the gate again until it was successfully cleared. If the player does not do this, the game cannot be finished. For the collision test, determine the two points on your spaceship which are farthest apart between the left and right end of it (for a terrestrial airplane that would be the wing tips). Let's call these points whisker tips. Then calculate lines between the current time point and the previous one for each whisker tip. If both lines intersect the gate's interior (represented by an invisible rectangle) the gate was cleared. You may need to consider multiple frames to properly determine this (for the case that the spaceship flies at an angle to the gate).

There needs to be a visual indication for which gate is next. This could happen by coloring that gate differently than the others, an arrow pointing to it, or even multiple things.

Grading

You will get points for the following things:

• Main menu with options for (at least) play (with selection of level file) and build mode (20 points)
• Level builder
  • 3D UI to control the spaceship to fly around placing gates (20 points)
  • Level saving to file (10 points)
• The game
  • Rendering the gates (10 points)
  • Detection of collisions between gate and spaceship and notification of user (visual, vibration, sound, etc.) (20 points)
  • Camera following spaceship (10 points)
  • Visual wayfinding aid(s) (10 points)

Extra Credit (up to 10 Points total)

There are multiple options for extra credit:

• Sky Box: if you add a space-themed sky box which has to be at the edge or beyond the playing field, you will get 2 points.
• 3D Model for spaceship: if you use a nice 3D model for the spaceship and scale it to the required width of 5 meters you will get 2 points.
• Exhaust: write a particle generator and link its parameters to the spaceship's acceleration. 3 points.
• Top 3: the top 3 ranked implementations in the competition will receive 3, 2 and 1 point of extra credit, respectively.
• Shooting gates: 1 point; effect when blown up: +1 point.
• Sound: 1 point
• Auto pilot: 1 point
• Enemy ships: points depend on quality of implementation
• Ghost: 2 points (like Mario Cart)
• Other options may be considered, please discuss with TA/tutor/instructor.