476
Advanced Web Applications
Group
Project
Prime Time
Picks
Spring
2001
Professor
Shklar
Group 4a:
Kevin George kjgeorge@eden.rutgers.edu
Dave Austin daustin@remus.rutgers.edu
Janine Perret janinep@remus.rutgers.edu
Overview
Both the television and internet have been instrumental to opening up our world: people now send and receive information much more easily, they communicate more effectively over long distances, and they just have more fun. Sitcoms, game shows, talk shows, news broadcasts, and even made-for-TV movies have emerged from the infusion of television, while the most popular genres of Internet gaming systems include strategy, role-playing, action adventures, and online versions of various table games like chess. Along with the more conventional online games previously mentioned, a new form of entertainment has appeared. This type of game tracks the performance of its players over a longer period of time. Typically a user’s performance is defined by his ability to predict a researchable and attainable statistic, such as a sports team’s score or record.
With this premise in mind, we propose a merger of both the television
and internet worlds, to create the online gaming system, "Prime Time
Picks", allowing users to build a team of their favorite television stars
to be competitively ranked against others.
Each actor or actress currently appearing on broadcast television is
assigned a dollar value relative to their perceived worth, which is based upon
a combination of the show's success and the actor's contribution to that
show. Registered users will be allotted
an initial dollar amount, with which they choose a team of up to ten
actors. As the television season
progresses, the actors' values change as their shows fall and rise in the
Nielson ratings; this in turn alters each user's worth and prompts users to
continuously update their rosters in order to maximize their total value. Users are ranked against each other to
enhance their competitive drive; prizes will be awarded throughout the year to
the users with the highest total worth.
Technologies
This project will make use of the following technologies: Java servlets,
JSP pages, HTML forms, JDBC/databases, cookies, and the Apache Tomcat server.
High Level
Design
Our application will provide the
following six services. These services
do not depict the implementation or architecture of the application, but merely
provides an abstract model of the transactions that occur within.
1.
User Registry
Our application will maintain a registry of the users and their profile information like a password, possible team affiliations, and other information. In order to play the game, the user will be required to register and login.
2.
Portfolio Managing
The actors that the player will
choose are to be stored and their respective costs will be computed and
tallied, ensuring that the roster adheres to the rules and regulations of the
game. The user registry will keep track
of the user to portfolio pair.
3.
Automated Nielsen Ratings
Every week when the Nielsen
ratings are published, an automatic updater will query the rating source and store
them. These ratings will be used to
compute the scores of the players and the worth of each actor.
4.
Score Keeping/User Ranking
Once the ratings are in, the
score keeper will compute the scores for each portfolio and rank them in
descending order. The user registry
will be able to search for a specific user’s rank also. It will store the players’ ranks on a weekly
basis as well as add on to a season’s total record.
5.
Show/Actor Records
There will be functionality for a
user to search for a show and its stars and also all the shows in which a
single actor plays a role. There will
also be a history of the Nielsen ratings available for a particular show over a
longer period of time.
6.
Administrative Interface
We would like to include an
interface to the game’s general construct and database. Of course, only the designers will have
access to the interface. The user
registry can have accounts for designers as well so it can permit the
applicable users to the interface. Some
of the anticipated functions for the administrator will be adding or deleting
shows/actors to the database, removing/editing accounts in the user registry,
and perhaps changing some of the configurations for the application.
Low Level
Design
Figure 1: Basic Architecture Design
As the overview (Figure 1) above shows, the gaming application will reside on an Apache server running a HTTP servlet. Apache will be configured to allow the servlet to process all incoming user requests, thus allowing the servlet to respond to the user with a JavaServer Page (JSP) based upon the request received. Each JSP will be comprised of dynamically generated information in HTML format; the JSP will contain all necessary calls to the database to retrieve this data.
Our database schema will be implemented using MySQL, and will be
comprised of five tables for system information, user registry, user portfolio,
and information on actors and their corresponding shows. The Show Information table will be updated
weekly (a preference actually set in the System Preferences Table) using
Neilson Rating data which has been retrieved using an XML formatting tool.
The tables can be defined as follows:
System Preferences
Table: (Update Length of Time,
Neilson
Source URL)
User Registry Table:
(User's Name, User ID, Password, Email)
User Portfolio Table:
(User ID, Unused Money Amount,
IDs for the 10 currently
chosen actors)
Actor Information
Table: (Actor ID, Actor's Name, Show ID,
Actor's Relevancy
Weighting,
Actor Summary)
Show Information Table:
(Show ID, Show Name, Show URL,
Show Rating as per Neilson update,
Previous 9 Neilson Ratings, Show
Summary)
New users must first register with the gaming server, which involves
filling out an informational form (name, email address, username and password)
and choosing up to ten actors, within their initial monetary amount ($250), to
fill their roster. The registration is
free, and adds the user to both the User Registry and User Portfolio tables. Once registered, user functionality includes
selling and purchasing actors, tracking actor and show values, reviewing
portfolio purchases and current value, and examining personal rank as compared
to others. All user and show
information stored in the database will be static, with the exception of the
Show Rating and Previous Neilson Ratings fields in the Show Information Table,
which will be dynamically updated from each week’s ratings.
The actual gaming application will be delivered to the user in the form
of JSP’s, which utilize the Java Database Connectivity (JDBC) API to retrieve
the necessary database information. The
JDBC calls will be embedded within the JSP and will be formatted into HTML
code. Each time the user requests a new
JSP, the application will employ servlets to handle the request. Our primary dispatching servlet will extend
Java’s HttpServlet class and handle the necessary semantics involved in serving
up the appropriate JSP. Such semantics
include, but are not limited to, maintaining concurrent user sessions, deciphering
current user state and validating user logins.
The servlet must reside on an http server that will supports its
execution. Our application will make
use of the Apache Tomcat server, which can run stand-alone or in conjunction
with a standard Apache web server. For
our purposes, Tomcat need only run by itself, and will therefore receive all
incoming http requests. Our application
can be deployed through the Tomcat server after completing the necessary
customization and setup steps. In order
to enable Tomcat to run our web application, the applications context must be
added to the server’s server.xml file and the applications hierarchy of
files must be installed under the server’s web application directory.
Game
Specifics
Each television show currently airing will be assigned a unique ID
number and added to the Show Information Table in the database. The actors and actresses appearing in that
show will then also be assigned a unique ID number and subsequently added to
the Actor Information Table. Each actor
is then assigned a weight by being ranked according to their contribution to
the show: a rank of 3 being the highest, down to a 1 for a less-important
supporting actor. This will currently
be done manually.
Each week, the Show Rating field for each television show in the table
will be updated according to the show's performance on the Neilson
Ratings. Each actor 's worth is then
based on a combination of the actor's weight and the show's relative performance
using the following formula, where Top Performer signifies the highest rating a
show has obtained that week:
Worth=Weight*(Performance/Top
Performer)*25
For example, suppose Frasier does particularly well one week, and scores
a 17 on the Neilson Ratings, where the top scoring show receives a 20. Kelsey Grammer (who plays Frasier himself)
would then have a worth of 63.75=3*(17/20)*25, because he plays the main
character and therefore has a weight of 3.
Meanwhile, Moose (who plays Eddie the dog) would only have a worth of
21.25=1*(17/20)*25, because his weight is only a 1.
The
player can make decisions on what actors to add to and remove from the roster
based on personal feeling along with analysis of the corresponding show’s
Nielsen ratings from the previous week.
The newly modified roster will then be played during the following
week’s period. At the end of the week
(or the start of the next week) when the ratings are published, the user’s
score for that week will be determined.
A user can change players without affecting their worth up until the new
ratings are taken into account.
To begin with, each user is allocated $250 of gaming money with which to
purchase their initial actors and actresses.
In order to assist the users in their actor purchases, we will provide
some search capabilities and supplementary information on the actor and
show. Each actor and show will have a
page summarizing themselves, complete with a photograph, if available. An example would be:
