Lab 4

You should be working now in your ~/public_html/reality directory. To preserve your own work in the face of future downloads, do the following.  Make a directory called ~/public_html/reality/my_patch.  This will contain all of your original source code, plus any of the standard library files that you have altered.   Automating the procedure will ensure its correct operation.  Make a new file called backup and put the following lines in it: 

cp DemoTarget.java  my_patch
cp ReBox.java       my_patch
cp ReBullet.java    my_patch
Make sure a carriage return is included on the last line. You must make backup executable by saying 
chmod +x backup
The procedure of building the environment is now
 
  • copy the latest version N
  • copy the latest patch (N+1)
  • copy the graphics if anything has changed
  • copy the files from my_patch

    • Now whenever you reach a plateau, you just type "backup". Remember to add new files to the backup shell-script whenever you start working on them, so they will be backed up as well. Then once in a while, when you really feel good, do the following from your reality directory: 

    mkdir bak001
cp my_patch/* bak001
    replacing "bak001" sequentially with "bak002", "bak003", etc. Shedding a skin. Never change these directories once you've made them, they are your permanent record.

    Check out the Introductory Benchmarks from Lab 3, which have been updated below to reflect our experiences in lab last week.

    INTRODUCTORY BENCHMARKS

    (1) Make a constructor for ReBullet that takes ReVector as its argument, and simplify DemoTarget, correspondingly. This is a fundatmental direction for developing libraries such as Reality.java: Reduce the number of lines in the user application by adding functionality to the library.

    (2) Modify DemoTarget so that bullets are destroyed when they disappear from the screen. This will make the game more fun, by avoiding the eventual slowdown that occurs with the buildup of distant bullets. But it will introduce a computational load of its own. An elegant way to do this is to build an enforcer for the ReBox object. If you want help, check out what Ashish has done.

    Today, when and if you have finished the two benchmarks above, I want each of you to come up with an idea of your own. It doesn't have to be part of the final project, but you never know. You have these different types of spaceships, and you know where each is and what its velocity is. You can exert forces, and accept input from the keyboard. What more do you need? See if you can come up with some interesting behaviors, strategies, interactions, etc.

    Also, I need a volunteer interested in the graphics, to work on bringing new sprites on-line. I have them from the old Maelstrom game, and it would be very educational (and helpful) for someone to take on the task of importing them. This would definitely count towards the course requirements.

    ADVANCED BENCHMARKS

    (1) Harsha is working on groups of ReBox's that can pass entities between them.

    (2) Sam is working on networking multiple Reality.java environments together.

    (3) Chris is developing "line" and "point" primitives to establish landmarks on video images of football fields.