XOOGA
(XML-based videoOO Game Architecture)
The assignment is to create a suite of several games. The games share several common
characteristics that should be exploited in common designs and code for full
credit. Your grade will be based on both the functionality of your games and on
the architecture you design for implementing the games. To receive full credit,
game designers should be able to create a game without modifying any existing
Java code (although they may create new classes), but instead each game should
be completely specified via an XML formatted file.
There are several aspects of the games that can be exploited in developing an
architecture for the games. This means sharing classes, frameworks, and designs
between the games. In addition to the model which might be shareable you can
share scoreboards, timers, user-login screens, etc. Extra points can be earned
for building classes/frameworks that other groups use.
Specifications
You must implement at least three video games in which there is some continuous
movement, some goals that allow the player to advance through a series of
levels, and a separate goal which causes the game to end. Players must be
allowed to pick which game they want to play and to play the game repeatedly
without quitting and restarting the program. Each game must keep track of a high-score list through successive runs of
the program (i.e., until the player manually clears it).
One game must be breakout (i.e., archinoid), with at least three different
brick types and three different levels. You may choose your other games from one
of the following, or choose another of your favorite games, or make up one of
your own.
- Pac-Man
- Frogger
- Space Invaders
- Missile Command
- Asteroids
- Tetris
- Pinball
- Defender
- ChuChu Rocket
XML, eXtended Markup Language, is a standard format for creating tagged data -
you define what the tags are and what they mean, it simply knows how to validate
and parse your file. In short, it is a simple way to represent hierarchical
data. Rather than define your own limited file format for game levels, we will
provide an XML
file specification.
Extra Credit
There are many extensions to the basic specifications possible; some are listed
below. From the stand point of your grade, the most important thing is that your
program is designed well (i.e., that it is possible to add new kinds of objects
and actions simply by creating a new subclass and adding O(1) line to your
existing code to include the new class). The requirements above are intended to
help you to realize such a design.
Next in importance to your grade is the clarity and usability of your
interface. At all times, the user should get feedback for her actions and it
should be clear how she should proceed to complete each task. Additionally, the
user should be protected against doing something irrevocable. If you do all
of the above well, the maximum grade you can receive is an A-.
Finally, the extensions given below are intended to stretch your design
further and to differentiate your program from others in order to capture the
global Videoooo Game market, you must do at least three such extensions if you want
to be considered for a grade in the A range. However, you should not start
implementing any of these until the basic specification is functional. In
general, your design should support adding any of these features reasonably
easily (and your programmer's manual should discuss how to do so).
These extensions must further the good design of your program and not simply
be hacks of code added at the last minute. If you do not have time to implement
an extension, partial extra credit may be given for excellent justification of
how your design either supports adding such a feature already or how it would
need to changed sufficiently to support such a feature.
Sound Effects
Integrate sound effects into your game in a general way.
Chat program
Allow users to send messages to each other while collaborating.
Level Editor
Allow the user to edit the appearance of the game graphically.
Artificial Intelligence
Make smart enemies to confound and attack the player.
Share your games over the network
Allow users to sit at different computers and connect to a common game
session. An update at any one computer should be visible immediately to all
connected users.
- Examples: Warlords, Battletris, Space War, Tank War, Bolo
Share your game interfaces
Allow the class to create a single application by getting together with other
groups to develop a common game interface so anyone's set of games can be loaded
into your project.
Additionally, allow the class to create a single networked application by
getting together with other groups to develop a common network protocol so
anyone's client can talk to your server.
Test your program thoroughly
Provide evidence that your program is correct that can be run automatically,
without user interaction. This can be done in several ways:
- provide a driver program that exercises your "model" directly
without using the GUI
- provide a driver program that "generates" events by calling your
listener functions directly with the appropriate event data
- allow the user to log and save the events generated in an example session
(simply by writing the objects to a file), then allow the program to be run
from this file instead of interactively
Deliverables
- Monday, November 15. Group design and estimate are due (one
submission per group)
- Submit an estimate of how long you expect it to take the group to
complete this project; include as specific a task list as possible to
support your estimate (i.e., come up with at least twenty "user
stories", each of has an estimate and priority for completion)
- Create a web page with your team's vision for the project: your team
name, each team member's primary and secondary responsibility on the
project, your team's description of the role this software is intended
to fill, including which extensions your team intends to implement ---
think of this as the advertising on the box in which your software will
be shipped.
- A description of the underlying model classes you expect to support
the project.
- A description of your graphical user interface, including drawn
"screen shots" of how you plan to lay out your interface and
how you plan to connect the interface to the model.
- A detailed description of how your program will handle the
following use case: In breakout, the ball hits the last brick,
causing it to disappear, a new level to be loaded, the ball and paddle
to be reset, and the game play started again. It should be clear
from this description which objects are responsible for completing each
part of the task.
- Your team as a whole must discuss your design with your mentor before
Wednesday
- Thursday, November 18. Group design version 1.0 is due (one
submission per group)
- You must have a project web page --- linked to by every member of the
group
- You must describe your design for breakout and at least one other game
- You must describe at least three levels of your design and how they
will interact:
- Generic frameworks that might be used in any program (i.e.,
animation, networking)
- Game specific frameworks that support generic sets of games (i.e.,
board, scoring)
- Game specific components that are tied a particular game
- You must explain how breakout will use these levels
- Monday, November 22. Version 1.0 of the program and project
artifact is due (one submission per group)
- A program that implements the basic specifications for breakout
- Your team as a whole must demo this program and describe how your
framework will work in class this week
- An in-class presentation of your progress.
You should be able to defend the
details of your framework to your competitors (and perhaps convert some
of them to cooperate with you). You should demo your current code;
however, 90% of the presentation should be on defending your framework
design (so make sure it is a good one and that you understand it). You
may also allow for questions at the end.
- You will have approximately 20 minutes for your presentation. Make it
professional and well-structured.
- Tuesday, November 30. Group design version 2.0 is due
- Update your project web page to reflect your design since you have
added more games
- Thursday, December 2, Version 2.0 of the program and project
artifact is due
- A program that implements all of the basic specifications for at least
three complete games
- Monday, December 6, Version 3.0 of the program and project
artifact is due
- Monday through Friday, December 6 - 10, Final Project Demo
- Demo final version of your project with me. The entire team must be
present to qualify.
Expect this demo will take approximately one hour.
- Friday, December 10, The project
analysis is due (one submission per person)
Comments?