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 or GameCenter

Sub-Projects

While the class as a whole will be working together, smaller teams will focus on building specific sub-projects that need to work together for the project to succeed. 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.

Game Plug-ins

These projects provide higher level tools on which to build games.

• Events/Time/Input: Create a framework for defining a game as an event driven system, i.e., a series of responses to significant events. The system should be efficient and extensible, allowing designers to easily register and swap out sets of event handlers. Note, time and input fit into this system as an outside generator of events.
• States: Create a framework for defining a game as a series of states, i.e., running, paused, over, powered, etc. It should coordinate flow between different game states in a game, allowing designers to easily setup and swap out states.
  
• HUD/Stats: Create a framework for displaying information the the user needs to see during a game. This information should be updated automatically, displayed in a variety of formats, and automatically positioned within a HUD that is separate from the game screen.

Game Sprite Plug-ins

These projects improve the basic Sprite system in Golden T.

• Sprite Enhancements/Collisions: Create a more sophisticated Sprite model that includes better support for modifying images at runtime, a more intuitive coordinate system, and more intelligent and efficient collision management. Update the collision system to be more automated and flexible by allowing Sprite tags, neighborhood-like regions, and customizable collision shapes. Separate the detection of collisions from the reaction to collisions.
• NPCs: Create a framework for building custom non-player characters, e.g., sprites that follow a pre-defined path, a state machine for simple bad guys, or "smart" characters that utilize the game environment to plan a next move. May utilize basic AI techniques such as path finding. Additionally, should provide automated ways to create waves of NPC characters.
• Physics: Create a framework for easily using standard Newtonian physical movement or collision reactions. Allow designers to choose which elements are acting physically, their physical properties, which forces affect the game environment. Maybe even allow then to define their own style of physics for a game (e.g., space, cartoons, reversed gravity, etc.).

Game Setup

These projects help make designing the game more flexible by providing a means to help design the game without resorting to hard-coded values in Java.

• Resources/Levels/Input: Provide a framework for keeping track of game configuration, images, sound and any other files and accessing everything easily within game. Design XML or Java resource 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). Design a standardized game directory structure for game resources (e.g., help file(s), splash screen(s), resources, etc.). Additionally, you may also try to be extra efficient in managing the game resources, e.g., cache all images and sounds so they are only stored once.
• 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 that outputs text files that can be used by the level system. 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 point values of game objectives (e.g., to make a bonus level); and probabilities of game events (e.g., when power-ups or rare characters appear).

GUI Front-end and Communication

These projects are the ones users will interact with directly, requiring Swing components for interaction and networking with a central site to achieve persistent, global storage so the entire class can interact with the same data.

• Arcade/Users/Preferences: 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, input keys, colors, etc). Note, an administrator should be able to manage the user list as well, including support for resetting passwords or blocking users. Additionally allow users to 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.
• Chat: Allow users to chat with other users when not playing a game. Provide a GUI to see who is currently online (and not playing) and let the user invite other users to chat (in the current session or a new one). Design a protocol that allows logged in users to query for other users online, start or join chats, and send broadcast or private messages.
• Ratings: Allow users to rate or recommend games and see all those made by other users. Allow people to keep friends and show their ratings above others. Keep track of social aspects of game playing, such as most popular, recent, and highly reviewed games played. Additionally, offer the user recommendations of other games based on the games they have played.

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