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.

As a class, create a software system designed to ease the creation, development, deployment, and playing of arcade-style 2D video games, often called casual games. 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 a reusable game 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.

At a high level, this software system should

• allow game designers (i.e., people with minimal programming skills) to create, deploy, and advertise new video games
  From this perspective, it is much like online "app" sites like iTunes, Valve, GameMaker, or even Scratch
• allow users (i.e., people with no programming skills) to play, discuss, rate, and mod available games
  From this perspective, it is much like online game portals like Shockwave.com, Orisinal, or the 2D games at Xbox Live

As a class of developers, you will need to rely heavily on each other's documentation in order to figure out how to use other team's projects that you may need to rely on.

Sub-Projects

Other than the game engine itself, this project is divided into several sub-projects.

Note, many of the named games have videos of people playing them on YouTube.

Front End

These projects are the ones users will interact with directly and will tend to be more experimental than the back end components they depend on.

• Arcade
  Players can pick a game to play and play it 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. Games can be searched, tagged, or view what's being played right now.
  
• 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). Offer social aspects by allowing players to rate, recommend, chat, or generally collaborate while playing games. Additionally, keep track of social aspects of game playing, such as most popular, recent, and highly reviewed games played.
• 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. 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). 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).
  
• Replay
  Allow users to save, resume, or re-view previously played 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. Extend even further 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.
• Mod Environment
  Game companies encourage this practice because different versions of a game add extra play value and interest for purchasing the original game. 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). Extend it further by allowing users to change variables of game play or even add new rules or behaviors to a game.
• Games
  Create a significant and very playable game as one of the arcade's games. Examples: Centipede, Defender, ChuChuRocket, BubbleFish Bob, GameOver, or one of your own that is of similar complexity. 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. 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).

Back End

These projects will need to be more stable and well tested than the front end projects that depend on them.

• 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
• Networking Engine
  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
• Asset Management.
  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.
• 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.
• Specialized 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 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
• Competition Framework
  Allow users to submit and run code that drives a game character in a competitive environment. Examples: Robocode, Greenfoot

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