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.

Like physical arcade stores, online arcades such as Shockwave.com, Orisinal, or the 2D games at Xbox Live offer users a suite of arcade-style video games from which to choose. These virtual stores have the advantage that they can keep better track of what games their players are playing and how they are playing them, but the isolation of the online experience means they have to work harder to offer the social aspects of the physical store by allowing players to rate, recommend, chat, or generally collaborate while playing games.

Core Specifications

Work in teams to create two systems: one that allows game designers (i.e., people with minimal programming skills) to easily create new video games and one that allows users (i.e., people with no programming skills) to play the games created in a social way. Thus the programming constructs and user interface presented to these clients must be simple and easy to use, yet powerful --- the essence of a good abstraction.

Specifically, your project should support the following features:

• Game Engine
  Video games have many common characteristics that can be shared as a common design framework so that creating a new game requires only creating things specific to it. Common aspects, e.g., models, scoreboards, timers, splash screens, levels, rules, interactions, etc., should be factored out into an engine that generally supports those games that have 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. This code should be shared by both systems.
• Level Editor
  Designing levels for a game is difficult for many reasons: the shear number of objects to create and the difficulty of testing the level's play-ability are chief among them. But these problems are compounded if the game designer must hand-edit a text file to specify appearance of all the level's objects. Thus you must build an application that allows game designers to load, save, and edit the appearance of game levels graphically. Your GUI should show conform to standard visual design principles of modern applications (e.g., File, Edit, and Help menus as well as context specific toolbars and preference dialogs).
  Basic characteristics of the look and feel of the game should be able to be easily changed: the graphical icons used in game (e.g., to turn a SciFi game into a political statement); the keys used for interaction (e.g., to accommodate multiple players on the same keyboard); and the point values of game objectives (e.g., to make a bonus level). Including support to change these within the Editor is recommended.
• Arcade
  This must include at least three different video games of moderate complexity that highlight different aspects of your game framework. 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 should display its own splash screen, instructions, any setup options it might need, and keep track of a high-score list through successive runs of the program until the player manually clears it.
  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.

To help debug your games (and the course staff to play your games :), you should include a number of useful cheat keys (and easter eggs if they come up during the development of the project).

Extensions

Extensions are intended to stretch your design further and to differentiate your program from others. Choose at least two extensions from those below (or come up with your own) and include them in your project's initial vision statement. Note, many of the named games have videos of people playing them on YouTube.

• Arcade Users. Allow users to log in, choose an avatar to be used within the arcade (or even individual games), view personal high scores, and save their preferences (e.g., name, password, image, age (if parental controls are implemented), and favorite games, players, colors, etc). Additionally, keep track of social aspects of game playing, such as most popular, recent, and highly reviewed games played. Examples: Scratch, GameMaker
• 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, use a fast collision detection algorithm.
• XML. Design XML file(s) rather than Java code that can be used to initialize your game (i.e., describing game level configurations, game resources, and other game specific data as appropriate).
• Mod-able Games: Game companies encourage this practice because different versions of a game add extra play value and interest for purchasing the original game. Join in by allowing users to go beyond simply changing a game's graphics, keys, or point values via the UI --- let them change variables of game play or even add new rules or behaviors to a game.
• Scripting. Much game play code is written in a scripting language on top of a game engine written in a more efficient language (for example, the Unreal 3D Game Engine and its proprietary scripting language UnrealScript). Use the SLogo language to further separate the game design from the game engine internals, making it easier for less advanced programmers to make or customize their games.
• Development Environment. Support game designers in debugging by providing the ability to pause and step the game action, to highlight attributes of game objects (like their health, velocity, nearest neighbors, etc.) visually or by clicking on them, and move or change objects to create specific game situations.
• Testing. Extend the basic unit tests for the game engine to provide a means for game designers to test that that games do expected things, can be won and lost, and progress through levels properly.
• 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, ZingBall
• Artificial Intelligence Engine. Allow game designers to create smart enemies to oppose the player. Examples: Pac-Man, Scorched Earth, Slime games
• Anti-Games: Allow users to control other characters in the game besides the "hero" --- combine with networking or on the same computer to create multi-player 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 Levels. Create a level system that can be invoked conditionally (i.e., a bonus level is loaded if a certain condition is achieved like in Galaga), or levels where you can buy weapons to use in the next level like Battletris, or levels that are actually another game in the arcade.
• Complex Games. Create a significant and very playable game as one of your arcade's games. Examples: Centipede, Defender, ChuChuRocket, BubbleFish Bob, GameOver, or one of your own that is of similar complexity.
• Competition Framework. Allow users to submit and run code that drives a game character in a competitive environment. Examples: Robocode, Greenfoot

