Due by last class meeting (demo-day) Fri March 7th. For this project you should work in teams of two. Email me your teams asap. If you don't have a team by class on Wednesday March 2rd I will assign partners arbitrarily. Both team members will receive the same score and you may combine your slip days. However, slip days may only be used to extend the deadline until our last class meeting (right before Spring Break). After that submissions will be considered late and given a zero.This is your last assignment in the class and I'm going to give you something of a blank sheet for part 5 in that it will be up to you what enhancements you make to our web-app. Expect to give a demo of your enhancements in our last class meeting.
Continue the tutorial in the AWDwR book. Setup and run our web-app locally on your Rails development machine. Improve the functionality of the web-app by doing one or more of the suggested enhancements and/or by coming up with some of your own.
- Rails Tutorial continued...
Continue the rails tutorial you started in the previous project by doing chapters 9-11. For extra credit you can do chapter 14 as well, but it is quite long and I would rather you spent the time working on a project to enhance our class web-application, so if you want to do chapter 14 please come back to it after you have completed part 5 below. After you are finished zip up your
depotdirectory and submit it in the usual way.
- Copy the Web-app to your Rails development machine.
The web-app directory is on the CS department machine called "z" at
/u/z/users/julian/rails2_apps/rubygame. Copy this directory and all it's contents to the same directory on your local machine in which your
depotdirectory is located. You do not have permission to access the following directories so you will have to create them (empty) manually on your local machine:
- Create the Web-app's database locally.
- Use the following commands to create the database:
mysql -u root -p (it will prompt for a password but just hit return unless you set up a root password) CREATE DATABASE rubygame; GRANT ALL PRIVILEGES ON rubygame.* TO rubygame@localhost IDENTIFIED BY 'RubyCS105'; (we just made 'RubyCS105' the password for the rubygame database) QUIT
- Now you need to modify your local copy of
rubygame/config/database.ymlso open it up in a text editor. Change the database and username from
rubygame. Also change the host to
- Use your newly gained knowledge of migrations to create all the database tables - HINT: the migrations you need already exist! Here is a diagram of the rubygame database.
- Use the following commands to create the database:
- Run the web-app on your local machine
Start the web-app running in the same way you started your
depotrunning in the tutorial. In your browser navigate to
http://localhost:3000/games. Test it is all working by uploading
c4_simpleton_s11_your_name.rband playing some matches.
- Web-app Enhancement Projects - and may The Force be with you.
Please describe your enhancements carefully in a file called
README.txt. MAKE A BACKUP OF YOUR ENTIRE
rubygameFOLDER BEFORE STARTING ON ANY ENHANCEMENTS! Here are some suggestions, but feel free to ignore them and be creative!
- Luke Skywalker
- Make the number of records displayed per page controllable by the user, and when the page must be scrolled to reach the bottom you should duplicate the main navigation links (My Games, My Agents etc) below all the records too.
- Make all our list pages sortable by any column
- Make all our list pages filterable by any value in any column
- Extend the user sign up process to include an account activation email. Note that our user authentication comes from a plugin called
restful_authentication. You can Google it. This plugin may have features we haven't fully exploited yet!
- Enable a user to edit their Game and Agent code online through the web-interface. Including Ruby syntax highlighting would be a very nice touch.
- Before a game becomes generally available, the owner of the game should have to play one error-free match with it to prove it works. If it doesn't work, the owner is then guaranteed the ability to destroy it since no other users have had the opportunity to try it or even assign agents to it yet.
- Most of our controller methods in which changes are saved to the database actually affect records in more than one table. We would like all of these changes to succeed, but should some of them fail we would prefer that none of the changes are applied. Learn about Rails support for database transactions and modify the controllers to ensure that the changes applied in response to any single user action are indeed applied atomically - i.e. all or none. Chapter 20 in the AWDwR book should get you started.
- Obi-Wan Kenobi
- Make the columns included on our list pages user-configurable i.e. the user selects which columns are displayed.
- Make the filters appllied to list pages user-configurable e.g. combinations of values, value ranges etc.
- List configurations such as filters, column selections, records per page all stored as user preferences (Database involved)
- Logging: Extend
gamebase.rbto provide all games with a logging service they optionally use. Instead of saving just the final game state, all intermediate game states would also be saved. Any extensions to the
GameBaseclass must not break backward compatibility with all the games that already inherit from it. (I believe this could be accomplished without any database changes.)
- Master Yoda
- Visualizations: Develop a general mechanism for presenting a visualization of a game's final state. A game author should only have to upload at most one additional file when creating their game. Your mechanism should do the rest. This must work for any game! (Database involved)
- Playback: Given logging and visualizations, implement a general playback screen that can step forward and backwards through the visualizations of every state in the log of a match. This must work for any game!
- Interactive Games: A number of versions are imagineable: User vs Agent, User vs User, Agent vs Agent with user spectator pausing play after each move. All of these require the game state to be saved to the database after every move. If logging, visualizations and playback were all well designed they should be leverageable here. This must work for any game!
- Dark Lord of the Sith
- Asynchronous Games: execute a lengthy game or batch of games asynchronously on a separate long-running thread, process or even a differrent machine, writing the results to the database in the normal way upon completion. This does not require changes to our database design but you'll need to understand
results_controller.rb, and some things in Ruby and Rails like mulithreading, multiprocessing, distributed objects (DRb), job queues etc. Do some Google searches on "asynchronous rails" to get started. Again, this must work for any game!
Zip up and turn in your
depot web-app after completeing the tutorial. As long as it works when I test it you will get full credit for this part of the project.
For your required enhancements to
rubygame brevity is best. Don't change code in many places if you can change it one place. Don't write many lines of code if you can do with just a few. Add comments to explain your work. Be sure to test your enhanced app thoroughly before turning it in - do not just assume that if it worked before you changed it then it still works after you changed it. TEST!
README.txt- but only if you have made extra credit enhancements