VOOGA

Video games are an increasingly important medium in terms of international use, cultural impact, and profitability. Arguably, video games have also driven many recent advances in computer hardware and are finally gaining acceptance within the academic community as an area worthy of study. And why not? Video games contain all of the basic elements taught in computer science and commercial game engines are becoming increasingly complex software systems. While the focus of this project is not to build commercial quality 3D video games, you will build 2D video games that represent all of the same basic concepts.

Work in a team of four to create a framework that allows programmers to easily create a suite of arcade-style video games such as those at Shockwave.com, Orisinal, or the 2D games at Xbox Live. Video games are a genre that shares several common characteristics that can be abstracted into a common design such that creating a new game requires only creating the behavior and objects specific to it. These common aspects, e.g., models, scoreboards, timers, splash screens, game rules, game interactions, etc., should be factored out into your architecture. Each game should display its own splash screen, instructions, and any setup options it might need.

Specifications

You must implement at least three different video games to populate your arcade, in which there is some continuous movement (by either the player or the enemies), 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 until the player manually clears it. Additionally, the player should easily be able to edit the graphical appearance of the game, for example by changing the icons used in game (so that Space Invaders might be turned into a political statement). One of the three games must be Arkanoid, a variant of the original Breakout, with at least three different brick types, three different power-up types, and three different levels (each of which has a different starting configuration of the bricks). For other variations of Breakout, consider these examples: Worms Breakout, Vortex, or Circus Atari.

These days, most gameplay code is written in a scripting language on top of a game engine that is written in a more efficient language (for example, the Unreal 3D Game Engine and its proprietary scripting language UnrealScript). This further separates the game design from the game engine internals, making it easier for less advanced programmers to make or customize their games. (It also allows games to be even more dynamic since code can be modified while the game is running.) As much as possible, the games in your arcade should be written in Jython while the game engine itself is written in Java. Unfortunately, Jython does not support the same encapsulation features as Java, making it easy for future developers to access game engine internals. Thus it will be vitally important that you provide detailed documentation of the API you expect game designers to adhere to when creating a new game.

Additional details can be found in this example functional specification that contains a description of some extra credit features given below.

Extra Credit

Your grade will be based on both the functionality of the games you implement and on the architecture you design for supporting the games. 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 games simply by creating new subclasses and adding O(1) line to your existing code to include them). The requirements above are intended to help you to realize such a design. Bonus points will given to the framework that requires the fewest lines of code to create a new game, the least time to create a new game, is the easiest to change the game's theme, is the easiest framework to explain to a game designer, or is the easiest to install a new game.

Next in importance to your grade is the clarity and completeness of your framework design description. It should be clear exactly what needs to be done to add a game to the arcade (both as a user and a developer). You also include a discussion of the advantages of your framework design. 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 VideOO Game market, you must do some of the 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.

• Arcade Users. Allow users to log in, save preferences, and view personal high scores. Additionally, keep track of social aspects of game playing, such as most popular, recent, and highly reviewed games played. Examples: Scratch
• Level Editor. Allow users to edit the appearance of game levels graphically.
• Save, Resume, and Replay. Allow users to save, resume, or re-view previously played games.
• Efficiency. Make your game engine as efficient as possible (while keeping the design goals of the project). For example, cache all images and sounds so they are only stored once, or use a faster collision detection algorithm.
• Stellar Graphics. Even using images, the graphics displayed in the animation engine are very ordinary. Provide support to make it easy to upgrade them to look much more rich and compelling. Examples: Geometry Wars, Ikaruga, and Flow
• Networking. 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, Pongbat, Scorched Earth, Slime games
• Physics Engine. Allow game designers to easily use standard physical reactions or define their own style of physics for a game. Examples: N-Game, Portal, Incredible Machine, Pinball, Slime games
• Artificial Intelligence Engine. Allow game designers to create smart enemies to oppose the player. Examples: Pac-Man, Scorched Earth, Slime games
• Isometric Games. Basically 2D games with a simulated 3D perspective (i.e., the simplicity of 2D with the look of 3D). Examples: Ballistik, Portal, Paperboy, Zaxxon
• Complex Games. Create a significant and very playable game as one of your arcade's games. Examples: Defender, ChuChuRocket, BubbleFish Bob, or one of your own that is of similar complexity.

Deliverables

0. Tuesday, November 11. Team preferences (one submission per group)
• Email Professor Duvall a team of four or five people with whom you would like to work and a name for your team.
1. Thursday, November 13. Initial Web Page describing your team's goals (one submission per group)
• Create a web page for your project, linked to by every member of the group, with your team's vision for the project: 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 some extensions your team intends to implement --- think of this as the advertising on the box in which your software will be shipped.
• List of issues that arise as you try to pin down the requirements, e.g., vague, ambiguous, conflicting requirements; issues in what's asked of you; concerns that you have about specific features or design ideas.
• No code is required for this deliverable. Please make this information available on a web page, and submit the URL to find the information via email to Professor Duvall.
2. Sunday, November 16. Team design version 0.1 and estimate (one submission per group)
• 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., break the project into specific "user stories", each of has an estimate and priority for completion)
• 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 Arkanoid, 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.
  A guide to running your initial design meeting is available online here.
• No code is required for this deliverable. Please make this information available on your project web page.
3. Thursday, November 20. Team design version 1.0 (one submission per group)
   • A design document that describes your design for Arkanoid and at least one other game
     include at least the following three levels of abstraction 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 to a particular game
   • A user guide that explains how your a game designer will use your framework to build a new game
   • No code is required for this deliverable. Please make this information available on your project web page.
4. Monday, November 24 --- in-class. Program version 1.0 (one submission per group)
   • A program that implements a basic game of Arkanoid
   • An in-class presentation of your team's progress. You team as a whole should be able to defend the details of your framework to your competitors and demo your current code; however, 80% of the presentation should be on defending your framework design (so make sure it is a good one and that you understand it).
   • You will have approximately 15 minutes for your presentation. Make it professional and well-structured
   • Submit your presentation slides (or notes) as well as your demo code.
5. Friday, December 5. Program and design version 2.0 (one submission per group)
   • A second release of your framework that includes new extensions, based on your vision and customer feedback. It should include a complete implementation of Arkanoid and at least one additional game, both written within using your framework.
   • Update your project web page to reflect your design since you have added more games
6. Thursday, December 11, Public Exhibition, 2-5pm
   • A public demo of your project.
     Any random person should be able to come by, see you demo your project, and ask the developer's detailed questions.
   • A coding competition to try to implement a game in another team's framework.
   • Submit a final version of your project and all relevant documentation by the end of the day.
7. Sunday, December 14, Individual project analysis (one submission per person)