CS 514 Spring 2007: Assignment 3

 

Submission due May 14, 2007. Demo Date: May 15, 2007.

 

Teams are permitted, even for MEng project credit students.

 

New: See guidelines for the project report, and the demo.

 

Objective

 

Our goal in CS514 assignment 3 is to implement a type of online multi-user role playing game of the sort that may be typical of what some are calling “Web 3.0”.  Basically, Web 1.0 is a shorthand that refers to the Internet used in support of browser to web site interactions, or perhaps web client to web server interactions running over the same XML-based technologies.  Web 2.0 is generally used to refer to various kinds of “mashup” technologies that combine information from multiple objects or services to display a composite page.  The most standard example is of a Google mashup combining a map with some form of spreadsheet or database that annotates the map with push-pins, pop-up information, and so forth.  You’ve no doubt encountered mashups when looking for restaurants near a city, knitting supplies in Arkansas, etc.  The beauty of these technologies is that they empower individuals and organizations to draw upon but to customize and extend existing content.

 

What will Web 3.0 bring?  One theory (nobody knows for sure, so far) is that Web 3.0 will be a world of highly dynamic content supported by highly scalable publish-subscribe event notification.   In this vision of the future, instead of visiting web pages, a user might enter a “place”.  Each place would be created by a person or team who designs its interior (perhaps, a futuristic city, a room in a hotel, a cave, the surface of a remote planet...).  Actors (people, other creatures) would be represented by rendered avatars, with each user controlling his or her own avatar.  Interactions, such as when one character shoots at another, would be done by sending a message.  The designers of the standards would need to set the rules for how these events are to be interpreted – did the bullet kill you, bounce off your rock-like skin, or reverse itself and transform to anti-matter? 

 

This vision of Web 3.0 presumes that someone (maybe you) will invent the needed standards: the concept of a place, the way to describe objects within it, and the rules used for those physical interactions (among others).  But beyond the standards, it should be obvious that this vision presumes enormous communication bandwidths,  to support the dynamic creation and delivery of content.  For example, if each user renders his or her own avatar, the user’s machine will be generating a stream of animation content that needs to flow to the others in the room (if any).

 

For our final project, we want you to design and implement a simple version of this Web 3.0 concept.  Come up with your own architecture, prototype the technology, test it, and demonstrate it to us.   

 

We strongly recommend, but do not require, that you make use of existing technologies in building your Web 3.0 prototypes.  In particular, Cornell’s Quicksilver Scalable Multicast will be available to the students doing the project, and a prototype of Quicksilver V2.0 (QS/2) should become available mid-semester.  This is an incredibly powerful technology and will make your life a lot easier. 

 

Teams: For project 3, we will permit teams to merge.  You may work alone, or in a team of as many as 3 co-workers.

 

Optional for MEng credit.    MEng projects should include a (text) discussion of security and privacy issues associated with such an architecture and some ideas on how they might be tackled.    There is no need to implement these ideas.  We also expect MEng projects to do a good job on the basic functionality and a thorough evaluation – what “squeaks by” for a minimal acceptable grade for the non-MEng CS514 student won’t necessarily impress us if you want MEng credit too.

 

What to hand in

 

We are hoping to put the best projects on the QS/2 downloads and demos web page.  Accordingly, for Assignment 3 your work will become public (in a legalistic sense, you own the code and writeup, but will be licensing it for public use and access under a BSD license agreement, which allows people to see and use your work in the current form, while preserving all rights for you to commercialize it or something later, yourself).  If you create a company and become a zillionaire, do remember that Cornell taught you everything you know!

 

Anyhow, this means that your work needs to be downloadable.  You should create a clean “release” version in a ZIP file, containing: the code, a build file for it, and the usual writeup consisting of a description of the architecture you developed, a discussion of your code (keep in mind that an architecture is general – many people could code against it – while your actual program is just one of many possible implementations that respect the rules laid down by the architecture).  You can assume that the users of your demo will also have downloaded and installed QSM or QS/2 – just make it clear what you are assuming. 

 

Similarly, feel free to track down some online rendering engine; there are a ton of them these days.  In CS514, one basic thing we hope you’ve learned is to not reinvent the wheel – so now’s your chance to show us that you understand the principle!

 

Your writeup should include instructions on how to run the demo, starting from compiling the source. Feel free to include screenshots as appropriate. 


You should also include discussion of how you tested your system and what performance you obtain. Feel free to include graphs showing how your system performs.


Total length of the writeup is expected to be approximately 10 pages.  A large team with an ambitious project might hand in a longer writeup, but please limit yourself to no more than 15 pages of text that you expect us to actually read (figures and “appendices” and so forth won’t count against this).

 

People doing the MEng project should have in an additional 5 page writeup on the security and privacy issues raised by the architecture, and how they might be addressed.  This separate document will not be part of the ZIP file unless you decide you want to make it public.


Last but not least: Krzys will put working, impressive, demos on our web page.  For this purpose, please include a single web page and tell us the name of your system (nothing unsuitable for the web, please).  He’ll put your page on the QSM or QS/2 downloads area,  add a link to your ZIP file, and viola.  The QSM area can’t be accessed except by people who fill out a BSD license agreement (basically: we provide the code and executables “as is”, but all rights are reserved.  The user agrees that it isn’t our fault if this code has some bugs or other issues).

 

Demo day (May 15th)

 

The demonstration will be held in the CSUG.  Professor Birman and the TA’s will show up and will want to see your stuff in action.  Be prepared to blow us away (good practice for impressing venture capital investors in June, once you’ve graduated from Cornell and are ready to start your company).


Do keep in mind that figures and other forms of graphics illustrating your work are especially welcome, and the adage “a picture is worth 1000 words” is probably true here.   If you wish, you may include a powerpoint presentation with your other materials.

 

How to turn in your assignment

 

Through CMS (NOT through mail).

 

How we’ll grade the assignment.

 

The TA’s will be grading using roughly the same criteria as were described for assignment 1.  The “Wow” factor obviously counts for this project... 

 
Assignment 3 counts for more.
 
Assignment 3 will be weighted more heavily than assignments 1 and 2, because the project is more ambitious.  50% of the homework “grade points” will be based on assignment 3, with 25% each from assignments 1 and 2. 

 

Hints.

 

Read “Snow Crash” by Neal Stephenson.  Check out “Second Life” and “Sim City”.