Revision as of 19:48, 1 February 2016

Air Race

This project is due on February 12th at 2pm and to be demonstrated, as usual, in CSE basement lab 220.

For user input the only permissible device is the Sony Move controller (the extra credit allows an additional 3D device).

If you are not familiar with air races, you might find this video entertaining and informative.

Our version of the air race actually resembles the rather new category of drone races more. Here is a great video illustrating how it works. Here is another hopefully inspirational video for this project.

Sony Move Setup (10 Points)

To use the controller, you will have to first get its driver to work. There is no official, polished driver available because the device was made for the Playstation. However, we are providing a Windows version of the driver on our MoveInVR wiki page. On the Piazza page is a special note in the pinned area under which you can post questions about the setup.

If you use an Apple computer with OS X these instructions will hopefully get you going with the Move. Please post any problems you run into on the Piazza page and we'll try to help.

Race Track

This UCSD campus model provides the environment for the race track. Load it into your application and turn the buildings and the ground plane into colliders that cannot be traversed.

The race track is a set of check points the player has to go to in a specific order in order to win.

24 hours before grading starts (which means on Thursday, February 11th at 2pm), we will post the competition file here and a note on Piazza. The competition file will be an ASCII file in the XYZ file format, listing the locations of your check points. The coordinate system will be the same as that of the campus model. An XYZ file does not have a header, it only consists of a list of point locations in 3D, in the format X Y Z<return>X Y Z<return> and so on. An example for an XYZ file defining two points is this:

-200.0378 100.1279 10.0475
-202.0447 103.1288 10.0905

The coordinates are separated by white space or a tab character, the points are separated by a line break. On each line are three floating point numbers. The first three are the x, y and z coordinates of the first point. The next three numbers are the x, y and z coordinates of the second check point, and so on. There could be hundreds of points in the file. In this project you can assume that the competition file will not have more than 100 check points.

Here is what you need to do:

• Write a parser for XYZ files. It should be a simple for loop in which you read each line of the file. In C you would use the fscanf command for this. Your parser does not need to do any error handling - you can assume that you will get a proper XYZ file. You do need to recognize when there are no more points in the file (i.e., check for End of File)
• Draw the check points using a method of your choice. You can assume that all check points will be floating above the campus model and will not intersect with any buildings. For instance, you can draw the check points as wireframe shperes. The goal is that the visualization should allow the player to move from one check point to the next as fast as possible without missing any. There will be a time penalty for each check point missed. A check point is reached once the aircraft's origin gets within a fixed radius of the check point. For now you can use a radius of 30 feet, but we may change that for the competition, so be sure to make this number easy to modify.

Aircraft

You are free to choose any 3D model for your aircraft you would like, just not an airplane. If you don't find one, feel free to use this Collada model of a quadcopter, provided by Professor Falko Kuester's lab here at UCSD, designed by graduate student Dominique Meyer. Regardless of what aircraft model you use, for collision checks with buildings and the terrain assume an aircraft size of a cube 3 feet wide, or a sphere with a diameter of 4 feet. Your aircraft does not have to be a drone, but it should be one that can plausibly fly in any direction, not only forward like an airplane.

Flight Controls

You need to implement two different ways to control the aircraft, both need to exclusively use the Sony Move controller. The first method is described below, the second one is up to you to create.

Method 1: This method utilizes only the 6 DOF (degrees of freedom) position and orientation data from from controller, along with a (binary) button. The idea is that when the button is pressed, the location and orientation the controller is in at that moment is stored in memory. The user will then hold down the button as long as they want to move the aircraft around. The movement is done by fetching the 6DOF data every frame, and comparing it with the 6DOF data stored initially. The difference between the two, both in position and rotation angle, should be multiplied by a fixed adjustment factor, and then applied to the aircraft. When the button is released, the aircraft should come to an immediate stop. Example: user presses the button and moves the controller towards the eye camera, without rotating it. This should make the aircraft move forward. The more the controller is moved toward the eye, the faster the aircraft will fly. One can slow down but moving the controller away from the eye.

Method 2: This is your custom method. Try to come up with a way that works better for the given scenario, allowing the player to get through the race track faster.

Wayfinding

The check points can be quite far from one another, and they are not along a straight line, so it will be important for the pilot to know where the next check point is. Come up with at least two visual ways of helping the player to know where to go next. For instance, you could have an arrow pointing to the next check point, and you could have a line connecting all the check points, or just the previous one with the next, or the current aircraft position and the next check point. Whatever allows the pilot to get to the next check point faster works.

Gameplay

The player's aircraft should start at the first check point, with zero pitch or roll (level with the ground). It should be facing the second check point.

You should use a third person view: the camera is somewhere behind the aircraft with the aircraft in the center of the view.

There should be a count down of some sort. Before the countdown ends the aircraft can't move. Once the countdown is done, a stopwatch starts running and is shown in a fixed position on the screen. The player takes control of the aircraft and tries to fly to the next checkpoint as fast as possible. Once that checkpoint is reached, there needs to be some sort of visual notification that the checkpoint has indeed been reached. Once the last checkpoint has been reached, the race is over and the time is halted and needs to remain visible.

Grading will include that you fly your aircraft along all the checkpoints both with our travel method as well as your own and we record both times. Who is going to have the fastest lap time in class, and what travel control method will it be achieved with?

You are free to add audio to the game if you desire, but there will not be extra points for it. The benefit might be that it could improve your lap times.

Extra Credit: Two Player Mode (10 Points)

Create a split screen view of your application to allow another player to control their own aircraft and compete against one another. The second player needs to use the input device from the first project (Leap or Kinect). Let's find out if the player's speed depends more on skill or on the input device. Make sure your game supports the following things:

• The two players need to fly their aircrafts simultaneously.
• At the end of the race the completion times and penalties need to be displayed for each player.
• In each player's view, the other player's aircraft needs to be displayed in the location it is at that moment.
• The two aircraft should not be able to collide with each other. They are allowed to intersect with each other with no effect.