Additionally, bonus points will given to the game engine that requires the fewest lines of code to create a new game (while still adhering to good design principles in generalizing the framework), requires the least time to create a new game, is the easiest to change a game's theme, is the easiest framework to explain to a game designer, or is the easiest to install a new game.

These extensions must further the good design of your program and not simply be hacks of code added at the last minute. In general, your design should support adding any of these extensions reasonably (and the project artifact should discuss how to do so). For example, if you do not have time to implement an extension, partial 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.

Your grade will be based primarily on both the framework you design for supporting game development (including its documentation) and the functionality of the games you implement. What needs to be done to add a game to the arcade (both as a user and a developer) should be clearly documented as well as a discussion of the advantages of using your framework design.

Resources

• The Game Loop by Koen Witters
• What is Software Design? by J. Reeves
• Introducing OO Frameworks by Taligent
• Chapter 2 from Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides

Deliverables

1. Tuesday, October 27. 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, that includes:
  • a name for your team and each team member's primary and secondary responsibility on the project
  • a vision for the project: describe your team's priorities for this project, specifically the priority of the extensions your team intends to implement
  • a list of issues that arise as you try to pin down the requirements, e.g., vague, ambiguous, conflicting requirements
• The beginning of your project artifact:
  • a description of the classes you envision as part of implementing this project
  • an estimate of how long you expect it to take you to complete this project; include as specific a task list as possible to support your estimate (i.e., break each of the requirements into several steps, the smaller the better your estimate will be)
• No code is required for this deliverable. Make this information available on a web page (linked to by everyone on the team), and email the URL to Professor Duvall.
  We will check this page frequently to check on your team's progress, so you will need to update this site as you develop your project.
• This week you will be assigned a mentor TA, you must meet with them to discuss your design and your implementation plan
2. Monday, November 2. Team design version 1.0 and estimate (one submission per group)
   • 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 game engine 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.
   • No code is required for this deliverable. Please make this information available on your project web page.
3. Monday, November 9 --- 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. Your team as a whole should be able to defend the details of your game engine to your competitors and demo your current code (approximately three-quarters of the presentation should be on defending your game engine design compared to only one-quarter on the demo).
   • You will have approximately 15 minutes for your presentation. Make it professional and well-structured, specifically, plan what your intend to demo and the code you will show off
   • Submit your presentation slides (or notes) as well as your demo code.
4. Monday, November 16. Team design version 2.0 (one submission per group)
   • A design document that includes a detailed design for Arkanoid and at least one other game, and a preliminary design of your Editor and Arcade
     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, GUI)
     • 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 code using your framework to build a new game
   • 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.
   • No code is required for this deliverable. Please make this information available on your project web page.
5. Monday, November 23 --- in-class. Program version 2.0 (one submission per group)
   • A program that implements the basics of another game besides Arkanoid, the Editor, and the Arcade
   • An in-class presentation of your team's progress. Highlight any changes to your game engine but focus your presentation on the graphical interface to your Engine, the Editor and the Arcade (approximately three-quarters of the presentation should be on defending your framework design compared to only one-quarter on the demo).
   • You will have approximately 15 minutes for your presentation. Make it professional and well-structured, specifically, plan what your intend to demo and the code you will show off
   • Submit your presentation slides (or notes) as well as your demo code.
6. Thursday, December 3. Refactored program and design version 3.0 (one submission per group)
• A third release of your framework that includes a well-designed and well-commented core, based on in-class and mentor feedback, that implements your described design.
  It should include a complete implementation of Arkanoid and at least one additional game, both written using your game engine.
• Update your project artifact to reflect your design since you have added more games
7. Friday, December 11. Public Exhibition, 2-5pm
• A public demo of your project.
• Submit a final version of your project and all relevant documentation by the end of the day.
8. Sunday, December 13. Individual project analysis (one submission per person)